Posted by ray_gans
on September 9, 2005 at 1:14 PM PDT
Sun has updated its Java Research License (JRL) to address several concerns brought to us by the developer community. This revision better clarifies Sun's intent for the JRL and should help to make the license more agreeable to those who may have had questions about some of its language in the past. These clarifications should not affect any projects currently using the JRL on java.net.
Thanks to thoughtful comments and questions from the community and great feedback at Java One, Sun has revised the Java Research License (JRL) to address several concerns that have been brought to our attention -- in particular with how it affects open source developers. As before, it is Sun's purpose to make its code easily available to developers under JRL for research and collaboration purposes and to not get in the way of other efforts. In addition we want to make the license possible for a non-lawyer to understand (which believe me is a challenge!) so people don't needlessly worry about accepting its terms. The changes we made are really just clarifications and some cleanup to the existing language, so no java.net projects using this license should be affected. The upshot of the update, we hope, is that more people will now be comfortable about participating in JRL projects.
So what's changed?
The definition of Modifications was clarified to ensure that the JRL is only concerned with changes or additions to Sun's code. The JRL does not prohibit you from doing any work alone or under another license (e.g., an open source license) as long as such work is done independently of JRL code. The Purpose section of the license was also expanded to better reflect this point, i.e., that code made available under the JRL is not intended to be used for consultation purposes on independent efforts. While this may seem obvious, the fact that it wasn't clearly stated has led to some questions. And don't worry, we did not back off on your residual rights. No one becomes "tainted" by examining code under JRL. Your memory is not contaminated and the JRL does not prohibit you from later participating in other projects after working with Sun's code -- in fact you may remain a JRL licensee in good standing while doing so.
We did some cleanup as well. The term "specifications" was removed from the definition of Technology (i.e., source and object code) since specs are generally covered under their own licenses and not distributed under the JRL. An address is now included where one can send notice in the unlikely event that he or she wants to terminate the JRL. We also clarified that termination of your JRL requires you discontinue all use and distribution covered by the license (which was backed up in the rest of the license, but not well stated in the previous termination section).
Notice too that the sections on Residual Rights and Third Party Software were replaced with language used in other Sun licenses for consistency. This new language is the same in intent as the old, but hopefully a little easier to read and understand.
If you'd like to compare the updated JRL to the old one, you can find it here .
I think the JRL is a good license and those interested in the licensed technology should have no qualms about its terms. We've tried hard to ensure that the JRL does not create a barrier for anyone who has used or examined the code and later wants to work on another project -- including an independent implementation of the same technology. Maybe it won't work for everyone (heh, and what license does?) but I believe it will meet the needs of the great majority of developers.
And there's more...
The JRL FAQ has been updated to answer additional questions and Sun has published a couple articles on the JDK Community site on java.net to discuss several issues in more depth pertaining to Java SE. The first is a note that addresses common questions from developers about Sun's Intellectual Property (IP) and the creation of independent implementations of Java SE (especially with regards to the Apache Harmony project). The other article provides a further discussion about "tainting" concerns over Java SE source code. Check them out and join us and other developers on the Mustang Project to create the next version of Java SE.
Again I'd like to thank those in the developer community who have kindly brought these issues to our attention. I hope this JRL update and the two articles will open more developers to work with Sun and to help move Java technology forward.