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://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/[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
