Although I agree that we had to change the license for the sca.tld
file, I'm not sure about the license for the sca-api module contents,
searching the dev list archives [1], it looks more like Tuscany were
proposing couple of these files to the spec.

Mike,  your comments and advice would be very valuable here.


[1] http://apache.markmail.org/message/hukfgmzf3pbtbgzb?q=sca+api+jeremy&page=5

On Tue, Sep 30, 2008 at 6:34 AM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, Sep 29, 2008 at 4:03 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>>
>>
>> On Mon, Sep 29, 2008 at 7:39 AM, Vamsavardhana Reddy <[EMAIL PROTECTED]>
>> wrote:
>>>
>>>
>>> On Fri, Sep 26, 2008 at 8:31 PM, Simon Laws <[EMAIL PROTECTED]>
>>> wrote:
>>>>
>>>>
>>>> On Fri, Sep 26, 2008 at 11:20 AM, Simon Laws <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Fri, Sep 26, 2008 at 10:52 AM, Luciano Resende
>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>> I was under the impression that sca.tld [1] was comming from SCA
>>>>>> specification. In this case, should it have the Apache License header
>>>>>> on it ?
>>>>>>
>>>>>> [1]
>>>>>> https://svn.apache.org/repos/asf/tuscany/java/sca/modules/host-webapp/src/main/resources/META-INF/sca.tld
>>>>>>
>>>>>> --
>>>>>> Luciano Resende
>>>>>> Apache Tuscany, Apache PhotArk
>>>>>> http://people.apache.org/~lresende
>>>>>> http://lresende.blogspot.com/
>>>>>
>>>>> Good point, it comes substantially (there are some Tuscany specific
>>>>> parts of if) from the OSOA JEE Integration Specification so it should have
>>>>> the attributions and license associated with it as defined in the
>>>>> specification. sca.tld is not one of the artifacts available from
>>>>> http://www.osoa.org/xmlns/sca/1.0/ so I expect we need to treat it as a
>>>>> portion of the spec that has been copied.
>>>>>
>>>>> The license in the specification [1] doesn't give specific permission
>>>>> to construct derviative works of the specification so this gives us a
>>>>> problem w.r.t the changes that we need to make. In lieu of immediate 
>>>>> changes
>>>>> to the specification this would be easier if sca.tld were made available 
>>>>> at
>>>>> http://www.osoa.org/xmlns/sca/1.0/. Thoughts?
>>>>>
>>>>> As an aside is the addition of  <rtexprval> something we should raise
>>>>> with OASIS or is it specific to our implementation?
>>>>>
>>>>> Regards
>>>>>
>>>>> Simon
>>>>>
>>>>> [1]
>>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf?version=1
>>>>
>>>> I've raised TUSCANY-2620 to fix this for 1.3.2. I think the derivation
>>>> point is not so problematic as this particular part of the spec is marked,
>>>> in places, indicating that implementation specific aspects will be present.
>>>> I'll go ahead and change the license to the OSOA spec license. Going 
>>>> forward
>>>> we do need to decide what to do about <rtexprval> w.r.t the OASIS
>>>> specifications.
>>>>
>>>> Simon
>>>
>>> As Raymond pointed out in [2], it appears sca.tld is not compliant with
>>> web-jsptaglibrary_2_1.xsd.  I will raise an issue with OASIS SCA-J-JEE
>>> Subcommittee.
>>>
>>> ++Vamsi
>>>
>>> [2] http://www.mail-archive.com/[email protected]/msg01952.html
>>>
>>
>> Thanks Vamsi, that would be a great help.
>>
>> Simon
>
> So following on from this I think at least the following files should have
> their license headers changed to OSOA.
>
> In sca\modules\sca-api\src\main\java\org\osoa\sca
>
>  CallableReference.java
>  ComponentContext.java
>   Conversation.java
>  ConversationEndedException.java
>  NoRegisteredCallbackException.java
>  RequestContext.java
>  ServiceReference.java
>  ServiceRuntimeException.java
>  ServiceUnavailableException.java
>
> In sca\modules\sca-api\src\main\java\org\osoa\sca\annotations
>
>  AllowsPassByReference.java
>  Authentication.java
>  Callback.java
>  ComponentName.java
>  Confidentiality.java
>  Constructor.java
>  Context.java
>  Conversational.java
>  ConversationAttributes.java
>  ConversationID.java
>  Destroy.java
>  EagerInit.java
>  EndsConversation.java
>  Init.java
>  Integrity.java
>  Intent.java
>  OneWay.java
>  PolicySets.java
>  Property.java
>  Qualifier.java
>  Reference.java
>  Remotable.java
>  Requires.java
>  Scope.java
>  Service.java
>
> There are a few definitions.xml files knocking around that have intents from
> the specs in. These would also need changing. Anything else that people know
> of?
>
> Regards
>
> Simon
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Reply via email to