Ray Gans's Blog

Java Internal Use License (JIUL) released for JDK 5.0

I am very pleased to announce that Sun has released a new license for the JDK called the Java Internal Use License (JIUL or "jewel"). This license lets developers easily make changes to the JDK for internal deployments. It's free, click-through and should be easy-to-read by non-lawyers.

JDK 5.0 source is available now under both the JIUL and the Java Research License at the tiger project in the JDK Community.

End-users of Sun's implementations of J2SE 5.0 now have the ability under the JIUL to fix any critical issue in the code that adversely affects their business operations. In addition, Sun will waive the commercial requirement to pass the Technology Compatibility Kit (TCK) for J2SE (a.k.a. the JCK) as long as all code changes are made with diligence to assure the resulting implementation remains true to the specification and that its use is restricted to the licensee's internal business or organization.

What? How could this be? Hasn't Sun proclaimed since the dawn of Java, "Thou shalt only have compatible implementations before thee!" And now... Sun is giving people the right to change the JDK without verifying that compatibility?

Well yes, and no.

Sun is not backing away from compatibility. In fact, a passion for Java compatibility should be a prerequisite for any company or individual who enters into the JIUL. The purpose of the JIUL is to address a specific business need of Sun's customers who tell us that while compatibility is critical to both Java technology and their businesses, they also need the ability to fix critical bugs or performance issues in an emergency.

So why drop the requirement to pass the JCK?

The JCK is not designed for end-users, but rather for J2SE implementers who are intimately familiar with the operation of their code. Few businesses need to understand all the intricacies of the JDK runtime and few operate in work environments that make use of every J2SE feature. However, all features must be set up and successfully tested as part of passing the JCK. For this reason, the cost in time and resources necessary to understand, set up an appropriate test environment, and then pass the JCK is just not practical for most businesses.

The JIUL runs on the "honor system." Sun trusts that licensees will make changes with great professional care so as to limit the risk that compatibility is compromised. Sun understands too that even the best of intentions may fail which is why all JIUL-based J2SE implementations must remain strictly within the confines of that licensee's business or organization.

To be clear, the JIUL is not a general purpose J2SE implementation license. Sun has commercial licenses for those who wish to distribute their implementations (and such licenses do require the code passes the JCK). Think of the JIUL as a safety net. It provides peace of mind when things are good and more control over managing your IT operations in times of a business emergency. I hope you never have to use the JIUL, but if the need ever arises, you'll be glad it's there.

Comments

• 
  Don't know why this blog entry is suddenly at the top of the JavaDesktop page, but I suppose it's good to reinforce to people what's going on with the licensing with Java.

  
  Whilst it's clear an improvment, as it's only aimed at organisations, it's only them who will benefit. Those same "critical" bugs that could upset a enterprise customer are also upsetting Jave developers who wish to release stand-alone products, like libraries or desktop applications. I wish Sun would find out just how many professional devs deploy a local JVM with their software. I reckon it's a very high percentage. Why can't they be allowed to fix bugs that affect their products?

  
  Again, can't you rely on "honour" for devs to do an honest job? Perhaps the license could be extended so that if you do deploy a patched JRE, you have to put up a notice professing this, and the user has to agree to it, or something like that.

  
  The license itself is no easier or worse than most of the OSS licenses that Gosling was complaining were difficult to read. Most licenses are awkward as they are written in legalese! I'm glad to see that there's a decent FAQ with it though, that really does help to clarify the license to the mere mortals :)

  Posted by: arooaroo on May 28, 2005 at 02:42 AM

• I think it's very funny how those same customers, that according to some folks would run to the hills on mention of Open Source, demand the freedom to modify the runtime code and distribute those modifications, which are, among others, the same freedoms granted and protected by Free Software licenses.
  Will Sun Microsystems now go around and make sure that organisations that accept the JIUL let no random senior citizen check something in into those JIUL licensed 'forks'? That's going to be very exciting to watch. :)
  Also somewhat amusing is that all the different SCSL-derived licenses are mutually incompatible, so that work done under either of them can not be reused under others. I thought it was by mistake, but apparently, judging by the FAQ it is by design. That's going to make the intergation of those changes back into the official JDK very interesting to watch, as Sun Microsystems will have to be careful not to mix the work they accept under the SCSL, with the work they accept under the JRL and the JIUL.
  Well, at least this license fixes the 'impossible to terminate' bug in the JRL by including the address to which to send the termination notice. The broken definition of Modifications(b) unfortunately remains, making the Residual Rights clause useless in real life as I have explained to you on JavaLobby and to others on the GNU Classpath mailing list. That's pretty unfortunate, and will need to be fixed by Sun Microsystems eventually to be able to effectively participate in Open Source efforts like GNU Classpath.

  cheers,
  dalibor topic

  Posted by: robilad on May 29, 2005 at 01:21 PM

• Harmony anyone? :-)

  Posted by: dgriffiths on May 30, 2005 at 11:59 PM

This work is licensed under a Creative Commons License.