Alex headshot

AlBlue’s Blog

Macs, Modularity and More

JEE 6 Approved, but licensing issues remain

2009, java

JEE 6 (JSR 316) has been approved by the SE/EE committee. However, it's telling that the JCP itself is under more fire rather than the technical content of what the JSRs are aiming to provide.

There has been a long-standing dispute between the Apache foundation and Sun, spurred on by the licensing constraints relating to the Java TCK (testing compatibility kit). This has been going on since April 10, 2007 and still doesn't seem to have been resolved satisfactorily.

As a result, the Apache foundation voted against the JCP, with the following:

The Apache Software Foundation's vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA

http://www.apache.org/jcp/sunopenletter.html

and therefore shouldn't be allowed to lead other JSRs 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".

This makes the first JSR that has had a negative vote - the last one for JEE 5 was approved by all. And, despite Apache's stance, there are others voicing their concern as well. SAP abstained with the vote with:

SAP had welcomed the changes made to the Java Community Process where "Spec Leads must provide complete copies of the licenses that they intend to use, not simply a summary of some of the terms" (quote from the JCP Process document http://www.jcp.org/en/procedures/jcp2). This change to the process had promised to create transparency about the licensing of Java in order to prevent that Java is used for unfair business advantage against any particular party in the marketplace.

However, we are disappointed that Sun Microsystems as the Spec Lead of the Java EE 6 specification has not managed to produce the promised "full license terms" of the Java EE 6 TCK until the begin of the two week voting window for Java EE 6. Given the complexity of this license, we are unfortunately not in a position to complete a thorough legal review. At a minimum, we would expect that the TCK is not used to prevent access to the Java marketplace, including open source implementations. This JSR has been filed in July 2007; we believe there would have been ample time to share and discuss the proposed full license terms with the community.

Regrettable [sic], we will therefore have to abstain from the Java EE 6 vote. This is not a statement about the technical merits of the underlying JSRs on which we have voted separately, but rather a reflection on the transparency and efficiency of the licensing process managed by Sun as the owner of the Java Community Process related to intellectual property critical for today’s IT landscapes.

IBM also chose to use this opportunity to comment on the licensing issues; having said that, it made much the same comment for JEE 5 as well:

With the exception of the JSR 330 and JSR 299 injection support defined by the EE 6 platform, we believe that this new specification brings value to the industry. We remain concerned that the injection support defined by the platform will create unnecessary difficulties for the community. IBM will continue to support both expert groups in the development of a single integrated and extensible injection programming model.

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 observed that the JSR wasn't well handled, although it didn't have an issue with the technical spec.

It remains to be seen whether Oracle can salvage any respect for the JCP, or whether it will replace the process with something more open. Indeed, this has already been done for Project Jigsaw, which notionally has JSR 294 associated with it but that in fact, all the work is being done externally with little to no discussion on the expert mailing list group. Maybe the JCP has made itself irrelevant?