New JCK license

Yesterday Sun announced a new license for the Java Compatibility Kit. I’m looking at this with a happy and a sad eye. At first sight this looks like a good move: It will allow OpenJDK derivatives (like IcedTea) and distributors of OpenJDK (i.e. Linux distros) to test for compatibility and to obtain the ‘Java compatible’ sticker. Furthermore, it seemingly encourages free software implementations of Java. Only VMs that are distributable under the GPL can obtain this license. Commercial vendors still have to pay for the commercial JCK license. So far so good.

The license comes with two major conditions: It can only be applied to VMs that are GPL-distributable and it has to be substantially derived from OpenJDK. This excludes all non-GPL or non-OpenJDK-derived VMs, for example Kaffe (=not (yet) OpenJDK derived) or Apache Harmony (neither OpenJDK derived nor GPL). I think that this is a bad decision by Sun. It makes Sun’s moves look as if the liberation of the JDK was basically a reaction to the Apache Harmony project (read: Intel and IBM). I understand that Sun has business interests like every other company, but I don’t think it’s a good idea to split the free Java community in 1st and 2nd class citizens. And I don’t think that this is in the spirit of the JCP. And btw, I don’t even think it is in Sun’s business interest to slap Harmony in the face. A free Java ecosystem that includes everybody would be so much more powerful than a fragmented one.


About Roman Kennke
JVM Hacker, Principal Software Engineer at Red Hat's OpenJDK team, Shenandoah GC project lead, Java Champion

4 Responses to New JCK license

  1. Simon Phipps says:

    The “substantially derived” requirement doesn’t mean all the code has to come from OpenJDK. And Kaffe (etc) couldn’t take the JCK without some class libraries. But if you combined Kaffe with the OpenJDK class libraries, or Classpath with Hotspot, both would form a project that was “substantially derived” from OpenJDK and thus able to use the OpenJDK JCK.

    I’d also suggest that looking at this move as “providing a JCK for OpenJDK” makes it easier to understand what’s going on. There are so many options for open source licensing and governance that we couldn’t work out how to make a general-case TCK license and also guarantee the ability to enforce compatibility and the ability to do business with commercial vendors who don’t like the GPL. As a consequence we’ve just written one for OpenJDK and left the rest of the situation (including scholarships to the commercial JCK) available.

    I regret that we couldn’t satisfy everyone wanting a JCK on their own terms, but the positive news is that we now have a path for a full, Free JDK that can be certified compatible and deployed everywhere. Remember, if you don’t like what Sun is doing you genuinely can take the code elsewhere and since that new project is also “substantially derived”, still use the JCK.

  2. roman says:

    Thanks Simon. Yeah I see it as ‘providing a JCK for OpenJDK’ and I still think it’s a good move, but if I were an Apache Harmony developer I would feel _very_ pissed by Sun. Fortunately I am not 🙂

  3. Stefan Qauder says:

    From where I sit (outside of GJC, Classpath, OpenJDK and Harmony, just an application developer) it looks like a deliberate narrow-minded attempt by Sun to finally kill of GJC + Classpath and Harmony.

    I understand that it is a good idea to prohibit someone to claim “Java compatibility” if there isn’t.

    I don’t understand the idea to hinder someone who’s implementation might be compatible to check how much is still missing, and once there is nothing missing to claim “Java compatibility”.

    Compatibility is not a function of VM license, library license or origin of code. Compatibility is a function of deviation from specification, or (in Sun’s case) apparently correctness of results when executing sample code.

    I do understand why Sun fears that someone tinkers with the TCK code to fake compatibility.

    I don’t understand why Sun says this is the reason for not releasing the source code. Sun anyhow exercises control over the “Java compatibility” label. There isn’t a difference between someone faking compatibility and someone not even running the tests and just claiming compatibility. In both cases a test run with an original test set reveals the blunder. In both cases Sun can withdraw the “Java compatibility” label on the ground of their trademark ownership.

    As a Java application developer I need more compatible JREs on more platforms, not less. I need choices and alternatives.

    From where I sit it smells. Another useless fight. It hurts everyone in Java land. Sun, Apache, GNU and all the bread-and-butter Java developers out there.

  4. Simon Phipps says:

    Stefan: This is far from an attempt to sniff out the work Roman, Dalibor, Mark and others have done. Your view is not shared by any Classpath developer I have spoken to yet.

    All Sun is doing is making sure that OpenJDK can have a JCK; in the process, it was also possible to make the terms flexible enough to allow Classpath and the various Free VMs to also be combined with OpenJDK code as a path to the JCK.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: