"Not to go back is somewhat to advance, and men must walk, at least, before they dance."

In my last entry I wrote about Sun's plans to open source their Java implementation, and my speculation about the how? and why? that would happen. Lo and behold, last week there was an announcement that gives many of the details of their open source Java actions and plans.

Sun are re-licensing some of their code under GPLv2 with the 'Classpath exception', and some code under GPLv2 unmodified, into a new project called OpenJDK. The motive appears to be as I predicted -- making Java a viable option as a managed runtime environment on Linux.

The choice of GPLv2 ensures that the license is a non-issue for distributing OpenJDK unmodified with Linux. That said, I have not seen any distro balk at the Apache license for httpd, so there is more to it than that. The 'Classpath exception' is an instrument designed to alleviate the fear that Java applications will be subject to the so-called 'viral' effects of the GPL. This is because it is ambiguous, in some people's eyes, whether Java application code "in whole or in part contains or is derived from" the system code at runtime. The intent is to make the situation for Java equivalent to the goal of the LGPL for dynamic libraries.

The code that has been given the linking exception includes the Java SE APIs, and interestingly the Java EE APIs (which now become dual licenced with CDDL). The Java ME class library, JVM, javac, and JavaHelp code do not enjoy the linking exception.

By drawing the distinction between some code that has the linking exception, and some that doesn't, Sun seem to be acknowledging that Java application code is 'linked' to the system code as described above, and therefore is subject to the viral effects of GPL without the benefit of the exception.

It would appear that Sun recognize the value of Java SE and Java EE as a platform, and the network-effect of a pervasive platform enhances the opportunity to make money indirectly, through services etc. I would argue that Sun could have identified areas of competitive value, say in the VM and JIT, that would play to particular hardware and OS strengths, and been more permissive of ongoing commercial investment in these areas around a shared 'commons'. That would be an opportunity for OpenJDK to compete on performance, reliability, scalability, etc. to the overall benefit of the Java ecosystem; whilst providing a viable open source VM for those that do not choose to pay for the vendors' enhancements. As vendors of these proprietary technologies determine they are no longer providing distinguishing value in these areas, the technology will flow into 'the commons' and the technology moves up a step.

I hope the choice of GPL doesn't stifle such competition and investment in Java, or serve to fracture the Java implementation space and introduce compatibility issues. I'm sure you appreciate that many of the performance advances in those no-cost Java runtimes you have been downloading have been made on the back on the commercial vendors. Competition is good. For now at least, Sun are effectively saying that such competition comes at the cost of a commercial license to the reference implementation codebase.

The stick for compatibility seems to be the JCK test suite. There have been a number of references to threats that people will find themselves in court if they fork the GPL code and try to call it Java without passing the JCK. It's not clear what the future terms of the JCK-availability will be for such forked projects, but I expect that Sun will keep tight control over it. It's unclear to me again how this situation works for distros that build the OpenJDK source to work well with the packages they distribute, or people who innovate in this space -- I hope we do not end up with an equivalent to IceWeasel for Java.

Sun appear to have taken a different approach to Java ME. By explicitly excluding the linking exception for Java ME they are requiring applications and network provider stacks to be GPL'd. Of course, that's not going to happen, so Sun are effectively telling Java ME licenses that it will be business as usual for them, period.

Sun need to maintain the 'business as usual' rule for ME, SE, and EE -- at least for the moment. It is totally understandable that Sun would not compromise their commercial licensing opportunities for their Java implementation. In fact, as a publicly traded company I believe that they could not have compromised that revenue stream. Such companies are obliged to maximize shareholder value. So to maintain that commercial license stream Sun have also specified a contributor agreement for code offered to the OpenJDK project.

The contributor agreement requires that you:

• assign joint ownership of the code to Sun, in copyright and all other relevant intellectual property rights,
• grant a royalty-free, sub-licenseable, patent grant to any inventions embodied in the code,
• allow Sun to use your code in other licensing mechanisms, at Sun's option.

Hmm, that seems a bit one sided doesn't it? Where's Sun's patent non-assertion covenant, or royalty free-licence granted to consumers of the OpenJDK code? What about all the code that has been granted to Sun over the years and included into the reference implementation?

I'm surprised that we haven't heard more about this agreement from the Free Software movement who applauded Sun's choice of GPL. Doesn't FLOSS mean that such code rights should not be granted to a for-profit corporation that reserve the rights to exploit it for commercial gain? Presumably such potential exploitation for commercial gain is ok provided that I can get the code under GPL? And what about the GNU Classpath folk who signed their copyright over to the FSF? It is unlikely that the FSF are going to enter into such an agreement with Sun, so is there a channel for any code in GNU Classpath to make it into the OpenJDK?

Very little has been written about the community that will exist in OpenJDK. Sun are, of course, eager to get as many contributors as possible, and in the future expect to allow members of that community to gain commit rights to the OpenJDK source code. But it has been made clear that the bar has been set very high. Sun cannot allow any opportunity for instability or poor engineering to creep into the reference implementation. So for the moment, all contributions will go through Sun engineers, and the Sun development process to ensure the required quality and standards are maintained. As such it seems very similar to the "JDK-Collaboration" project, only you don't get the T-shirt!

So to wrap up, the first steps have been taken. The OpenJDK implementation is rolling out into a new project. It remains to be seen how the community is built and the effects on the existing open source Java community, the effects on the JCP, and the reaction of the commercial Java implementers.

I'm delighted to see the OpenJDK project take it's first steps. Now let's see this baby dance!