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 #356
Java^TM API for WebSocket
JSR Review Ballot
Ballot duration: 2012-02-21 to: 2012-03-05
These are the final results of the JSR Review Ballot for JSR #356. The Executive Committee for SE/EE has approved this ballot.
Votes

SE/EE
Azul Systems, Inc.
Credit Suisse
Eclipse Foundation, Inc
Ericsson AB
Fujitsu Limited
Goldman Sachs & Co.
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
London Java Community
Oracle
Red Hat
SAP SE
SouJava
Twitter, Inc.
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

SE/EE
On 2012-03-05 Red Hat voted Abstain with the following comment:
Red Hat supports the technical aspects of this JSR and fully expects to be an active member of the technical committee, but after further investigation we are changing our vote to ABSTAIN and would like the following commented on/changed prior to the final approval vote:

The RI license terms associated with the web sockets jsr state:

7.  Fees, Royalties and Payments.
a)  Annual Fee. $35,000 per year for access to the Technology in Source Code form (Part. No. J2E88-UPD1-
A889), which can be obtained only if you have also ordered, or order concurrently, Part No. J2E88-TC4-A889 (to
license the Java API for Web Sockets 1.0 TCK).

This appears to be in conflict with the JCP 2.8 terms this JSR is governed by.

JCP 2.8 terms that I'll argue are violated include:
- "TCK license terms must permit implementors to freely and publicly discuss the testing process and detailed TCK test results with all interested parties."
- Allow the EC to assess the TCK quality per the guidelines in 4.2 FINAL APPROVAL BALLOT as one should not have to be a licensee to view the source code, and due to the desire for transparency to the community, non-EC members should be able to participate in assessing the TCK, and RI.

See, 
http://java.net/jira/browse/WEBSOCKET_SPEC-1
http://java.net/jira/browse/WEBSOCKET_SPEC-2

We hope that the licensing issues are resolved before this JSR comes up for final approval, or we will have to vote NO. Our abstaining at this stage should not be taken as implicit approval of the licensing terms currently associated with the JSR.
------------------------------------------------------------------------------
On 2012-02-22 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2012-03-04 Eclipse Foundation, Inc voted Yes with the following comment:
I would have preferred that this ballot be delayed to allow the TCK license discussion to continue. However, given that this is Review ballot, we will vote yes in the hopes that all concerns about the TCK license will be addressed by the Final ballot.
------------------------------------------------------------------------------
On 2012-03-04 Intel Corp. voted Yes with the following comment:
Voting YES to approve the JSR and the formation of an EG. It will be great if several concerns as pointed by other members are clarified as soon as possible. 
------------------------------------------------------------------------------
On 2012-03-04 Google Inc. voted No with the following comment:
It would appear that RedHat has some valid points. Google agrees that these point should be addressed before moving on to the next stage in the process.

------------------------------------------------------------------------------
On 2012-03-05 IBM voted Yes with the following comment:
IBM agrees that there is a need for a WebSocket JSR. However, we are concerned about how interop issues with such a new protocol may cause compliance testing problems for vendors attempting to implement this JSR. Therefore, we ask that extra care be taken when crafting the TCK for this JSR.
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 2012-03-05 Hewlett-Packard voted Yes with the following comment:
HP votes Yes on this JSR at this time, but agrees with other EC members that these license issues be addressed as soon as possible.
------------------------------------------------------------------------------
On 2012-03-05 SouJava voted Yes with the following comment:
SouJava considers that this JSR is an important one for the Java community. Although we agree that there are concerns about the TCK licensing raised by other EC members, the spec lead has came forward in the past few days and took important steps in starting to address the issues raised. We expect that this trend will continue, so we vote to approve the JSR to continue its course in the process.
------------------------------------------------------------------------------
On 2012-03-05 Fujitsu Limited voted Yes with the following comment:
Fujitsu's vote is based on the technical merits of this JSR, but not based on the licensing terms.

------------------------------------------------------------------------------
On 2012-03-03 Azul Systems, Inc. voted Yes with the following comment:
Voting YES to approve the JSR and the formation of an EG. However we have concerns that EG and EC work on the JSR may get stuck if some confidential information (such as the TCK per the proposed licensing terms) cannot be openly discussed in the JSR's relevant publicly readable forums. We will likely not be able to vote for final approval of this JSR without open, publicly readable discussion of any technical concerns raised by us or others around the the JSR materials, as required by the JCP 2.8 process. 

------------------------------------------------------------------------------
On 2012-03-05 Ericsson AB voted Yes with the following comment:
Support JSR and EG formation. Assuming concerns wrt TCK licensing as pointed out by several members will be sorted before moving this to the next stage.
------------------------------------------------------------------------------
On 2012-03-04 London Java Community voted Yes with the following comment:
The WebSockets JSR is seen by the LJC to be of significant interest to the developer community, and we are therefore voting to support the kick-off of this JSR. However, it seems to us that there are significant unresolved issues with regards to the TCK licensing terms, and possible conflict with JSR 348 / JCP 2.8. It is our opinion that these matters must be dealt with by the upcoming JSR to review IP matters within the JCP. 

If the issues related to this potential conflict are not satisfactorily resolved by the time that JSR 356 comes up for Final Approval Ballot, then the LJC will almost certainly vote NO on approval. We're confident that the possible conflicts here can be resolved, and we have no wish to hold up technical work on standards, but we should also not lose sight of the need to provide a resolution of the conflicts in a timely manner.
------------------------------------------------------------------------------
On 2012-03-05 Twitter, Inc. voted Abstain with the following comment:
We are fine with the technical merit of this proposal, however, we agree with Red Hat and would like to see the TCK licensing issues resolved before this is put up to vote, therefore we will abstain.
------------------------------------------------------------------------------
On 2012-02-21 Oracle voted Yes with no comment.
------------------------------------------------------------------------------