These are the final results of the Final Approval Ballot for JSR #336. The Executive Committee for SE/EE has approved this ballot.
JSR336
StageFinal Approval Ballot
Ballot durationJul 5, 2011 to Jul 18, 2011
Votes

SE/EE

Credit Suisse
Eclipse Foundation, Inc
Ericsson AB
Fujitsu Limited
Goldman Sachs & Co.
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
Keil, Werner
London Java Community
Oracle
Red Hat
SAP SE
SouJava
VMware
Vote Log

SE/EE

On 2011-07-15 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-07-17 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-07-06 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-07-18 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-07-18 VMware voted Yes with the following comment:
VMware shares the concerns expressed by others about licensing terms. However, we support this proposal on technical merit.
------------------------------------------------------------------------------
On 2011-07-18 Keil, Werner voted Yes with the following comment:
Based on the technical improvement and necessary evolution of the Java platform I vote "Yes", but want to emphasize again the concern about intransparent ways this umbrella JSR and some of the underlying EGs have worked.
 
Hoping greater transparency in the spirit of JCP.next and also more satisfactory licensing terms follow with Java 8 and beyond.
------------------------------------------------------------------------------
On 2011-07-16 London Java Community voted Yes with the following comment:
The LJC votes Yes to the JSR for SE 7 based on its technical merit and our very strong desire to get Java moving again. 

We note that the archives for some of the Expert Groups that comprise this JSR have not been made public. It is most regrettable that this did not happen prior to this being put to final vote. 

We trust that no further platform JSRs will be submitted without full access to EG archives - we would be very unlikely to support any such JSR.
------------------------------------------------------------------------------
On 2011-07-18 Goldman Sachs & Co. voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-07-12 Red Hat voted Yes with the following comment:
Red Hat's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  Red Hat would prefer a licensing model that creates an open arena for everyone, including those not members of the JCP and removes any ability for one individual or vendor to exert undue control over a standard. We are an open source company and hence would like to see such a licensing model for JCP contributions. Note however, that this comment is not necessarily directed at the license terms for this JSR, but is a statement of Red Hat's preferred licensing model.
------------------------------------------------------------------------------
On 2011-07-13 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 2011-07-13 Google Inc. voted No with the following comment:
While Google supports the technical content of this JSR, we are voting no because of its licensing terms. As per the JCP resolutions of 9/25/2007 and 4/7/2009, "TCK licenses must not be used to discriminate against or restrict compatible implementations of Java specifications by including field-of-use restrictions on the tested implementations. Licenses containing such limitations do not meet the requirements of the JSPA, and violate the expectations of the Java community that JCP specs can be openly implemented."

The proposed license clearly violates this requirement (see Exhibit A, Section II). Oracle was duly reminded of this when JSR-336 was first proposed, but has done nothing to address the issue in the months that followed. It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license, as this clearly violates the JSPA, by Oracle's own admission. 

We do hope that other JCP members show the courage of their convictions and join with us in this vote. Otherwise, Oracle will have little motivation to provide the community with TCK licenses that comply with the JSPA and preserve the openness of the Java platform. By acquiescing, we risk losing the support of the many strong independent voices whose contributions made Java what it is today

------------------------------------------------------------------------------
On 2011-07-18 SouJava voted Yes with the following comment:
SouJava votes yes on this JSR based on its technical merits. We understand and support the complains from other EC members and of many in the Java community on licensing issues. Our reading is that this is a transition moment where Java needs to advance technically, and on this, our members are satisfied with the evolution of the technology. But we are unhappy with the licensing terms in this JSR. By discriminating against open source implementations, they cloud the work being done inside this process, and cast doubts on the openness of the resulting standards. This is prejudicial for the whole Java ecosystem. At this point, we are willing to accept what we see as a temporary step back in the JCP. But our main drive is to work towards rectifying those issues, so that the next version of Java can be both a step forward technically, and also a step forward in making the JCP standards more open, inclusive, transparent and fair.
------------------------------------------------------------------------------
On 2011-07-18 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-07-06 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-07-11 Credit Suisse voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-07-12 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------