The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

JSR #317
Java^TM Persistence 2.0
JSR Review Ballot
Ballot duration: 2007-07-17 to: 2007-07-30

These are the final results of the JSR Review Ballot for JSR #317. The Executive Committee for SE/EE has approved this ballot.

Votes

SE/EE

Apache Software Foundation

BEA Systems

Borland Software Corporation

Fujitsu Limited

Google Inc.

Hewlett-Packard

IBM

Intel Corp.

Lea, Doug

Nortel

Oracle

Red Hat

SAP SE

SAS Institute Inc.

Suleiman, Hani

Sun Microsystems, Inc.

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

SE/EE

On 2007-07-17 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-19 Borland Software Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-20 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-24 Suleiman, Hani voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-25 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-25 Nortel voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-27 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-26 Red Hat voted Yes with the following comment:
The spec lead of the Java Persistence 2.0 specification has confirmed that the TCK would contain no "field of use restrictions", as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.

However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.

Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.

------------------------------------------------------------------------------
On 2007-07-28 IBM voted Yes with the following comment:
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
------------------------------------------------------------------------------
On 2007-07-30 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-30 SAS Institute Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-30 Intel Corp. voted Yes with the following comment:
The Spec Lead has told us there are no "field of use restrictions" on implementations for this particular JSR. The Apache open letter about Java SE (http://www.apache.org/jcp/sunopenletter.html) claimed that a confidential license for a required JCP test suite restricts how Independent Implementations of that JCP spec can be used. Licenses to test for JCP compatibility must not be used to limit or restrict competing, compatible implementations; licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates.  For every JCP ballot, we will ask the Spec Lead whether such restrictions exist in their licenses for that JSR.  We have been asking that for the licenses for the particular JSR under ballot, but are considering the view expressed in the Apache Foundation JSR 316 ballot comment that Spec Leads who do this for any JSR should not lead new JSRs, so we may start asking Spec Leads if they do it for any JSRs.
------------------------------------------------------------------------------
On 2007-07-30 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-07-30 Apache Software Foundation voted No with the following comment:
The Apache Software Foundation's vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA 

http://www.apache.org/jcp/sunopenletter.html

and therefore shouldn't be allowed to start another JSR until the above matter is resolved. 

This vote is not a comment on the technical merits of the JSR.  If not for the issue of the spec lead, the ASF would have otherwise voted "yes".
------------------------------------------------------------------------------
On 2007-07-30 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------