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 #322
Java^TM EE Connector Architecture 1.6
JSR Review Ballot
Ballot duration: 2007-12-04 to: 2007-12-17

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

Votes

SE/EE

Apache Software Foundation

BEA Systems

Eclipse Foundation, Inc

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-12-17 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-12-17 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-17 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-17 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-17 SAS Institute Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-17 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-04 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-04 SAP SE voted No with the following comment:
In order to vote "YES" for this JSR, we would want to see licensing terms that are comparable with that of an open standard. Those terms should allow use of the specification by any compatible implementation. Specifically, the terms should not include any "Field Of Use" restrictions that favor one particular member's business interest over that of the rest of the Java Community.

------------------------------------------------------------------------------
On 2007-12-07 Red Hat voted Yes with the following comment:
The spec lead of the EE6 specification has confirmed that the EE6 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-12-08 Suleiman, Hani voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-10 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-10 Google Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-10 Nortel voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-12-10 Apache Software Foundation voted No with the following comment:
The ASF must regretfully vote "No" for this JSR.  This vote isn't a reflection of our opinion of the technological aspects of the JSR.  Rather, the ASF objects to Sun Microsystems leading another JSR while Sun remains in violation of the JSPA - the governing rules of the JCP to which Sun is a signatory - due to it's refusal to offer a TCK license for Java SE that doesn't inhibit the ability of the ASF to distribute a certified compatible Apache Harmony.   In order for Java standards to be open standards, implementors must be free to distribute their independent implementations of Java specifications under terms of their choice.
------------------------------------------------------------------------------
On 2007-12-11 Intel Corp. voted Yes with the following comment:
We were happy to see a note in the JSR indicating no Field of Use restrictions for this JSR - it simplifies review to have that in the JSR text. ("The TCK license does not limit how a compatible implementation of the specification can be used or distributed, e.g., by limiting the hardware devices or operating environments that can be supported."). In the future, the EC should see actual licenses for one alternative for the JCP required licenses at JSR initiation.  One task the JCP Process gives to the EC is to "provide feedback on the terms as an indication of how the community might react as a whole to the terms" - to do that we need to be able to see licenses.  Better yet would be for one alternative to be public so the community can consider for themselves what is required to implement that JCP spec.
------------------------------------------------------------------------------
On 2007-12-13 Eclipse Foundation, Inc voted No with the following comment:
Eclipse supports the position of the Apache Foundation. It is necessary to resolve the outstanding field of use issues with respect to all JSRs. 

Similar to others, our vote is not intended to be a reflection on the technical merits of this JSR.
------------------------------------------------------------------------------