You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Geir Magnusson Jr <ge...@4quarters.com> on 2004/01/17 14:52:55 UTC

Re: Licensing for implementing a Java JSR within Apache

On Jan 14, 2004, at 6:52 AM, Geir Magnusson Jr wrote:

>
> On Jan 12, 2004, at 2:50 PM, Davanum Srinivas wrote:
>
>> FYI, Apache Axis already implements SAAJ spec :) you can ask these  
>> questions on jcp@apache.org
>
> jcp@ is members only, and I don't believe that Cliff is a member.
>
> We do have a public JCP-issues list, but it has *zero* traffic.  I  
> also don't remember what it is.  I'll find out, report back, ask Cliff  
> to subscribe there, and continue with this thread there.

The list is jcp-open@apache.org

Crossposting...

geir

>
> geir
>
>>
>> thanks,
>> dims
>>
>> --- Cliff Schmidt <cl...@bea.com> wrote:
>>> Can anyone tell me what steps should be taken for a committer on an
>>> existing Apache project to build an independent implementation of a
>>> particular Java JSR?  I've listed four steps I would assume one
>>> would need to follow, but at each step I have a couple questions.
>>> Maybe I'm making this harder than it needs to be, but I haven't
>>> found any info posted around Apache on how this process works.
>>>
>>>
>>>
>>> Suppose an Apache project wants to add a SOAP interface that is
>>> compliant with JSR-67's Soap with Attachments (SAAJ) spec [1].
>>> Here is the sequence of steps I imagine would be followed:
>>>
>>> 1. Any individual committer obtains the license [2] for the
>>> download of the spec.  See an excerpt of this license below.
>>>
>>> Questions: Is this the applicable license?  Is there a license
>>> that the ASF already has that applies to all J2EE 1.4 JSRs,
>>> which would make this one not applicable?  Is there a problem
>>> with me, as an individual (or worse, also an employee of a company
>>> that also licenses JSRs from Sun) using this license for
>>> something that is ending up at Apache?  (When I download the
>>> license, it applies to me -- not the ASF.)
>>>
>>> 2.  The committer codes up a few Java classes that partially
>>> implement the spec's interfaces and integrates it with the rest
>>> of the project.  The committer now wants to check this code into
>>> the project.  (The committer has already signed the latest
>>> approved CLA.)
>>>
>>> Questions: Where should the committer note the license of the
>>> APIs?  Paragraph 4 of the CLA mentions including details on
>>> applicable licenses as part of the contribution.  Does this
>>> mean in the source, the check-in comments, or should there be
>>> a separate document faxed in, such as the software grant?
>>>
>>> More Questions: This particular license (see below) allows
>>> distribution provided that the spec is fully implemented and
>>> passes the TCK (among other things).  Does this mean that
>>> before "distributing" the independent implementation to Apache
>>> (by checking it in), the code would need to pass the TCK first?
>>> There's a paragraph towards the end that says these limitations
>>> don't apply to "pass-through" requirements, but I'm not sure
>>> that applies here.
>>>
>>> 3. The committer and other contributors in the project now
>>> want to continue and complete development of this piece of
>>> their project (the independent implementation of the JSR).
>>> Each of them (those who have signed CLAs) is now checking-in
>>> code to complete the implementation.
>>>
>>> Question: Once the interfaces have already been checked-in,
>>> does that mean that the other individual contributors do
>>> not need to worry about the license for their work on the
>>> independent implementation, or do they need to be covered
>>> by a license since they are building the implementation?
>>>
>>> 4. The project eventually wants to pass the TCK before
>>> their first 1.0 release.
>>>
>>> Questions: Who do they contact within Apache, and when, to
>>> obtain a TCK?  Are there any rules/guidelines about
>>> what type of releases (source only? v. 0.5 binary release?)
>>> can occur before passing the TCK?
>>>
>>> Thanks,
>>> Cliff
>>>
>>> [1] http://java.sun.com/xml/downloads/saaj.html
>>> [2]  
>>> http://java.sun.com/webapps/download/Display? 
>>> BundleId=9445&button=Download
>>>
>>> ========================================================
>>>
>>> EXCERPT OF JSR-67 LICENSE -- see [2] for complete copy
>>>
>>> 'Sun also grants you a perpetual, non-exclusive, worldwide,
>>> fully paid-up, royalty free, limited license (without the
>>> right to sublicense) under any applicable copyrights or
>>> patent rights it may have in the Specification to create
>>> and/or distribute an Independent Implementation of the
>>> Specification that: (i) fully implements the Spec(s)
>>> including all its required interfaces and functionality;
>>> (ii) does not modify, subset, superset or otherwise extend
>>> the Licensor Name Space, or include any public or protected
>>> packages, classes, Java interfaces, fields or methods within
>>> the Licensor Name Space other than those required/authorized
>>> by the Specification or Specifications being implemented;
>>> and (iii) passes the TCK (including satisfying the
>>> requirements of the applicable TCK Users Guide) for such
>>> Specification. The foregoing license is expressly
>>> conditioned on your not acting outside its scope. No license
>>> is granted hereunder for any other purpose.
>>> You need not include limitations (i)-(iii) from the previous
>>> paragraph or any other particular "pass through"
>>> requirements in any license You grant concerning the use of
>>> your Independent Implementation or products derived from it.
>>> However, except with respect to implementations of the
>>> Specification (and products derived from them) that satisfy
>>> limitations (i)-(iii) from the previous paragraph, You may
>>> neither: (a) grant or otherwise pass through to your
>>> licensees any licenses under Sun's applicable intellectual
>>> property rights; nor (b) authorize your licensees to make
>>> any claims concerning their implementation's compliance with
>>> the Spec in question.
>>> For the purposes of this Agreement: "Independent
>>> Implementation" shall mean an implementation of the
>>> Specification that neither derives from any of Sun's source
>>> code or binary code materials nor, except with an
>>> appropriate and separate license from Sun, includes any of
>>> Sun's source code or binary code materials; and "Licensor
>>> Name Space" shall mean the public class or interface
>>> declarations whose names begin with "java", "javax",
>>> "com.sun" or their equivalents in any subsequent naming
>>> convention adopted by Sun through the Java Community
>>> Process, or any recognized successors or replacements
>>> thereof.'
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: licensing-unsubscribe@apache.org
>>> For additional commands, e-mail: licensing-help@apache.org
>>>
>>
>>
>> =====
>> Davanum Srinivas - http://webservices.apache.org/~dims/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: licensing-unsubscribe@apache.org
>> For additional commands, e-mail: licensing-help@apache.org
>>
>>
> -- 
> Geir Magnusson Jr                                   203-247-1713(m)
> geir@4quarters.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: licensing-unsubscribe@apache.org
> For additional commands, e-mail: licensing-help@apache.org
>
>
-- 
Geir Magnusson Jr                                   203-247-1713(m)
geir@4quarters.com