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 #237
Work Manager for Application Servers
JSR Review Ballot
Ballot duration: 2003-12-02 to: 2003-12-15

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

Votes

SE/EE

Apache Software Foundation

Apple Computer, Inc.

BEA Systems

Borland Software Corporation

Caldera Systems

Fujitsu Limited

Hewlett-Packard

IBM

Lea, Doug

Macromedia, Inc.

Monson-Haefel, Richard

Nokia Networks

Oracle

Progress Software

SAP SE

Sun Microsystems, Inc.

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

SE/EE

On 2003-12-04 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-04 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-11 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-12 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-15 Nokia Networks voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-15 Macromedia, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-15 Borland Software Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-15 Sun Microsystems, Inc. voted Yes with the following comment:
The licenses contained in the JSR submission had a number
of problems.  Sun would like to thank the spec leads for
acknowledging the issues and agreeing to resolve them.

Sun would also like to thank the spec leads for their
constructive discussions on the relationship between this
new JSR and the existing JSR-166, and for their willingness
to attempt to base this JSR on the JSR-166 APIs.


------------------------------------------------------------------------------
On 2003-12-15 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-15 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-15 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2003-12-15 Oracle voted Yes with the following comment:
We believe that this JSR should reuse JSR-166 APIs and not invent new APIs.  If a generic solution across J2EE cannot be formulated, then we believe that the individual container specifications should address the problem.

While voting to support the technical work in this JSR, Oracle is concerned about the manner in which it was  introduced into the JCP.   IBM and BEA, by publishing specifications and publicly committing to implement them as published in the very near term, are dramatically altering the JCPs normal mode of operation; instead of working with major stakeholders to develop a consensus specification, they are imposing on the community their preferred approach and trying with their combined market shares to assure its adoption.    

Oracle also has concern about the proposed licensing approach.  We appreciate IBM and BEAs willingness to revise and clarify the licenses, especially to remove any wording that could be construed as viral and to specify the commercial terms that will apply when the RF option is not chosen.  However, we have questions about several aspects of the new licensing approach that we believe require more thorough consideration.  These include questions such as:

1. Should the RF commitment be more symmetrical?  That is, if Oracle commits to provide RF terms on all future JSRs for which we serve as specification lead, should IBM and BEA make some similar commitment to offer RF terms on their future JSRs as well?

2. If the proposed licensing approach becomes wide spread, is there a potential for conflicting commitments?

3. Will the availability of the RF option result in the commercial terms getting insufficient review?  

4. Will the availability of the RF option result in fewer organizations willing to take on the role of specification lead?

------------------------------------------------------------------------------
On 2003-12-15 Apache Software Foundation voted Yes with the following comment:
Apache appreciates the clairifications provided for the licensing for this JSR.  We also appreciate the notion of encouraging free licensing via example, but do worry about the implications.  We'd like to see the license terms revised to clearly indicate no virality involving third parties, and an extension of the terms to provide symmetry - if IBM licenses TCK to Company X for no cost, and Company X then must license all subsequent TCKs to IBM at no cost, then any further TCKs by IBM are available to Company X at no cost... 

Finally, thank you for all the efforts on techniical clarification wrt JSR 166.

------------------------------------------------------------------------------
On 2003-12-15 Monson-Haefel, Richard voted Yes with the following comment:
While I support the technical goals of this specification, I'm concerned about the license.  I look forward to seeing the revised license that includes commercial licensing terms and clarification on the free license ... specifically the viral qualities of the free license. Free is good, but quid pro quo clauses should be limited to the signing parties.

In addition, I'm looking forward to seeing an alignment between this JSR and JSR-166.
------------------------------------------------------------------------------