These are the final results of the Public Review Ballot for JSR #316. The Executive Committee for SE/EE has approved this ballot.
JSR316
StagePublic Review Ballot
Ballot durationFeb 17, 2009 to Feb 23, 2009
Votes

SE/EE

Apache Software Foundation
Eclipse Foundation, Inc
Ericsson AB
Fujitsu Limited
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
Keil, Werner
Lea, Doug
Nortel
Oracle
Red Hat
SAP SE
Sun Microsystems, Inc.
VMware
Vote Log

SE/EE

On 2009-02-17 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-20 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-20 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-20 Google Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-22 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 Sun Microsystems 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 2009-02-22 Keil, Werner voted Yes with the following comment:
I agree with RedHat Middleware, that an Open Source approach to all of Java should not limit e.g. a TCK or other parts of the JSR in proprietary ways. Recent discussions on more restrictive access to code by other fellow EC members or others raising their licence fees up to 25% in the middle of the worst crisis show, that in times of economic hardship many of us including individual consultants may want to find proper ways to financially manifest some of these contributions and efforts as well.
There are some good examples out there on how this can be done, e.g. via service models for an otherwise open and free solution.

Btw, the statement "targeted to ship in 2008" may need revision and update, too?;-)
------------------------------------------------------------------------------
On 2009-02-23 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 2009-02-23 SAP SE voted Yes with the following comment:
SAP votes YES but would like to content that more work is required for the integration of JSR 299 into the platform to be useful and successful. We also would like the Spec Lead to consider putting more emphasis on architectural rigor regarding a single consolidated and extensible component model to be used across the platform - right now there are three (EJB, JSF and JSR 299).

------------------------------------------------------------------------------
On 2009-02-23 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-23 VMware voted Abstain with the following comment:
The introduction of profiles is a step in the right direction. However, we are disappointed not to see a minimal web profile, especially as this has become the choice of most enterprise Java users.

As with previous releases, the inclusion of  unproven technology is a risk, especially in JSR 299 and EJB concurrency annotations. The number of substantial changes late in the process also gives us concern about the maturity of the result--especially, the impact of the scope creep of JSR 299 on other specifications.

Experience has shown that tying dependency injection features to a server environment does not match user requirements, as injection is common to all application types. We would have preferred to see a dependency injection model for SE, as we proposed in 2007.

Finally, we are not convinced that the end result matches the goals of Java EE 6 as defined in the original specification request, which we strongly supported.

------------------------------------------------------------------------------
On 2009-02-23 Intel Corp. voted Yes with the following comment:
This is a general comment we make in each ballot  By the agreement that forms the JCP, other than reciprocity rules for licensing and three compatibility conditions (including passing the TCK test suite) "the Spec Lead agrees not to impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations." The Apache Foundation claims in an open letter that they have been unable to obtain a TCK License that does not restrict compatible implementations of the SE Platform (additional restrictions that are not in the  specification itself). 

Java EE requires Java SE.  If the Java EE TCK License requires use of an SE implementation that passes the SE TCK and if the SE TCK License restricts field of use then the EE TCK License would also be restricting field of use through the SE TCK License.  Since the licenses are confidential, we do not know.

By the time EE 6 JSRs come to Final Ballot, we expect a statement that the EE 6 TCK License does not restrict field of use, does not require implementing anything other than what is required in the spec itself (no "value add" preventing implementation of just the spec) and does not require any other license that restricts field of use of JCP Specs.  
------------------------------------------------------------------------------
On 2009-02-23 Apache Software Foundation voted No with the following comment:
Apache must regretfully vote "No" for JSR-316, as we contend that the spec lead - Sun Microsystems - is not complying with the JSPA with respect to  Java SE TCK licensing.  We believe that members of the JCP that do not comply with the letter and spirit of the governing rules should not be allowed to lead JSRs.

This is not a statement about the technical merit or quality of work done by the Expert Group to date, and if it were not for the unresolved non-compliance by Sun, Apache would most likely vote "Yes".
------------------------------------------------------------------------------
On 2009-02-23 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-23 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------