Mailing-List: contact jcp-open-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: jcp-open@apache.org
Received-SPF: pass (herse.apache.org: local policy)
Date: Mon, 22 Jan 2007 17:55:57 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
In-reply-to: <D0232EBA-6E60-4E9A-B31A-88927EC7DFED@pobox.com>
Sender: Craig.Russell@Sun.COM
To: jcp-open@apache.org
Message-id: <61E04DC1-076E-4C9E-811C-5BCBD4073D5D@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-116-84115443; micalg=sha1
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>


--Apple-Mail-116-84115443
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


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!


--Apple-Mail-116-84115443
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw
NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7
16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg
Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc
a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr
jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym
bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt
/CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6
eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTIzMDE1NTU5WjAjBgkqhkiG9w0B
CQQxFgQUorRy9uFQIVkM2XiT5aH0IFuG0iYwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq
SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAF7yGC4zG7irSCfbYSZEZUE45yptp1HH
nyC1OA73/aM5lrr+CkbzAb/Ofc193NiQWle+XiZ/WcR/dh23H49eHAAVGFaVUth9JfdFbJgCEuz9
qhEs0C3APom/y84c8vuItMZdGPk4qwX9j2uvQxBC2aeIibP5BZm2B8N9Q4xXpOqdyVOp1eQnKtPI
toEpi5NoaCOkIg/l9GxfLX5/eKj6CcWdwtKKmMKW9+eHxwY+0izHN220AR/gg2HMMkUg6H33dHpO
vjKqVf4Ye4hWsw6Dh0oDximYtgZ96WtgeIYjJFdhpK8X9eGF1vyoQkH0AfOV7dPK0JUE8YybgrZu
f6CxZ0QAAAAAAAA=

--Apple-Mail-116-84115443--