Licensing and Compatibility

Frank Sommers: How does that licensing freedom still ensure that all JSR implementations are
compatible?

To illustrate the question, suppose that I propose and develop a new Java-based API through the JCP—say, an API to interact with Java-enabled toaster ovens. After the work is complete, I release the reference
implementation under an Apache-style license. Given that license's terms, anyone can now download my
implementation and hack away at the code. At some point Big Bad Toasters, Inc., decides to fork my
original Java toaster-API implementation such that the new code branch works only with their toaster ovens
and breaks some of the code written against my original implementation. Can that occur under the JCP 2.5?

Rob Gingell: As specification lead of the Java toaster JSR, you have decided to make the
reference implementation, and maybe the TCK, available under an open-source license. If Big Bad Toasters
takes that reference implementation and creates an incompatible derivative work from it while still claiming
to implement the specification, then they would be in violation of the specification license.

On the other hand, if they took your work and implemented a completely different specification from it,
say, com.bigbadtoasters.Toaster, that would be a legitimate, though annoying, thing for them
to do. The specification intellectual property protection says that you can't lie to Java programmers about
what Java is. The JCP defines that truth, and the materials produced in JSRs are used to validate it, and
collectively the artifacts and the process work to maintain that assurance. In this case, however, they're not
lying to anyone. They're not claiming it to be an implementation of the JSR, nor are they offering an artifact
that would poach upon developers who were expecting it to be the JSR, since it lives in Big Bad Toasters'
namespace.

If you make your reference implementation available without the requirement that others using it create
implementations compatible to the original specification, a competitor, such as Big Bad Toasters, can create
a different API and bootstrap their market effort with your work. If they then work in the marketplace to
cause their API to become popular, that's permissible, unless they infringed on a patent or other intellectual
property not licensed to them.

They can also operate much more communally to the same effect. For instance, they can subclass your
JSR-specified API. They will then be compatible with all existing applications of the original API, but
create some new functionality which has great appeal. If they're successful, it may come to pass that there is
no application for toasters which ends up directly using your original API anymore, making it marketplace-irrelevant. Big Bad Toasters has done nothing harmful, but merely made its non-community-defined
extensions more popular than the base defined by the JCP.

There's nothing about the JCP that prevents people from succeeding with Java, even where that success
overshadows the JCP—that's what competition is all about. Indeed, the changes adopted in the JCP serve to
increase the competition for compatible implementations. The main thing the JCP strives for is to ensure
that those who write Java applications are not lied to by those who make the implementations they build and
deliver upon.