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.