Sun's new Java licensing is disappointing

Last week Sun announced a new licensing scheme for Java. It's part of a larger plan, referred to as "Project Peabody", designed to increase transparency into the development process of the Java specifications and reference implementations.

According to Sun, "Project Peabody" has the following goals:

• Simplify licensing practices
• Increase transparency
• Give developers a chance to contribute
• While maintaining Java compatibility

Sun has devised three new licenses to replace SCSL (Sun Community Source License), which is the extremely complex license Sun now uses for Java source code. These licenses will apply to J2SE 6.0 ("Mustang"). The three new licenses include:

• Java Distribution License (JDL)
• Java Research License (JRL)
• Java Internal Use License (JIUL)

JDL applies to anyone that wants to distribute a J2SE implementation for any purpose other than research. The license requires that the J2SE implementation must prove J2SE compatibility by passing the TCK (Test Compatibility Kit).

JRL is (supposedly) designed to support the needs of the research community. It permits research groups to develop and share J2SE implementations for research purposes. If anyone wants to redistribute a derivation of J2SE for any purpose other than research, that entity must obtain a JDL license and pass the TCK. J2SE 5.0 ("Tiger") is now available under JRL. Sun plans to release weekly builds of "Mustang" under the JRL, also.

JIUL (pronounced "jewel") is designed to support the needs of the average company that uses Java. It permits "users" (personal, academic, or corporate entities) to make fixes and enhancement to the Java source code for their own internal use. Such users are not required to pass the TCK, but they also may not share their fixes with other users (except for research purposes). JIUL relies "on the honor system" to ensure compatibility, but what that really means is that compatibility is not assured if you make modifications.

Sun has also developed a new set of contribution agreements. Developers are "encouraged", but not required, to contribute bug fixes and modifications back to Sun. Contributing developers retain rights to their code, but they must also grant all rights to the code to Sun.

My take on all this

First and foremost: JRL and JIUL are not open source. The first rule of open source is that it allows developers to fork the code. These licenses clearly prevent developers from forking the code.

At least Sun is upfront about it. They clearly stated that these licenses are not open source. Sun made the usual excuses about ensuring compatibility as their reason for not open sourcing the code. But I totally reject this argument.

Sun protects Java compatibility through the licensing of the Java brand, not through the licensing of the source code. An implementation may not be called "Java" unless it passes the TCK (Test Compatibility Kit). Using a GPL license -- or even CDDL (the new Solaris 10 open source license) -- Sun can use a dual licensing strategy to open up the source code, and yet still maintain a commercial licensing practice.

Sun is being greedy. They want the benefits of open source -- getting vast hordes of developers to contribute fixes and new ideas to the Java code base for free -- but they aren't willing to actually contribute the source code to the open source/research community.

I explained the JRL to an acquaintance of mine that has a research position at MIT, and his response was, "Well that's of no use. And why should I contribute my work to Sun?". Researchers want the ability to fork the code, and Sun definitely doesn't want people to fork the code -- that's the essence of the compatibility argument.

JIUL does offer some value to users. One of the most valuable benefits of open source is that it allows users to debug, fix, and tweak code to suit their specific requirements, and the JIUL does give a company that capability. I doubt, though, that very many companies will take advantage of this opportunity. Java is a bit too complex for most companies to want to muck around in. It's also potentially dangerous -- because if user companies do muck around in the code, they are likely to break compatibility.

When dealing with this type of code base, the real beneficiary of open source is the research community, which would like to work on building the next, better VM. But Sun doesn't want someone to build a better VM. Not unless they own it. Now, if they did a GPL license, then all modifications would have to be contributed back into the code base. From my perspective, Sun would be better off using GPL rather than JRL and JIUL.