JSR 316, Java EE 6 Spec, Approved with Reservations
by Tim O'Brien
IBM voted yes with a 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.
Intel also made a similar statement:
The Spec Lead has told us there are no "field of use restrictions" on implementations for this particular JSR. The Apache open letter about Java SE (http://www.apache.org/jcp/sunopenletter.html) claimed that a confidential license for a required JCP test suite restricts how Independent Implementations of that JCP spec can be used. Licenses to test for JCP compatibility must not be used to limit or restrict competing, compatible implementations; licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates. For every JCP ballot, we will ask the Spec Lead whether such restrictions exist in their license.
Red Hat filed a similar comment along with a YES vote. Note the emphasis:
The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no "field of use restrictions", as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.
However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.
Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.
And Apache voted NO with the following comment:
The Apache Software Foundation's vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA
and therefore shouldn't be allowed to start another JSR until the above matter is resolved.
This vote is not a comment on the technical merits of the JSR. If not for the issue of the spec lead, the ASF would have otherwise voted "yes".
From the jcp-open list at the ASF, Geir Magnusson's from the 15th:
I'd like to vote "no" simply on the grounds that from our point of
view, this spec lead - Sun - is in violation of the JSPA, and
therefore we don't think they should be allowed to start another JSR
until the matter is cleared up
"we don't think they should be allowed to start another JSR
until the matter is cleared up "
Read: We want to stifle the JCP unless and until control over it is signed over to us and our corporate sponsors.
|@JT Wenting, hmmmm... not really, JT Wenting, do you have any idea what a Field of Use restriction is?|
Interesting post, but haven't IBM posted the same comment on all their yes votes for a long time now: http://www.infoq.com/news/2006/11/ibm-response-os-java
Andrew, the issue is not about the GPL, it is about
restricting effectively what can the software certified
used for (Field of Use restrictions). This is something
that, as far as I can tell, violates the GPL too. Sun, according to Rich Green recent post, will accept
any certified GPL implementation so long as it is *the ONE OpenJDK *they host. No other GPL codebase will be allowed to be certified. This includes, as far as I can tell, GCJ or kaffe. Correct me if I'm wrong.