Sun Releases JCK to OpenJDK and its Derivatives
Sun Microsystems today announced the release of a new license for Java Compatibility Kit (JCK). The specially drafted OpenJDK Community TCK License - as the name suggests - is designed to benefit the OpenJDK community by allowing much easier access to the JCK and therefore ensuring conformance to the Java standard is maintained. This is clearly a great boost to the credibility for the open source version.
While Sun has recently been moving key software assets under open licenses, the JCK remains closely controlled. Access to it has been gradually getting simpler over time, albeit not in a way that has been deemed favorable to open source implementors.
The new license sets specific requirements on which projects can gain access to the compatibility tests. The crux of it is that a project must "substantially derived" from the OpenJDK itself, and the code must be available under the GPL2 license - although the fact that the OpenJDK is distributed under GPL2 means that any derivative has to be be GPL2 also. What "substantially derived" actually equates to is not detailed in the license, and the FAQ not precise either:
"An implementation is "substantially derived" from the OpenJDK code base if it includes a large body of code existing in the code base that does something identifiably significant, or implements some set of APIs in their entirety."
As InfoQ reported recently, the Apache Harmony project had been lobbying Sun for fewer restrictions on the JCK. Harmony is the name given to Apache's implementation of the Java standard, and it needs to pass the JCK in order to call itself Java compatible. The Apache organization believes that Sun is in fact breaking the JSPA agreement forms the basis of the Java Community Process. This agreement, according to Apache, ought to bind participants to only distributing technology compatibility kits (TCKs) under non-restrictive licenses.
As a protest, Apache is now voting against all new JSRs where Sun is the specification lead. A spokesperson at Sun says, "Obviously we don't believe that we are breaching our obligations to the JSPA. We are offering access to and use of our TCKs, including the Java brand, under very benign terms." In a further comment, "Sun regrets that Apache implicates the evolution of the Java EE platform in our discussions over the TCK license for Java SE." Ultimately, the no-votes not yet having any real tangible impact as other participants are not engaged in this disagreement and the JSRs proposals are being passed. The official JCP commentary on this matter states:
"The JSR voting process is uniquely designed to assess and express an expert opinion by the JCP ECs about the technical merits of a proposed JSR. Based on the results of the JSR EC ballot it is decided whether a proposed JSR will continue development through the JCP to become a standard. We hope that the Apache Software Foundation and Sun will collaborate to find a resolution to their disagreements satisfactory to both parties and beneficial to the developer community."
It is fair to expect that the new JCK license will be a blow to the Apache Harmony project due to the lack of concessions to independently developed implementations which are working under their own open source principles. Sun's spokesperson says:
"We have offered, and are offering, to Apache the Java SE TCK under the same terms as we offer the TCK to commercial entities that want to build their own independent implementations, except that to Apache we offered the TCK free of charge, use of the Java brand free of charge, and our support services free of charge."
Evidently that offer was not suitable to Apache in accordance to their own open standards, hence the disagreement is likely to continue for some time.
Why the offer to Apache was unacceptable
These restrictions would not have been acceptable to Sun if somebody else tried to impose them against the OpenJDK, and they are not acceptable to Apache either. Make no mistake about who exactly is being stubborn and unreasonable.
This shows exactly how Sun is manipulating the Open Source model
The fact is that if Sun truly believed in open source and open competition then it would be willing to fairly and openly compete with other implementations - whatever their origins and without any freedom of use (FOU) restrictions. The reason Sun is not making the TCK available under the GPL is that the GPL would not support the FOU restrictions that Sun wants to enforce on Apache.
[I am a member of the Apache Software Foundation]
Field of Use: IBM and BEA in the same boat?
Sun argues that everyone is in the same boat and that Apache is in the same boat with the likes of IBM and BEA. If this is the case, what is their take? Is JRocket suitable for kiosk applications? How about Sun's JVM?
I've always seen the field of use restrictions as general protections for Sun and the Java brand. If someone decides to build their "kiosk" (or airplane navigation controller, power plant regulator, life support system, etc) and things go wrong Sun is covered legally. IIRC Microsoft Windows and other pieces of software have these field of use restrictions, and have had them for a while.
So what's the real issue here? Sun wanting to promote J2ME on mobile devices rather than J2SE as a more applicable runtime? If my phone can't run Eclipse should I blame Java the language? The runtime? My silly expectations?
I sympathize with Apache and agree that a completely open JVM without FOU restrictions would be great. However, I can at least understand that Harmony's failures can tarnish the reputation of Java and Sun. Apache has stated that it would allow Harmony users to do whatever they wished with the implementation. Even if those uses were ill advised and had disastrous consequences. A commercial entity will likely have FOU restrictions imposed by their JVM licensing to cover them and their brand from high risk legal issues.
If Sun's position is that their TCK can't validate Java for certain uses then I guess I have to respect that. The only way around these FOU restrictions then would be to demonstrate that a TCK can be created that is able to certify an application for any use. Which is a tall order.
Of course the logical argument is that non-"kiosk" applications can have the same problems and are open to just as much litigation. Is there some middle ground by which Sun can have recommended uses for the Java SE runtime? Something that can foster innovation and yet protect the brand should some inventions crash and burn?
Re: Field of Use: IBM and BEA in the same boat?
Firstly, I'd like to point out that IBM has its own private agreements with Sun around Java, and I assume BEA does too, so you cannot extrapolate to those JVMs.
The Apache Software Foundation - like other real Open Source initiatives - is based on its license. The ASF cannot and will not publish code under any other license. Therefore a freedom of use restriction - which is after all a licensing restriction - is inherently incompatible with Apache.
Of course, if you are correct that the "TCK cannot validate Java for certain uses", then that applies to the GPLed Java too. Under the new rules, anyone can take the GPLed Java, modify it in ways that still pass the TCK but make it less stable, less robust and "tarnish" the image of Java. Because the GPL doesn't allow the messing with its license either, and it would not be legal to apply FOU restrictions to the GPL'ed Java.
Re: Field of Use: IBM and BEA in the same boat?
The JDK as a technology may be another issue. It seems that what Sun is essentially saying is that the ASF can either have its completely open technology, or live by Sun's license for Java. With OpenJDK the technology is as open as it can be. You are free under the GPL to take it in any direction you want. Unfortunately what you'll be left with is Hava a "Java like runtime environment". Something similar worked out alright for Linux but likely won't fly with the ASF.
I do feel your pain, the ASF has worked very long and hard only to come to this conclusion. In the end the ASF may have to ask itself whether its willing to work on a non-Java runtime able to execute Java bytecode or whether it wants to be able to have an actual Java(TM) runtime.
Put another way, open technology is one thing, but an open brand is unacceptable to Sun. How would you suggest that Sun put FOU restrictions on the brand and allow you to produce completely open code at the same time? Answer that and you'll be one step closer to getting what you want.
Sun is not the problem
This GNU java is in Fedora.
No need for ASF to be agent for IBM.