Red Hat to Build Optimized Java for Enterprise Linux

Nearly a year after Sun Microsystems first announced it would be releasing a build of Java to the open source community, Red Hat has apparently signed on. In an announcement this morning, the company said it has licensed Sun's Java SE Technology Compatibility Kit (TCK), with the objective to produce an optimized Java for its Enterprise Linux that will drive JBoss applications.

"Red Hat customers will benefit from a highly optimized, accelerated runtime for JBoss Enterprise Middleware in a Linux environment," reads a Red Hat statement this morning.

The purpose of the TCK is to help implementers to certify whether the build they're currently working on satisfies the requirements of the current Java specification. In other words, open source implementers may make optimizations to Java like those Red Hat is planning, but is it still Java? Licensing the TCK is seen by Sun as a commitment to ensuring the integrity of the platform.

"The TCK includes a set of tests and a set of rules," reads guidelines posted on Sun's Web site. "The rules define (a) the procedures for running the tests and (b) some higher level standards for compatibility which may not currently be captured in explicit tests. One example is that there is a rule that requires that a product be compatible in 'all configurations.' You can't have a special configuration that you use to pass the tests, but then encourage your customers to use other configurations that are actually subtly incompatible."

But Red Hat's move isn't without a note of controversy. For the last year, Sun's licensing terms have been a topic of concern in the open source community. Last April, the Apache Software Foundation aired its dispute with Sun in public, with an open letter from its Java Community VP Geir Magnusson to Sun CEO Jonathan Schwartz complaining about certain restrictions of its TCK (also known as JCK) licensing terms.

"The ASF has a proud history of support for open software ecosystems in which commercial software can flourish," Magnusson's letter read. "However, Sun's JCK license protects portions of Sun's commercial Java business at the expense of ASF's open software. It prevents our users from using Apache software in certain fields of use. Such implicit or explicit threats of IP-based aggression give one actor overwhelming commercial advantages over the other participants in the ecosystem. In an open ecosystem, it must be the case that the necessary IP to implement a specification can be secured independently from the specific commercial interests of any one actor in the ecosystem, which is the basis of our objection to your offered terms."

At the time of the dispute, Sun tried to argue that the TCK makes it possible for licensees to determine whether they are eligible for using Sun's intellectual property in an open source fashion. Apache, it said, should be eligible as well if it meets the requirements.

"Let us say that Apache creates a set of binaries that pass the TCK in a given target environment," its explanation began. "By passing the TCK in accordance with Sun's TCK license, these binaries have been demonstrated to be compatible in a given environment. Therefore they are licensed to use the Java SE IP in that environment. So people can safely download and use the binaries in that environment."

But if someone modified those binaries without license to do so, the explanation continued, "those binaries will no longer be authorized to use Sun's Java SE IP."

Last July, SD Times publisher Alan Zeichick asked Sun Microsystems to provide a copy of the TCK/JCK agreement. Sun declined.

But since that time - in fact, just two weeks ago - a version 1.1 of the TCK agreement template (PDF available here) showed up on Sun's OpenJDK Web site. No such restriction provision appears in this version.

What does remain, though, is a legal definition of the phrase "substantially derived," which refers to a derivative work to OpenJDK whose eligibility to be called "Java" is technically defined by the TCK itself. Such a derivative "may include significant modifications to the OpenJDK Code, of the Java Specification," version 1.1 of the agreement now reads, "where such implementation is substantially derived from and would be considered a derivative work of the OpenJDK Code and, if distributed to a third party, is distributed only under the GPL License."

Later, the license refers to users' ability to validate a Java implementation using the kit, and then distribute that implementation only under the General Public License, under which OpenJDK itself is distributed. But the TCK itself is not open source, so users are prohibited from making any derivatives of it.

There's a simple enough reason, from Sun's vantage point: "If the JCK itself were open sourced, alternative versions of the test could proliferate that might or might not conform to the actual specification or that might interpret the specification differently," reads a company FAQ.

While the prohibition against modifying the TCK remains and will probably continue to remain, the latest version of its licensing agreement does not appear to restrict the rights of implementers, or the "field of use" of substantially derived implementations, as Apache had complained. Perhaps the timing of version 1.1's release, its public visibility, and Red Hat's commitment to the project is not coincidental.

This afternoon, Sun CEO Schwartz noted Red Hat's decision, in the same sentence with Google's announcement of its Android phone platform, which is said to possibly include a Java implementation. (No mention of Java was made on today's Google conference call.) Said Schwartz, "With friends like Google and Red Hat, it sure seems like the momentum behind Java's on the rise."