www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Date Tue, 23 Jan 2007 02:14:22 GMT

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


Mime
View raw message