On Wed, Oct 1, 2008 at 2:44 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > > > On Wed, Oct 1, 2008 at 2:27 PM, Mike Edwards < > [EMAIL PROTECTED]> wrote: > >> Simon Laws wrote: >> >> >>> >>> On Tue, Sep 30, 2008 at 8:55 PM, Mike Edwards < >>> [EMAIL PROTECTED] <mailto: >>> [EMAIL PROTECTED]>> 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
