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:09:29 GMT
(I'm taking this thread over to jcp-open.  Posting this note to license  
as a courtesy.)


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
> 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