Wednesday, 17 November 2010

Java SE 7 and 8 JSRs published

Following yesterday's statements from Oracle and Apache, the meaty JSRs are now published and announced by Mark Reinhold.

I’m pleased to note the submission of four new Java Specification Requests to the Java Community Process:

* JSR 334: Small Enhancements to the Java Programming Language, by Joe Darcy with help from Jon Gibbons, Maurizio Cimadamore, and many others in Project Coin;
* JSR 335: Lambda Expressions for the Java Programming Language, by Brian Goetz with help from Alex Buckley, Maurizio, and others in Project Lambda;
* JSR 336: Java SE 7 Release Contents, for the enormous team effort that is JDK 7 (the first half of Plan B); and, finally,
* JSR 337: Java SE 8 Release Contents, for the eventual JDK 8 (the rest of Plan B).

These JSRs have been a long time coming. They’re now—finally—on the JCP Executive Committee ballot for approval; results should be available in two weeks.

My thanks to everyone who’s contributed to the related OpenJDK Projects.

Cool! Java is moving forward! And JSR-310 is proposed for Java SE 8!

But, lets take a peek at the interesting stuff... the licensing terms. (OK, its not really that interesting unless you want to understand the raging Java disputes...)

Firstly, the licenses are provided in Word Document format! (See section 2.18 of the JSR page for the links)

Its late here, so I only have limited time to evaluate the licenses. At first glance, the Specification and Reference Implementation licenses look fairly normal and bland (but I may be wrong). The interesting one is the TCK (testing kit) license.

I emphasise that this should be considered to be notes on the TCK license based on a relatively quick reading. If you read this blog and reference this topic/story in another blog or article, you are advised to read and examine the original license text yourself, or include a suitable caveat.

The famous "Field of Use" is an explicit part of the license:

1.4 "Exhibit A" means collectively Exhibits A-1 through A-n which incorporate into the Agreement the specific terms and conditions for each TCK licensed hereunder.

1.6 "Field of Use" means the relevant market segments for products tested by a particular TCK for a Java Environment Specification as specified in the applicable Exhibit A(s).

The "Java Environment Specification" is defined, covering Java SE:

1.8 "Java Environment(s) Specification" means a Java Specification that defines a baseline API set that provides a foundation upon which applications and other Java Specifications can be built. For example, and not by way of limitation, Java Environment Specifications include: (a) “Platform Editions” such as the Java Platform, Standard Edition ("Java SE"); Java Platform, Enterprise Edition (“Java EE”); and Java Platform, Micro Edition (“Java ME”) Specifications; (b) “Configurations” such as the Connected Device (“CDC”) and Connected Limited Device (“CLDC”) Configurations; and (c) “Profiles” such as the Mobile Information Device (“MIDP”) Profile.

The definition of a "product" contains what looks like an unusual part (highlighted). It appears that a "product" must meet three criteria beyond the basic ones:

  • "have a principal purpose which is substantially different from a stand-alone implementation of that specification"
  • "represent a significant functional and value enhancement over any stand-alone implementation of that specification"
  • "not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification"

