You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/09/30 15:34:59 UTC
OSOA API headers - was: Re: sca.tld license header
On Mon, Sep 29, 2008 at 4:03 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Mon, Sep 29, 2008 at 7:39 AM, Vamsavardhana Reddy <c1...@gmail.com>wrote:
>
>>
>>
>> On Fri, Sep 26, 2008 at 8:31 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Fri, Sep 26, 2008 at 11:20 AM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Fri, Sep 26, 2008 at 10:52 AM, Luciano Resende <luckbr1975@gmail.com
>>>> > 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://people.apache.org/%7Elresende>
>>>>> 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/dev@tuscany.apache.org/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
Re: OSOA API headers - was: Re: sca.tld license header
Posted by Simon Laws <si...@googlemail.com>.
snip...
>From what i can tell there is NOTHING, ANYWHERE, that says we need to
> include the OSOA license header in any of our source files, and it seems
> wrong to me to do so.
>
You are absolutely right. This was me being over-zealous in adding header
information. I can fix that.
>
> What the OSOA license does say is that we need to include two things:
>
> 1. A link or URL to the Service Component Architecture Specification at
> this location:
> http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
>
> 2. The full text of the copyright notice as shown in the Service Component
> Architecture Specification.
>
> To date we have been including those two things in artifact top level
> LICENSE/NOTICE files and its got through lots of release reviews including
> all the ones while in the Incubator with lots of eyes looking so i don't see
> why we want to change.
>
>
>
> A slightly related point is that the Apache headers we include in each of
> our source files are not strictly necessary but are just included for good
> measure, the code is covered by the top level LICENSE/NOTICE files in the
> released artifact and that is all thats absolutely required.
>
> It is a bug that the host-webapp module jar LICENSE/NOTICE file weren't
> updated for the OSOA license when the taglib was added, IMHO thats all that
> needs fixing here.
>
>
> I'm not sure that will satisfy everyone now that this has been blown up so
> much though so how about also removing the Apache header from all the spec
> derived files and replacing it with the SCA copyright. As i pointed out
> above the header isn't really necessary anyway and that way the files would
> match the .xsd files we have eg
> https://svn.apache.org/repos/asf/tuscany/java/sca/modules/assembly-xsd/src/main/resources/sca-binding-ejb.xsd.
> This does seem to go slightly against the ASF policy of having attributions
> in the NOTICE file where possible though, see:
> http://www.apache.org/legal/src-headers.html
>
> ...ant
>
> Sounds OK to me. I will add the copyright from the specs in question and
also the link to the web site.
Simon
Re: OSOA API headers - was: Re: sca.tld license header
Posted by ant elder <an...@gmail.com>.
On Wed, Oct 1, 2008 at 2:44 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Wed, Oct 1, 2008 at 2:27 PM, Mike Edwards <
> mike.edwards.inglenook@gmail.com> wrote:
>
>> Simon Laws wrote:
>>
>>
>>>
>>> On Tue, Sep 30, 2008 at 8:55 PM, Mike Edwards <
>>> mike.edwards.inglenook@gmail.com <mailto:
>>> mike.edwards.inglenook@gmail.com>> wrote:
>>>
>>> Simon Laws wrote:
>>>
>>>
>>> <snip>
>>>
>>> Excellent Luciano. Well found. If they came from Tuscany in the
>>> first place, which this post would seem to suggest, they can
>>> stay with the ASL2 license.
>>>
>>> I agree about sca.tld though. Judging by the commit log that was
>>> copied from the spec.
>>>
>>> Regards
>>>
>>> Simon
>>>
>>> Folks,
>>>
>>> If those files are derived from material in the OSOA specs, then
>>> they will fall under the license of the OSOA specs.
>>>
>>> I dont see how the material can use an ASL2 license.
>>>
>>>
>>> Yours, Mike.
>>>
>>>
>>> Mike
>>>
>>> Looking back at svn it seems that it was the other way round for the
>>> sca-api files. Part of them came from the original IBM/BEA contribution and
>>> subsequent development went on in sandboxes (presumably in parallel with
>>> the spec development) before they were copied into trunk. I assume that the
>>> people involved in creating these files chose to contribute them to Tuscany
>>> and ASF2 license them and also chose to contribute them to OSOA for
>>> inclusion in the spec. Sound plausible?
>>>
>>> Simon
>>>
>> Folks,
>>
>> The APIs in the SCA Java specifications were developed by a Technical
>> Committee process, involving a whole group of people from many companies,
>> working under a legal agreement relating to the OSOA collaboration. The
>> APIs are not the creation of any one person, but are the results of the
>> joint deliberations of the technical committee. This is true whatever is
>> said in SVN about the origins of the files currently in Tuscany.
>>
>> The APIs are created and are licensed for use under the terms of the OSOA
>> collaboration. Any files which match the specifications are simply copies
>> of the material in the specifications and fall under the copyright and
>> licensing laid down by the OSOA collaboration. The same principle would
>> apply to OASIS specifications (they have similar copyright and licensing to
>> OSOA).
>>
>> I hope this helps to clarify things.
>>
>>
>> Yours, Mike.
>>
>
> Ok, interesting. Having not been involved in the development of the OSOA
> specs it's difficult to reverse engineer this knowledge.
>
> So in summary it looks like the API files did have the wrong licenses added
> as they were being coded in Tuscany. That means to me that we go with the
> 1.3.2. branch change I have already made to the APIs and sca.tld to add
> OSOA licenses. So I'll roll RC2 and start a vote on that.
>
> Simon
>
>From what i can tell there is NOTHING, ANYWHERE, that says we need to
include the OSOA license header in any of our source files, and it seems
wrong to me to do so.
What the OSOA license does say is that we need to include two things:
1. A link or URL to the Service Component Architecture Specification at this
location:
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
2. The full text of the copyright notice as shown in the Service Component
Architecture Specification.
To date we have been including those two things in artifact top level
LICENSE/NOTICE files and its got through lots of release reviews including
all the ones while in the Incubator with lots of eyes looking so i don't see
why we want to change.
A slightly related point is that the Apache headers we include in each of
our source files are not strictly necessary but are just included for good
measure, the code is covered by the top level LICENSE/NOTICE files in the
released artifact and that is all thats absolutely required.
It is a bug that the host-webapp module jar LICENSE/NOTICE file weren't
updated for the OSOA license when the taglib was added, IMHO thats all that
needs fixing here.
I'm not sure that will satisfy everyone now that this has been blown up so
much though so how about also removing the Apache header from all the spec
derived files and replacing it with the SCA copyright. As i pointed out
above the header isn't really necessary anyway and that way the files would
match the .xsd files we have eg
https://svn.apache.org/repos/asf/tuscany/java/sca/modules/assembly-xsd/src/main/resources/sca-binding-ejb.xsd.
This does seem to go slightly against the ASF policy of having attributions
in the NOTICE file where possible though, see:
http://www.apache.org/legal/src-headers.html
...ant
Re: OSOA API headers - was: Re: sca.tld license header
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Oct 1, 2008 at 2:27 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Simon Laws wrote:
>
>
>>
>> On Tue, Sep 30, 2008 at 8:55 PM, Mike Edwards <
>> mike.edwards.inglenook@gmail.com <ma...@gmail.com>>
>> wrote:
>>
>> Simon Laws wrote:
>>
>>
>> <snip>
>>
>> Excellent Luciano. Well found. If they came from Tuscany in the
>> first place, which this post would seem to suggest, they can
>> stay with the ASL2 license.
>>
>> I agree about sca.tld though. Judging by the commit log that was
>> copied from the spec.
>>
>> Regards
>>
>> Simon
>>
>> Folks,
>>
>> If those files are derived from material in the OSOA specs, then
>> they will fall under the license of the OSOA specs.
>>
>> I dont see how the material can use an ASL2 license.
>>
>>
>> Yours, Mike.
>>
>>
>> Mike
>>
>> Looking back at svn it seems that it was the other way round for the
>> sca-api files. Part of them came from the original IBM/BEA contribution and
>> subsequent development went on in sandboxes (presumably in parallel with
>> the spec development) before they were copied into trunk. I assume that the
>> people involved in creating these files chose to contribute them to Tuscany
>> and ASF2 license them and also chose to contribute them to OSOA for
>> inclusion in the spec. Sound plausible?
>>
>> Simon
>>
> Folks,
>
> The APIs in the SCA Java specifications were developed by a Technical
> Committee process, involving a whole group of people from many companies,
> working under a legal agreement relating to the OSOA collaboration. The
> APIs are not the creation of any one person, but are the results of the
> joint deliberations of the technical committee. This is true whatever is
> said in SVN about the origins of the files currently in Tuscany.
>
> The APIs are created and are licensed for use under the terms of the OSOA
> collaboration. Any files which match the specifications are simply copies
> of the material in the specifications and fall under the copyright and
> licensing laid down by the OSOA collaboration. The same principle would
> apply to OASIS specifications (they have similar copyright and licensing to
> OSOA).
>
> I hope this helps to clarify things.
>
>
> Yours, Mike.
>
Ok, interesting. Having not been involved in the development of the OSOA
specs it's difficult to reverse engineer this knowledge.
So in summary it looks like the API files did have the wrong licenses added
as they were being coded in Tuscany. That means to me that we go with the
1.3.2. branch change I have already made to the APIs and sca.tld to add OSOA
licenses. So I'll roll RC2 and start a vote on that.
Simon
Re: OSOA API headers - was: Re: sca.tld license header
Posted by Kevan Miller <ke...@gmail.com>.
On Oct 1, 2008, at 9:27 AM, Mike Edwards wrote:
> Simon Laws wrote:
>> On Tue, Sep 30, 2008 at 8:55 PM, Mike Edwards <mike.edwards.inglenook@gmail.com
>> <ma...@gmail.com>> wrote:
>> Simon Laws wrote:
>> <snip>
>> Excellent Luciano. Well found. If they came from Tuscany in
>> the
>> first place, which this post would seem to suggest, they can
>> stay with the ASL2 license.
>> I agree about sca.tld though. Judging by the commit log that
>> was
>> copied from the spec.
>> Regards
>> Simon
>> Folks,
>> If those files are derived from material in the OSOA specs, then
>> they will fall under the license of the OSOA specs.
>> I dont see how the material can use an ASL2 license.
>> Yours, Mike.
>> Mike
>> Looking back at svn it seems that it was the other way round for
>> the sca-api files. Part of them came from the original IBM/BEA
>> contribution and subsequent development went on in sandboxes
>> (presumably in parallel with the spec development) before they were
>> copied into trunk. I assume that the people involved in creating
>> these files chose to contribute them to Tuscany and ASF2 license
>> them and also chose to contribute them to OSOA for inclusion in the
>> spec. Sound plausible?
>> Simon
> Folks,
>
> The APIs in the SCA Java specifications were developed by a
> Technical Committee process, involving a whole group of people from
> many companies, working under a legal agreement relating to the OSOA
> collaboration. The APIs are not the creation of any one person, but
> are the results of the joint deliberations of the technical
> committee. This is true whatever is said in SVN about the origins
> of the files currently in Tuscany.
>
> The APIs are created and are licensed for use under the terms of the
> OSOA collaboration. Any files which match the specifications are
> simply copies of the material in the specifications and fall under
> the copyright and licensing laid down by the OSOA collaboration.
> The same principle would apply to OASIS specifications (they have
> similar copyright and licensing to OSOA).
That would seem to depend on the donations to Apache. If those files
were donated to the Apache Tuscany project by IBM or BEA and they were
the sole copyright holders for those files, then they would not be
covered by the OSOA license. The Tuscany project would be free to do
with them what the Tuscany project wants. The fact that the files
might have also been donated to OSOA, is irrelevant. Unless the
propriety of the donation/contribution to the Tuscany project is in
doubt (e.g. they weren't the sole copyright holder), there's nothing
which would force a switch to the OSOA license for those files. If IBM/
BEA weren't the copyright holder, then certainly agree...
That said, regardless of the propriety of those files, seem to be many
reasons that OSOA licensed versions of these files should be used...
Updates/changes/fixes to these files would certainly be problematic...
By the way, would seem a lot easier if properly licensed versions of
these files were actually provided by OSOA, rather than embedded
within specs...
--kevan
Re: OSOA API headers - was: Re: sca.tld license header
Posted by Mike Edwards <mi...@gmail.com>.
Simon Laws wrote:
>
>
> On Tue, Sep 30, 2008 at 8:55 PM, Mike Edwards
> <mike.edwards.inglenook@gmail.com
> <ma...@gmail.com>> wrote:
>
> Simon Laws wrote:
>
>
> <snip>
>
> Excellent Luciano. Well found. If they came from Tuscany in the
> first place, which this post would seem to suggest, they can
> stay with the ASL2 license.
>
> I agree about sca.tld though. Judging by the commit log that was
> copied from the spec.
>
> Regards
>
> Simon
>
> Folks,
>
> If those files are derived from material in the OSOA specs, then
> they will fall under the license of the OSOA specs.
>
> I dont see how the material can use an ASL2 license.
>
>
> Yours, Mike.
>
>
> Mike
>
> Looking back at svn it seems that it was the other way round for the
> sca-api files. Part of them came from the original IBM/BEA contribution
> and subsequent development went on in sandboxes (presumably in parallel
> with the spec development) before they were copied into trunk. I assume
> that the people involved in creating these files chose to contribute
> them to Tuscany and ASF2 license them and also chose to contribute them
> to OSOA for inclusion in the spec. Sound plausible?
>
> Simon
Folks,
The APIs in the SCA Java specifications were developed by a Technical Committee process, involving a
whole group of people from many companies, working under a legal agreement relating to the OSOA
collaboration. The APIs are not the creation of any one person, but are the results of the joint
deliberations of the technical committee. This is true whatever is said in SVN about the origins of
the files currently in Tuscany.
The APIs are created and are licensed for use under the terms of the OSOA collaboration. Any files
which match the specifications are simply copies of the material in the specifications and fall
under the copyright and licensing laid down by the OSOA collaboration. The same principle would
apply to OASIS specifications (they have similar copyright and licensing to OSOA).
I hope this helps to clarify things.
Yours, Mike.
Re: OSOA API headers - was: Re: sca.tld license header
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Sep 30, 2008 at 8:55 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Simon Laws wrote:
>
>>
>> <snip>
>
>> Excellent Luciano. Well found. If they came from Tuscany in the first
>> place, which this post would seem to suggest, they can stay with the ASL2
>> license.
>>
>> I agree about sca.tld though. Judging by the commit log that was copied
>> from the spec.
>>
>> Regards
>>
>> Simon
>>
> Folks,
>
> If those files are derived from material in the OSOA specs, then they will
> fall under the license of the OSOA specs.
>
> I dont see how the material can use an ASL2 license.
>
>
> Yours, Mike.
>
Mike
Looking back at svn it seems that it was the other way round for the sca-api
files. Part of them came from the original IBM/BEA contribution and
subsequent development went on in sandboxes (presumably in parallel with
the spec development) before they were copied into trunk. I assume that the
people involved in creating these files chose to contribute them to Tuscany
and ASF2 license them and also chose to contribute them to OSOA for
inclusion in the spec. Sound plausible?
Simon
Re: OSOA API headers - was: Re: sca.tld license header
Posted by Mike Edwards <mi...@gmail.com>.
Simon Laws wrote:
>
<snip>
> Excellent Luciano. Well found. If they came from Tuscany in the first
> place, which this post would seem to suggest, they can stay with the
> ASL2 license.
>
> I agree about sca.tld though. Judging by the commit log that was copied
> from the spec.
>
> Regards
>
> Simon
Folks,
If those files are derived from material in the OSOA specs, then they will fall under the license of
the OSOA specs.
I dont see how the material can use an ASL2 license.
Yours, Mike.
Re: OSOA API headers - was: Re: sca.tld license header
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Sep 30, 2008 at 6:49 PM, Luciano Resende <lu...@gmail.com>wrote:
> 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 <si...@googlemail.com>
> wrote:
> >
> >
> > On Mon, Sep 29, 2008 at 4:03 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >>
> >>
> >> On Mon, Sep 29, 2008 at 7:39 AM, Vamsavardhana Reddy <
> c1vamsi1c@gmail.com>
> >> wrote:
> >>>
> >>>
> >>> On Fri, Sep 26, 2008 at 8:31 PM, Simon Laws <simonslaws@googlemail.com
> >
> >>> wrote:
> >>>>
> >>>>
> >>>> On Fri, Sep 26, 2008 at 11:20 AM, Simon Laws <
> simonslaws@googlemail.com>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> On Fri, Sep 26, 2008 at 10:52 AM, Luciano Resende
> >>>>> <lu...@gmail.com> 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://people.apache.org/%7Elresende>
> >>>>>> 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/dev@tuscany.apache.org/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://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
Excellent Luciano. Well found. If they came from Tuscany in the first place,
which this post would seem to suggest, they can stay with the ASL2 license.
I agree about sca.tld though. Judging by the commit log that was copied from
the spec.
Regards
Simon
Re: OSOA API headers - was: Re: sca.tld license header
Posted by Luciano Resende <lu...@gmail.com>.
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 <si...@googlemail.com> wrote:
>
>
> On Mon, Sep 29, 2008 at 4:03 PM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>>
>> On Mon, Sep 29, 2008 at 7:39 AM, Vamsavardhana Reddy <c1...@gmail.com>
>> wrote:
>>>
>>>
>>> On Fri, Sep 26, 2008 at 8:31 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>>
>>>>
>>>> On Fri, Sep 26, 2008 at 11:20 AM, Simon Laws <si...@googlemail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Fri, Sep 26, 2008 at 10:52 AM, Luciano Resende
>>>>> <lu...@gmail.com> 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/dev@tuscany.apache.org/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/