These are the final results of the Final Approval Ballot for JSR #291. The Executive Committee for SE/EE has approved this ballot.
JSR291
StageFinal Approval Ballot
Ballot durationMay 8, 2007 to May 21, 2007
Votes

SE/EE

Apache Software Foundation
BEA Systems
Borland Software Corporation
Fujitsu Limited
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
Lea, Doug
Nortel
Oracle
Red Hat
SAP SE
SAS Institute Inc.
Suleiman, Hani
Sun Microsystems, Inc.
Vote Log

SE/EE

On 2007-05-15 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-05-15 Sun Microsystems, Inc. voted No with the following comment:
Sun's vote is not a negative assessment of the OSGi specification or technology, but rather on the purpose of this JSR and expert group when the specification exists and is being actively developed elsewhere.

The JSR 291 specification is simply a reference to the OSGi Core spec version r4. No other specification work has been created in the context of the JCP JSR 291 expert group. Rather the work to update the r4 spec occurred in the OSGi working group.

This manner of working contradicts the goals of the JCP to create expert groups empowered to evolve Java technology with the freedom to make design choices and technical decisions based on the needs of the Java Community. Sun has consistently expressed these concerns, as have other community members, throughout the lifetime of the JSR as our previous voting comments show.

Since these concerns been not addressed by the spec lead, either at the inception ballot or at the public review ballot, we are reluctantly voting no.

------------------------------------------------------------------------------
On 2007-05-15 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-05-15 BEA Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-05-15 Suleiman, Hani voted No with the following comment:
I do not believe that the JCP's role should be to rubberstamp existing specifications just for the sake of giving them a JSR number. These concerns as well as the lack of any meaningful work by the Expert Group  have all been expressed previously and have resulted in a no vote. I am forced to vote no again since nothing has changed since.
------------------------------------------------------------------------------
On 2007-05-15 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-05-16 SAS Institute Inc. voted Yes with the following comment:
OSGi is an important standard that is widely in use today in production Java environments. As such, ensuring interoperability between Java and OSGi is critical. This expert group has helped to raise awareness of the technical interoperability issues and has served to develop necessary communication channels between the Java and OSGi communities, in a way that strengthens both.

This yes vote is for both the technology and the model of cooperation that has been demonstrated. The JCP Executive Committee should nurture such cooperative efforts and not downplay their importance.
------------------------------------------------------------------------------
On 2007-05-18 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-05-18 Nortel voted Yes with the following comment:
We do believe that JCP should play key role in bridging the technologies developed withing the non-Java worlds and Java community. Even though we understand and recognize the concerns raised within the JCP regarding this JSR, one cannot reject that this JSR brings out the relationship and alliances, which are required to empower Java to leverage other technologies. 

This JSR is demonstrates, how the work done by other technical bodies can be incorporated to strengthen Java. It is not about just giving a rubber stamped JSR number, but providing a channel to leverage and enhance the interoprability with other non-java concepts. JCP EC should continue promoting similar alliances, instead of rejecting concepts just because it was not invented or enhanced by Java community.
------------------------------------------------------------------------------
On 2007-05-21 Red Hat voted Yes with no comment.
------------------------------------------------------------------------------
On 2007-05-21 Apache Software Foundation voted Yes with the following comment:
Apache votes YES with the condition that the spec lead will include the corrected TCK license - as found at http://www2.osgi.org/JSR291/TCK - in the final TCK package.  In addition, the ASF would like to thank the spec lead for the clear, simple and JSPA-compliant spec and TCK licenses, and strongly urge other spec leads to follow this example.  In order to deliver on the promise that the JCP creates "open specifications", the ASF requires spec leads to commit to specification and TCK  licenses that do not restrict the downstream licenses of tested, compatible implementations.  In particular, no "Field of Use", shared code, or other restrictions can appear in a TCK license that would prevent a compatible independent implementation of a Java specification
from being distributed under the Apache License.
------------------------------------------------------------------------------
On 2007-05-21 Borland Software Corporation voted Yes with the following comment:
As Borland / CodeGear rose at the time of accepting this for review, we continue to be concerned about the relationship between JSR-277 and JSR-291. 
We recognize the importance and wide use of OSGI and hence vote yes. However, a java platform module system and OSGI module system shouldn't end up competing module systems. They should rather build on each other. 

As a tools vendor, we very much focus on the complexity of the Java platform and believe having two un-integrated module systems will not serve the Java community well. 

So, we urge that the two JSR teams work together in the Java 7 time-frame.

------------------------------------------------------------------------------
On 2007-05-21 Intel Corp. voted Yes with the following comment:
We are concerned about the issue of field of use restrictions raised in the Apache Open Letter on Java SE TCK Licensing.  For this JSR, the TCK License can be viewed by anyone interested and there is no issue.

The rest of this comment describes a general procedure we employ for all JSRs.  We think the best approach is to make at least one alternative for the required licenses publicly viewable so that the community knows what is required to implement a spec. 

If there is not an alternative in which all licenses required to implement the specification are publicly viewable, we intend to ask the Spec Lead for confirmation that at least one alternative "does not impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations" other than the compatibility and reciprocity conditions described in the JSPA.  In particular, we intend to ask for confirmation that at least one alternative does not limit field of use of a compatible implementation (e.g. prohibit or charge royalties for distributing for use on particular operating systems or particular devices or for use in particular environments or require implementation of features other than what is required in the spec).

------------------------------------------------------------------------------
On 2007-05-21 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------