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 Any Final Thoughts? (Was Re: JSR 291 - public review)
Date Tue, 23 Jan 2007 01:36:14 GMT
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.

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

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

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

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  

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  

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  

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.

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.


View raw message