I believe that Apache Harmony would fail all three of these tests (were the project to try and implement this JSR, which they probably won't). Since a "stand-alone implementation" would be either OpenJDK or OracleJDK, the principal purpose of Harmony is clearly the same (not substantially different), Harmony does not offer significant functional enhancement, and Harmony would be marketed as a replacement for OpenJDK/OracleJDK.

1.12 "Product(s)" means a Licensee product which: (i) fully implements the Java Specification(s) identified in Exhibit A including all its required interfaces and functionality; (ii) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields, methods or constructors within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (iii) passes the TCK (including satisfying the requirements of the applicable TCK Users Guide) for such Specification; and (iv) neither derives from nor includes any of Oracle’s source code or binary code materials which implement any portion of the Java Specification, except for code contributed by Oracle to an open source project (e.g. Apache’s “Tomcat” project) and that is rightfully (i.e. pursuant to a separate and appropriate license) included in the product to be tested. In addition, to be a Product, a Licensee product that implements a Java Environment Specification must: (a) have a principal purpose which is substantially different from a stand-alone implementation of that specification, while the value-added portion of the product operates in conjunction with the portion that implements the Java Environment Specification; (b) represent a significant functional and value enhancement over any stand-alone implementation of that specification; and (c) not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification.
(My highlights)

Criteria are given as to what not to do. This indicates that no one may distribute code that implements the specification unless it is part of a product, as defined above. Given Apache Harmony cannot be a product, it cannot be distributed.

(b) Additional Limitations. Except as otherwise set forth in Exhibit A, Licensee may not:
...
(v) distribute code which implements any portion of the Java Specification unless such code is included in a Product within the meaning of Section 1.12 and unless, for each new release of a Product by Licensee, such Product passes, in accordance with the Documentation (including the TCK Users Guide), the most current TCK applicable to the latest version of the Java Specification and available from Oracle one hundred twenty (120) days before FCS of such version of the Product; provided, however, that if Licensee elects to use a version of the TCK also provided by Oracle that is newer than that which is required under this Section 2.1(b)(v), then Licensee agrees to pass such TCK;
(My higlights)

Were a court case to challenge the contents of the license, Oracle can at its discretion terminate the licence.

11.4 Partial Invalidity. If any of the above provisions are held to be in violation of applicable law, void, or unenforceable in any jurisdiction, then such provisions are herewith waived or amended to the extent necessary for the Agreement to be otherwise enforceable in such jurisdiction. However, if in Oracle's opinion deletion or amendment of any provisions of the Agreement by operation of this paragraph unreasonably compromises the rights or increase the liabilities of Oracle or its licensors, Oracle reserves the right to terminate the Agreement.

And Exhibit A contains the actual "Field of Use" terms. These specifically exclude wireless mobile telephones, kiosks and even netbooks (highlighted). Remember that any Field of Use restriction violates the OSI open source definition.

EXHIBIT A
TECHNOLOGY SPECIFIC TERMS AND CONDITIONS

I. Description of TCK, Test Tools and Documentation

A. Java Specification: Java Platform, Standard Edition, version 7 (“Java SE 7”), which includes mandatory standalone elements to the extent described and permitted in the Java SE 7 specification and which includes optional elements to the extent described and permitted in the Java SE 7 specification
...
II. Field(s) of Use: Products for use on “General Purpose Desktop Computers and Servers" meaning computers, including desktop and laptop computers, or servers, used for general computing functions under end user control (such as but not specifically limited to email, general purpose Internet browsing, and office suite productivity tools). The use of Software in systems and solutions that provide dedicated functionality (other than as mentioned above) or designed for use in embedded or function-specific software applications, for example, but not limited to: Software embedded in or bundled with industrial control systems, wireless mobile telephones, wireless handheld devices, netbooks, kiosks, TV/STB, Blu-ray Disc devices, telematics and network control switching equipment, printers and storage management systems, and other related systems are excluded from this definition.
(My highlights)

The published release must contain a note from Oracle emphasising the conditions on further distribution:

1. The following provision is added as subparagraph (viii) to the Additional Limitations set forth in Section 2.1(b):

(viii) distribute Products unless accompanied by the following notice from Oracle, where the notice is displayed in a manner that anyone receiving the Product will see the notice:

NOTICE FROM ORACLE:
If you redistribute the software licensed hereunder (including derivative works thereof) for your direct or indirect commercial gain, then we are not authorized to grant or otherwise pass through to you any licenses under Oracle applicable intellectual property or other rights, if any, and as a result any such use is a violation of Oracle’s applicable rights. Any redistribution of the software licensed hereunder (including derivative works thereof) must be compatible and branded with the appropriate compliance logo specified by Oracle and licensed by Oracle to you pursuant to a separate Trademark License required to be executed by you with Oracle.

Redistribution of the software licensed hereunder must retain this notice.

The cost of the TCK is specified. And it is cheap. So, none of the dispute is directly about money (indirectly is another matter!).

A. For Commercial Licensees: $100,000.00 (as of the Effective Date) per year. All fees shall be due upon execution of this Agreement. In addition, Oracle shall have no obligation to deliver or make available the TCK until such fees are received by Oracle.

B. For Qualified Not-for-Profits and Qualified Individuals: $0.

And thats it. Well, at least the parts I see as being interesting. But if you want to comment on this, you really should read it yourself!

Sadly, at 3am, I don't have time to contrast the TCK license with the JSPA.

To be honest, I'm surprised that the TCK license for Java SE 7 still contains any pretence that it can be implemented in open source by anyone other than Oracle. At least the restrictions are clear (and I suspect, but cannot prove, that very similar restrictions were offered for Java SE 5 in the Sun/Oracle vs Harmony dispute).

I personally expect these 4 JSRs to pass the JCP Executive Committee vote in two weeks time as I see no evidence that committee members are still up for a fight. If the vote passes, I expect the ASF will immediately leave the JCP.

I will leave the biggest amusing point until last. The TCK license conflicts with the JSR! The JSR itself says:

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This JSR defines a release of the Java SE platform targeted at embedded, desktop, server, and cloud environments.
(My highlights)

So, the JSR is targetted at embedded environments! That's not what the TCK license says ;-)


Stephen Colebourne
Apache Software Foundation member, speaking personally
Oracle Java Champion, speaking personally
Not a committer on Harmony or OpenJDK

7 comments:

  1. We should have a vendor-neutral standards body to design Java standards and TCKs, not unlike the W3C/ISO.

    ReplyDelete
  2. Alkali, I was part of the ISO/ANSI standardization process for C++ in the 90s, and it was slooooow. It may be better now, but I really don't think we should go there. Besides, in ISO only countries can vote, and in ANSI only companies and individuals with a presence in the US (if I remember correctly). And ECMA is even worse, where only big elephant companies can play. The JCP was good in this respect, since it allowed anyone to participate, in theory. Sure, to get voting right in the EC's would need lots of votes from JCP members, but is possible for individuals, as we all know.

    I actually don't think we need the JCP anymore. Let Oracle, Apple and IBM do thier own dance with Java SE (JVM and core libs) and let everything else be done the Apache way. Much faster, much more democratic, and we don't need that monolithic fixed Java EE stack anymore anyway. Let it die! Open source tech runs circles around that dinosaur machinery.

    ReplyDelete
  3. Oracle is trying to becoming the next Apple, with is walled garden approach. Which in my opinion is bad for Java as a platform. Java's popularity and usefulness as a platform today is only because of open-source software, including from Apache, Spring and RedHat. None of the applications I have created, used or seen, was based on pure Java SDK. It just can't be.

    Oracle's tight-grip over the Java platform, I fear, might destroy the community and give rise to other platform's. Sadly, there is none other cross-environment platform available.

    I am not a legal guy, but is it possible to fork a new platform using the same syntax (thus existing code being compatible) but with a total different VM which would compile to a different binary.

    Sad to see some lawyers decide the fate of Java :(

    ReplyDelete
  4. About your last point: the embedded simply refers to "Java SE for Embedded".

    ReplyDelete
  5. Well at least you didn't go snooping through anyone's LinkedIn profiles for this post.

    But, seriously, thank you for the analysis. It is very useful. I think we're in for it, but, selfishly, I just want Java 7 released. I'm sick of the struggle.

    ReplyDelete
  6. On the JSR page, there is a link to volunteer to be on the committee (see http://jcp.org/en/jsr/egnom?id=336) . Perhaps someone like Apache should join the EC and make some changes.

    I still believe TCK and RI should be separated from a JSR. Have a "test spec" with all necessary test cases define instead of an actual implementation of anything. Then anyone can write an RI and/or TCK, avoiding any restrictions presently in play.

    At the very least, maybe change any reference from Oracle to the JCP organization.

    I'm interested how the items on platform restrictions relates to the EE Profiles (Web, etc).

    ReplyDelete
  7. Hi Stephen,

    considering recent Oracle's actions and people like Bob Lee declining to do further work for Oracle what is the status of JSR-310?

    Do we have to expect a "sudden" change of leadership or even the closure of the project? :-)

    I guess most people would fully understand it, if your motivation to work on JSR-310 decreased in the last few weeks.

    ReplyDelete