Mailing-List: contact jcp-open-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: jcp-open@apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <61E04DC1-076E-4C9E-811C-5BCBD4073D5D@SUN.com>
References: <747F5D5B-8D1D-44DC-ABE1-3D51C579987F@pobox.com>
 <7b3355cb0701211633k6812dea3n60f60ac0c85b668a@mail.gmail.com>
 <D1084983-FE50-45E0-8581-08733C4CAFEF@apache.org>
 <45B415FA.1090005@ungoverned.org>
 <8F4D9B06-B8C8-48BC-B081-E17D01BA6AA1@apache.org>
 <caf30e2a0701211918u4b587d44u774086298aec7c7c@mail.gmail.com>
 <45B433A3.10303@ungoverned.org>
 <eb7e2190701212359o4b0a5df9iecd6fdfa2950c48@mail.gmail.com>
 <caf30e2a0701220011v71209ddcu7d438640d5f34e4e@mail.gmail.com>
 <D3B6D422-4940-41C4-ABE1-C995B299D8F5@gmail.com>
 <D0232EBA-6E60-4E9A-B31A-88927EC7DFED@pobox.com>
 <61E04DC1-076E-4C9E-811C-5BCBD4073D5D@SUN.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7409D3E8-8E07-4CEF-AFB9-063BB2B8F3BC@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Date: Mon, 22 Jan 2007 21:14:22 -0500
To: jcp-open@apache.org


On Jan 22, 2007, at 8:55 PM, Craig L Russell wrote:

>
> On Jan 22, 2007, at 5:36 PM, Geir Magnusson Jr. wrote:
>
>> So how do we vote? (answer below)
>>
>> Roy's criterion :
>>
>> On Jan 22, 2007, at 3:27 AM, Roy T. Fielding wrote:
>>
>>> Apache should vote "No" unless *all* of the following are true:
>>>
>>>   1) The specification is completely provided by the JSR  
>>> publications
>>>      (i.e., we don't need to jump through some other license hoops
>>>      in order to read it);
>>
>> This appears to be met at this point.
>>
>>>
>>>   2) The Specification, RI, and TCK licenses are provided to the EC
>>>      prior to the vote;
>>
>> I don't believe that licenses are applicable at this point.
>
> I don't agree, but we can clarify our position in the comments that  
> accompany the vote.

The JSPA says that EGs are encouraged, not required.

>>
>>>
>>>   3) The Specification and TCK licenses allow an open source
>>>      implementation;
>>
>> The TCK isn't germane at this point, but the spec license is, and  
>> previous post had no problem.  IIRC, the OSGi spec license is  
>> sane, as is the OSGi TCK license.
>
> I agree. The OSGi license under which IBM says they intend to  
> license 291 is ok.
>>
>>>
>>>   4) The above licenses are provided at no cost to nonprofit
>>>      organizations like the ASF; and
>>
>> That's required by the JSPA.
>>
>>>
>>>   5) The technology defines something useful for Java.
>>
>> This is a judgement call, and we tend not to vote EC votes based  
>> on that (or J2EE  and the calendar API would have been toast long  
>> ago ;).
>
> On the other hand, there is evidence of the value of this technology.

Agreed.  But again, I want to be careful on how we consider this aspect.

>>
>>>
>>> I don't think it matters if OSGi gets a rubber stamp.  What  
>>> matters is
>>> that the result is specified accurately, readably, and in a form  
>>> that
>>> we can implement.
>>
>> So my tally of people's eventual positions :
>>
>> +1 : Roy, Richard, Brett (hope I got that right), Niclas, David
>>
>> Not sure : Bruce
>>
>> License concerns : Craig
>>
>> I believe that Craig's concerns about licensing should be  
>> mentioned in the voting statement.
>
> In short, my concern is that the intent to license the  
> specification according to the terms of the OSGi license should be  
> explicit in the release materials.
>
> And the intent to release the RI as the Equinox open source project  
> is certainly relevant for this phase of the project.

Yep

>>
>> I went and looked back at our statement with our original approval  
>> vote :
>>
>> "As we are a supporter of this JSR, and a proposed member of the  
>> Expert Group, we would like to see this JSR begin.  Apache has an  
>> OSGi implementation project (http://incubator.apache.org/felix/),  
>> and therefore has an interest in how the community standardizes  
>> this technology in the Java ecosystem.
>>
>> That said, we do have concerns.  We recognize that the objections  
>> of other EC members about "rubberstamping" should not be  
>> dismissed.  However, we believe that this is a judgment that can  
>> only be made later, and we welcome the opportunity to bridge two  
>> technical communities and try to remove the obvious tension  
>> between JSR-277 and OSGi.
>>
>> We emphasize our interest in seeing collaborative  community  
>> engagement in the expert group, and expect that as with any other  
>> JSR, the proposed timeline will shift to accommodate the needs of  
>> EG as it does it's work.
>>
>> Finally, we congratulate the spec lead on opening the expert group  
>> mail list to read-only access to any interested party, and expect  
>> that there will be no requirements for such access other than an  
>> expression of interest.  Further, in the interest of widespread  
>> adoption, we again urge the spec lead to create the RI and TCK as  
>> open source software, either through a new effort, or via one of  
>> the existing open source communities currently engaged in OSGi  
>> implementation."
>>
>> So the issues :
>>
>> 1) bridge the 277 and OSGi communities - there's some claim this  
>> happened, but I'm not too convinced
>>
>> 2) "rubberstamp" - it's been argued by Richard and others that the  
>> EG influenced the spec to create a v4.1, so it's not a total  
>> rubberstamp.  I'm not sure why this input couldn't have been done  
>> in OSGi, but whatever.  Also, there doesn't seem to be a good  
>> argument why a rubberstamp is bad in itself.
>>
>> 3) Clearly the timeline shifted. IIRC, the original timeline was  
>> really silly, calling for final approval by July 2006.  It's good  
>> to see that schedule isn't being adhered to.
>>
>> 4) The mail list was open, although there seem to be complains on  
>> where some of the work was done.
>>
>> So all in all, not too bad, based on our original input.
>>
>> So unless someone can find a really compelling reason not to,  
>> we'll vote yes with a statement listing our concerns and  
>> requirements for the final ballot.
>
>> I'd like to list :
>>
>> 1) Require a clear statement that the necessary IP from all OSGi  
>> members is licensed on a RAND and royalty-free basis to any  
>> compatible independent implementation.  This seems to be the  
>> biggest problem.
>>
>> 2) Ask that they help set a precedent through the submission of a  
>> TCK license that will be offered to any implementor.  The spec  
>> lead is of course able to offer any other license they choose as  
>> an alternative.  This is something we need to move to do for all  
>> specs going forward.  The lack of "ex-ante" disclosure on this is  
>> a serious problem in the JCP.
>
> As is the lack of ex-ante disclosure of specification licensing  
> terms. To my great surprise, spec license terms vary significantly  
> for non-Sun-led JSRs.

I thought the spec license has specific requirements - but this isn't  
a spec yet.

The sanest license I've seen so far is from BEA for a TCK we licensed  
from them.  Simple, clean, to the point.  A real model for everyone  
else.


>>
>> 3) Encourage them to choose an open source implementation as the RI
>>
>> 4) Encourage them to deliver the TCK as open source software.
>>
>> any more comments, additions, thoughts, or protest?  Speak fast -  
>> I need to do this tonight.
>
> Looks good.

Thanks

geir

>
> Craig
>>
>> geir
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>