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.

Java Community Process and Licensing

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.