"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!

Sun's plans to open source their Java implementation

When you talk about "Java(tm)" what exactly do you mean?

Are you referring to the Java language? the tools in the Java runtime and development environments? or the Java VM and class library specifications (such as JEE, JSE and JME)?

Maybe you mean the eco-system that has grown up around Java, such as world-class web containers, databases, scripting languages, and so on.

The term "Java" means different things to different people. I believe that most people understand that there are many diverse interests within the general community that develop and use applications written in the Java language. I believe that people understand you can get different implementations of application servers and IDE's that have different characteristics and design points. Most people probably know that you can get Java SE implementations from companies other than Sun, such as IBM and BEA who create work derived from Sun's under license. So when Sun says it is going to 'open source Java', we should understand what that means.

Sun plan to open source their implementation of the Java SE and ME specifications (they already open sourced their Java EE implementation as Project GlassFish.) This is a big deal. Sun's implementation is the reference implementation of the specification, and is the implementation that most people have installed on their desktop. Making the implementation open source, under an OSI-approved license as promised by Sun, means that people will have rights and freedoms that they currently don't have, and this is to be applauded.

A large part of the value of Java is its universality. Java is available on lots of platforms, and many interests are represented in the evolution of the specifications through the JCP. It is in the interests of all Java users that implementations are both compliant to the specifications and compatible with each other, so that Java applications really do 'run anywhere'. Apache Harmony is committed to producing a compliant and compatible implementation of Java SE for just such reasons.

So I'm left wondering why Sun have decided to open source their implementation? I don't think I can answer that question until we hear exactly how it will be opened. It comes down to the community model, and the code license and contributor agreement.

Turning to the license first. I mentioned that Sun have promised that the code will be made available under an OSI-approved license, but that still leaves a wide latitude of conditions for adopting and developing the code. It would seem from press coverage and common sense that the principle candidates are CDDL and GPLv2. The decision will come down to the type of community that Sun are trying to attract.

From my reading I believe that Sun are principally intending to make Java SE and ME open source in order to make it more acceptable to Linux distributors, and thereby increase the relevance of Java in that open OS space. I accept that Sun have already made moves to improve Java's acceptance by Linux distros by introducing the Distro Licence for Java (DLJ), but that hasn't been universally welcomed, attracting criticisms from one of the main Linux distributors for not going far enough.

Listening to some of the well-respected individuals at Sun I find it hard to believe that they really will trust the reference implementations of ME and SE to an open source community, where 'community' is defined in terms that you and I would generally understand it. I think development of Sun's implementation will continue as a principally in-house activity, with increased visibility to the changes that are being made to the code, but with very little opportunity for outsiders to earn rights to modify the code directly. The offer of such rights will be there, but the bar will be extremely high, and any contributions that are made will be under a contributor agreement with Sun that gives them copyright assignment rights so they can continue to license the code to companies such as IBM and BEA as I mentioned earlier.

The principal reason Sun are open sourcing the code is therefore to make it more acceptable to the Linux community. My prediction is that Sun will choose GPLv2, with a contributor agreement assigning significant relicensing rights to Sun for code going into the mainstream codebase, and the community around that mainstream will remain very tightly controlled for the foreseeable future. Any fork of the mainstream code will have to pass the appropriate TCK in order to be called Java, and we know that the TCK's are not being opened, so Sun still retain the control point of what can be distributed as 'Java'.

Such a scenario will allow Sun to say quite legitimately that the code is open, and they will do what it takes to make it palatable to the Linux distros; however, Free Software types will not be able to live with a contributor agreement that allows their work to be commercially licensed, and the Apache types will not be able to live with the conditions of the GPLv2, so I expect that both types of existing open source project will be dissatisfied, and we will unfortunately have a third open source Java SE project.

It remains to be seen how the current Java licensees react. It may be business as usual, or they may choose to work in one of the other open source communities. Perhaps it depends upon their current working relationship with Sun, and how they see their future use of Java evolving. In any case, there will be a benefit for all involved in the Java eco-system to continue working together on evolving the specifications and competing on the implementations so that the real winners are the millions of good people who write and use Java on a daily basis and appreciate the choices of implementation within standards that they are being offered.

Now Voyager depart, (much, much for thee is yet in store)

Welcome to my blog -- and welcome to the very first posting on the blog!

Looking at the site settings on blogger.com, I can see that I created my blog site back in July 2004. Back then, blogging was still in it's infancy, and I was interested in what this phenomenon was all about, and how people were using this new medium to publish information that was of great personal interest to them. So why has it taken me so long to write this first post?

Well just like websites in general, the range in quality of bloggers and their blogs is quite remarkable. Overall I've been underwhelmed by the quality of many blogs that I have read, and the implication was always there that I'd do no better (and that still remains to be seen!)

I believe that interesting blogs are those that are both informative and express an opinion. Until recently I was working exclusively on a proprietary implementation of the Java specification for IBM. What "changed" is that IBM decided to participate in the Apache Harmony open source project, and I was lucky enough to be involved in that process. Up to that point it would have been inappropriate, or irrelevant to many people, for me to inform and opine on the issues that were of great personal interest to me.

Being involved with open source is a game-changer. I've worked on projects in collaboration with other companies, and worked in open standards groups such as the IETF, but nothing feels quite like working in an open source project. Open source projects provide a special combination of working on a shared architecture and code base, and working in a broad and liberal community with simple rules of engagement, that I believe is unique.

My first experience of open source was while working for IBM Canada through involvement with the early days of the Eclipse Project and subsequent formation of the Eclipse Foundation. That was a relatively smooth transition of an existing code and community from 'closed' to open development.

Starting to work with Apache was a different experience. It required learning the Apache style of working and interaction, which I had never really appreciated as an enthusiastic consumer of their software. I think I've seen enough now that I get the basics if not all the subtleties.

So now I feel that I can write about aspects of life that relate to a broader community of fellow travellers. Some of my opinions, ideas, and rants are not going to be appropriate to inflict directly on the Apache Harmony development team, who are a great bunch of people and rightly focused on the task in hand. To date it has been my office co-workers (and bewildered family members) who have endured such outbursts. At least now I will have a distinct channel to express myself, and people can make the decision whether to follow along or not.

Let's see if I can beat my current record, and get round to a second posting within the next two years.