I spent much of last week reading various press accounts of Sun’s decision to open source the Java platform. I usually do this after major announcements to get a sense of how clearly and accurately we have communicated externally. But what I’m noticing is that while the views of traditional media remain important, we are increasingly interested in the feedback received from blogs and the comments posted by blog readers. These are becoming great indicators of how well an announcement, such as this one, is ultimately understood and received.
I participated in a number of media interviews in connection with the Java announcement. But, I had reservations about speaking to business journalists about such a complex and nuanced area. Given the questions asked by one of the reporters, I was certain that my responses would be reported in a very inaccurate journalistic mashup.
Thankfully, that interview wasn’t used. But, in the interest of clarity, I thought it would be useful to provide some of the questions that the reporter should have asked along with my responses.
Q: “What was the involvement of Sun’s legal team in the decision to open source Java?”
A: “The decision to release any Sun technology in open source is a collective effort involving the engineering, marketing and legal organizations. Our attorneys have been key contributors to the formation and 11-year evolution of the Java Community Process. They also have significant expertise in open source licensing. With this combination of knowledge and insight they were integral participants in the open sourcing of the Java platform.”
Q: “Why was the GNU General Public License (GPL) chosen?”
A:”The first step for us in open sourcing a technology is to understand what our internal business partners are trying to achieve. Then, the legal team reviews the available licensing models and makes recommendations as to which is most appropriate. In this case, we wanted an OSI-approved license. For OpenSolaris, we created the OSI-approved Common Development and Distribution Agreement (CDDL), a derivative of the Mozilla Public License (MPL) that is designed to be more re-useable by others for their own open source projects. In this way we attempted to reduce the need for new MPL derivative licenses and combat license proliferation. And, in fact, it has worked out as many non-Sun projects have chosen to release their code under the CDDL.
A key factor in our decision was selecting a license that would continue to help drive community adoption of the Java platform. Currently, there are more than 4 billion devices worldwide that use the Java platform. Think about that number for a second. It’s a staggering example of the power of a community – in this case the Java community – to drive a common global platform. We could have selected the CDDL, but we wanted a license that would be embraced by the Linux community and that was in harmony with the already existing and thriving Java GPL community. The GPL requires that any code combined with GPL code must be distributed under the same license. Developers must provide their contributions back to the community. This provision provides a mechanism to ensure that Java continues as a unifying platform for innovation.”
Q: “Why didn’t you release under GPLv3?”
A: “The short answer is that it doesn’t yet exist in final form. The Free Software Foundation has provided a very robust and open process for developing GPLv3. We have representatives from both our business and legal teams participating in this effort.
Q: What was the process for open sourcing the Java platform?
First of all, let me make clear that this was not a trivial effort. We had a number of people working amazing hours (thanks Chris, Melissa and the rest of the team) to get everything done in a compressed period. The most involved part of the process is the extensive due diligence review. This is where we examine the code base to identify any contributions, attributions, notices or other indications of non-Sun intellectual property. Once this is completed, we then review our legal agreements to ensure that we have the rights necessary to place any of the identified third party code into open source. If we don’t, then we engage in a renegotiation with the licensor to acquire the necessary rights. In some cases, where we aren’t successful, we will release the code in binary form. To give you an idea of the scope and complexity of this exercise, the Java Standard Edition platform contains over 6 million lines of code.
Although this a challenging task, it is becoming a core competency of our legal, marketing and engineering teams. We’ve done it with OpenOffice, OpenSPARC and OpenSolaris. We’ve even released “Duke” in open source!