www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Date Tue, 23 Jan 2007 01:55:57 GMT

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

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