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 #321
Trusted Computing API for Java^TM
Final Approval Ballot
Ballot duration: 2011-11-15 to: 2011-11-28

These are the final results of the Final Approval Ballot for JSR #321. 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 2011-11-23 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-11-25 Credit Suisse voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-11-26 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-11-28 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-11-28 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-11-28 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-11-28 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-11-28 SouJava voted Yes with the following comment:
The usage of open source licensing terms for both the RI and the TCK in this JSR is something to look for in future evolutions of the JCP process.
------------------------------------------------------------------------------
On 2011-11-28 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-11-28 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.

At this stage, with JSR 348 accepted, we would also encourage the submitters to consider strongly adopting the practices enshrined within that effort.
------------------------------------------------------------------------------
On 2011-11-28 Twitter, Inc. voted Yes with the following comment:
Twitter votes yes on this JSR, although we do understand the concerns raised by IBM in the previous ballot regarding the API reliance on SHA-1 and RSA keys.We feel though that having a working specification now is beneficial to the Java ecosystem independent of these issues.
------------------------------------------------------------------------------
On 2011-11-27 London Java Community voted Yes with the following comment:
The LJC's general voting criteria can be found at: http://londonjavacommunity.wordpress.com/2011/11/08/what-we-look-for-in-a-jsr/ 

JSR-321 is fairly transparent (open wiki, good documentation, RI and TCK available) but lacks in some areas (no observers alias mailing list, no public issue tracking). This JSR is run under JCP 2.7 and it is not obliged to meet the transparency goals of JSR-348. However, we feel that a good JSR should run an open observers mailing list (i.e. a read only copy of the EG mailing list) so that potential participants can see why technical decisions were made. 

The LJC does not have direct expertise in this area but does note that this is effectively a re-implementation of the Trusted Software Stack in the C standards space. This stack is used fairly widely and so it indicates that there is a need for a Java compliant standard in the same space. There are not a lot of competing Java implementations, but the EG has based the RI off the lessons learned from the C standard and we think this is a good thing.

------------------------------------------------------------------------------
On 2011-11-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.
------------------------------------------------------------------------------