You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2007/01/23 02:36:14 UTC
Any Final Thoughts? (Was Re: JSR 291 - public review)
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
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.
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.
geir
Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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!
>
Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Posted by Brett Porter <br...@apache.org>.
On 23/01/2007, at 12:36 PM, Geir Magnusson Jr. wrote:
> +1 : Roy, Richard, Brett (hope I got that right), Niclas, David
Yep, for what it's worth, I'm in favour. Thanks all for answering my
queries.
Your comments for the ballot sound fine.
- Brett