Sun needs to get its licensing act together
There’s a debate going on in the Java community regarding the licensing terms for technology compatibility kits. It’s not a new debate—the Apache Software Foundation published an open letter on the subject back in April, complaining about the so-called field of use restrictions that Sun places on its Java Compatibility Kits.
The JCKs are the tests that third parties, including open source groups like Apache, need in order to demonstrate that their implementation of Java specs meet the requirements of those specifications.
Sun’s field of use language requires licensees to restrict how their customers deploy the software tested by the JCKs. As you can imagine, that’s ridiculous when applied to open source software. As Apache correctly points out, those restrictions not only are hostile to Sun’s public promises to support open standards, but also violate Sun’s own Java Specification Participation Agreement, the bilateral contracts between Sun and other companies that let them into the Java Community Process.
To date, Sun has refused any meaningful comment about the field of use restrictions, or address the concerns expressed about them by Apache. And now, it looks like the issue’s coming to the fore. The first major JCP spec to come to a vote since Apache’s open letter is the ballot for the creation of JSR 316, the super-important Java EE 6 specification. The ballot passed, but it was not unanimous—even though the spec leads apparently pledged not to impose field of use restrictions on Java EE 6’s JCK.
Apache voted against, charging that “this spec lead—Sun—is in violation of the JSPA and therefore shouldn’t be allowed to start another JSR until the above matter is resolved.”
While everyone else voted in favor (well, Borland didn’t vote), several Executive Committee member companies referred to the license issue in their official vote comments.
Big Blue wrote, “IBM’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.”
Intel said, “The Spec Lead has told us there are no ‘field of use restrictions’ on implementations for this particular JSR. The Apache open letter about Java SE claimed that a confidential license for a required JCP test suite restricts how Independent Implementations of that JCP spec can be used. Licenses to test for JCP compatibility must not be used to limit or restrict competing, compatible implementations; licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates. For every JCP ballot, we will ask the Spec Lead whether such restrictions exist in their license.”
And Red Hat wrote, “The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no ‘field of use restrictions,’ as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing. However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR. Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.”
It is long past time when Sun needs to publicly and openly address the “field of use” issue—and either satisfactorily explain why it imposes such restrictions in violation of the JSPA, or drop such restrictions from all past, present and future JSRs immediately.