www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@4quarters.com>
Subject Re: Licensing for implementing a Java JSR within Apache
Date Thu, 22 Jan 2004 09:16:39 GMT

On Jan 22, 2004, at 1:26 AM, Cliff Schmidt wrote:

> I haven't heard from anyone on either list yet.  Maybe I scared
> everyone off with my long post (below), or maybe it's the topic
> that is scary. ;-)
> The reason the post is longish is that I was trying to describe
> the steps I think need to be taken so that someone could just
> correct me where I am wrong/confused.
> The short question is: what legal issues typically need to be
> dealt with when an Apache project wants to implement APIs of

The traditional way is that a project will just do it.  When anyone  
downloads a spec from sun's JCP site, you agree to a license that says

a) you can use this spec to figure out how to work with implementations  
of the spec

b) you can use the spec to create a compatible implementation of the  
spec, 'compatible' defined as passing the TCK.

So, the legal issue that will be dealt with at some point is passing  
the TCK.

Once you get to that point, a member can request on the jcp@ list  
access to a TCK, and it will be provided as long as that member  
understands and agrees to uphold the confidentiality requirements of  
said TCK materials.  For non-members, we are currently working out an  
NDA between the ASF and the non-member in which the non-members  
understands and agrees to the same thing....

That's it.  We're working to make this as simple as possible.  If you  
need anything, just shout here or contact me directly.


> Thanks,
> Cliff
> Geir Magnusson Jr wrote on Saturday, January 17, 2004 5:53 AM:
>> 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 <cliff@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)

View raw message