These are the final results of the Final Approval Ballot for JSR #271. The Executive Committee for ME has approved this ballot.
JSR271
StageFinal Approval Ballot
Ballot durationNov 17, 2009 to Nov 30, 2009
Votes

ME

Aplix Corporation
AT&T
IBM
Nokia Corporation
Orange France SA
Research In Motion, LTD (RIM)
Samsung Electronics Corporation
Sheedy, Sean
Siemens AG
SK Telecom Co., Ltd.
Sony Ericsson Mobile Communications AB
Sun Microsystems, Inc.
T-Mobile
Time Warner Cable Inc.
Vodafone Group Services Limited
Vote Log

ME

On 2009-11-27 T-Mobile voted Yes with the following comment:
This is a great & necessary achievement for the Java ME area. 
Many thanks to the spec leads for their passion in managing a large EG. 
------------------------------------------------------------------------------
On 2009-11-17 SK Telecom Co., Ltd. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-30 Sony Ericsson Mobile Communications AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-30 Vodafone Group Services Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-18 Orange France SA voted Yes with the following comment:
Orange congratulates Motorola and Aplix for this highly expected finalization. We are now eager to see the devices.
------------------------------------------------------------------------------
On 2009-11-29 Samsung Electronics Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-22 AT&T voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-24 Aplix Corporation voted Yes with the following comment:
This is from Brian Deuser (MIDP3 spec lead) I thought it should be recorded. Since we argee with what he wrote we decide to enter it as our comments.

I have been asked a few questions regarding the TCK license for MIDP 3.0, and if you'll all bear with me, I'd like to hopefully clarify:

As indicated in the MIDP 3.0 TCK LTR AGR FINAL.doc, a Letter Agreement must be signed and accepted by Aplix in order to obtain access to the MIDP 3.0 TCK.  Upon acceptance of the Letter Agreement, the conditions of the Apache Software License v2.0 apply.  Derivative works, commercial and otherwise, are possible.  The Letter governs your relationship to the TCK Licensor and the ASL governs how you may use the TCK.

The bulk of the Letter Agreement works like this:  
If you/your company does not license a JSR TCK, simply sign and agree to the Letter and obtain the TCK at zero cost following the terms in the ASL.

If you/your company does license any Java ME JSR TCKs, you may obtain the MIDP 3.0 TCK a zero cost under the ASL provided your TCKs are reciprocally offered to Aplix as follows:
* No extra conditions are placed on an Independent Implementation by using the TCK outside the scope of the Specification License terms for Independent Implementations.
* No per unit royalties payments are required.
* No more restrictions (or less) will be offered to Aplix.
* Payment for each TCK shall not exceed $50,000/yr.
* No more than usual & customary terms for the TCK are given.

I apologize & take full responsibility for any confusion these terms have caused.

Apart from Thursday's Thanksgiving holiday, I remain available for further inquiries.

- Brian Deuser
------------------------------------------------------------------------------
On 2009-11-18 Sheedy, Sean voted Yes with the following comment:
Congratulations on the completion of this key JSR.  MIDP3 provides a necessary and critical update of the Java ME platform.
------------------------------------------------------------------------------
On 2009-11-23 Sun Microsystems, Inc. voted Abstain with the following comment:
Sun Microsystems vote to abstain follows from two very serious concerns we have with Aplix' proposed TCK license terms.

1. Aplix proposes to create a confusing hybrid of the Apache license with its letter agreement dictating asymmetrical "reciprocity."  But the terms and conditions, and objectives, of the Apache license -- which is used by many Spec Lead companies for licensing out RIs and TCKs -- seem at odds with those of the letter agreement, and it is not at all clear whether the two agreements could be interpreted together in a way that makes any sense. Moreover, the license appears to
require carte blanche for any independent implementation governed by a TCK license offered to Aplix, without regard to its compatibility
status. This approach would both undermine compatibility and set up conflicts with the existing provisions of the JSPA concerning independent implementations.

2.  The JSPA calls for the Spec Lead to make the TCK available for license on a standalone basis on terms that are fair, reasonable and non-discriminatory. Subject to that standard, the Spec Lead is given considerable discretion in determining the particular terms under which it will license the TCK.  This discretion reflects the community's longstanding view, and one debated at length by the entire EC, that the unique set of circumstances bearing on a particular TCK -- be they the method or costs of development, market conditions or other distinctive factors -- make it unwise to dictate the same terms for every TCK.  But for the MIDP3 TCK, Aplix proposes to condition the availability of Aplix' license on Aplix' unilateral assertion of what terms cannot be included in every other TCK that is offered for license to Aplix, now and in the future. The asymmetry of this approach, tying one to the many, invites a multi-party, ongoing battle of the forms that holds the adoption of important Java technologies hostage to rectifying last week's particular grievance. It has implications far beyond just the MIDP3 TCK, and sets a very bad precedent.

------------------------------------------------------------------------------
On 2009-11-30 IBM voted Yes with the following comment:
I don't think this JSR goes far enough in addressing the needs of today's smartphone applications, especially in light of some of the competing platforms being offered today. For instance, a JME CDC/Foundation profile would be more appropriate for providing the level of base platform functionality now expected by developers. Also, the inclusion of SOA (such as from JSR 232) would provide component dynamicism and manageability currently missing from the spec. However, I don't want to stand in the way of making at least some progress in the JME space. IBM voted YES on this JSR with the expectation that changes will be implemented to ensure the JSR Spec and RI licenses are consistent with the terms of the JSPA.
------------------------------------------------------------------------------
On 2009-11-30 Time Warner Cable Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-30 Siemens AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-30 Research In Motion, LTD (RIM) voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-11-30 Nokia Corporation voted Yes with no comment.
------------------------------------------------------------------------------