Sponsored Link •
Inaugurating the JCP Watch Series, Artima.com columnist Frank Sommers interviews Sun Microsystems' fellow and chief engineer Rob Gingell, chair of the Java Community Process (JCP), about open source licensing, source and binary compatibility, binary standards, and the JCP.
When you write a piece of Java code, you know that that code will run on a variety of machines: Windows, Linux, the MacOS, the Palm, and so forth. Platform-to-platform Java portability works because the VM, the Java bytecodes, and the APIs your program uses adhere to strict specifications.
What if those specifications, and their implementations, were opened up and developed in an open-source manner? Would Java still preserve its remarkable platform-independence? Or would it be fragmented into a myriad of incompatible versions and implementations? How could you be sure that the servlet or MIDlet you just wrote will work when executed on a different VM and OS?
These were just some of the questions the Java Community Process (JCP) had to recently grapple with. The primary forum for Java's advancement, the JCP in theory is an open process: Anyone paying a small membership fee can participate. In practice, it has been branded as a politically charged club of large corporations, with Sun at the helm, all vying for a piece of the Java pie. Due to its restrictive licensing model, the open-source community has completely shunned the JCP.
In response to those charges, and for fear of missing out on the open-source action, the JCP adopted a new set of rules in November, 2002. The most important of those rules explicitly allows JCP members to develop new Java standards in an open-source manner, while still under the JCP's umbrella and official blessing.
Frank Sommers asked Sun Microsystems fellow and chief engineer Rob Gingell, who also chairs the JCP, about the impact of those changes. In this interview, which will be published in two weekly installments, Gingell tells us what causes fragmentation in a market place, and how Java can avoid that danger. He also talks about how competing companies can cooperate through the JCP, and how small companies and individuals can have their voices heard in the JCP.
Frank Sommers: For a long time, Sun has claimed that Java needed a high level of compatibility to preserve the "Write Once, Run Anywhere" promise, and that open-source licenses could not enforce that degree of compatibility. The JCP requires that specifications and reference implementations be accompanied by a Technology Compatibility Kit (TCK). All subsequent implementations of a JCP-originated Java standard must pass those TCKs if they claim to be compatible with that specification.
The latest changes to the Java Community Process—JCP 2.5, inaugurated in October, 2002—give Java Specification Request (JSR) leads leeway in deciding licensing policy for their work. JSRs can now be developed in an open-source manner. The resulting work, including the reference implementation, can also be licensed under an open-source license such as the GNU Public License (GPL). How does the need to ensure compatibility mesh with the new JCP policy?
Rob Gingell: Your question involves a confusion between the process to develop a specification and the manner in which the resulting work is licensed. The JCP is a process. It does not actually license anything directly. Project leaders under the JCP are the licensors. When Sun is the licensor, we use the Sun Community Source License (SCSL), a license that requires derivative uses of the work to maintain compatibility with the specification as part of the terms for having access to the work.
The JCP now requires that the work products of a JSR—specification, reference implementation, and conformance tests (TCKs)—are licensed separately from each other. The general principle is that those doing the work should be able to decide how they make their work available.