Now, that the dust has settled a bit.

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!

3 Comments

Filed under Sun

3 responses to “Now, that the dust has settled a bit.

  1. sheila

    First time I’ve heard the term ‘mashup’, great links to defining it.

  2. Mike,
    Thanks for opening up Java under a less restrictive license. For the FreeBSD community this will mean we don’t have to fund raise to pay for Java certification before we can distribute Java packages. At the moment we don’t distribute Java for FreeBSD/Sparc64 because of that cost.
    While you’re blogging about licenses, though, I’d like to draw your attention to the problems I’m having integrating DTrace into FreeBSD.
    Earlier this year there was some publicity surrounding my work on DTrace for FreeBSD. Following that I was grateful to receive a T2000 for development work and I’ve been helping with the FreeBSD/sun4v.
    While all this has been going on, another FreeBSD developer has been busy working on porting Sun’s ZFS.
    FreeBSD 7.0 is scheduled for release in the second half of 7.0 and the added features of UltraSparc-T1 support, DTrace and ZFS are all thanks to Sun Microsystems.
    The license problem that I have with the CDDL, though, is the effect that it has on the existing FreeBSD kernel license. The word free is supposed to mean that. People talk about supposedly free licenses and then they add conditions which make them somewhat less than free.
    The restriction that the FreeBSD project places on me as a developer is that the FreeBSD (GENERIC) kernel released and installed as default must contain only BSD licensed code so that it can be freely embedded in other products.
    The DTrace code in Solaris is built into kernel modules in FreeBSD and we have no issue with the CDDL covering that code. However, the problem comes when I try to integrate the hooks that DTrace uses to trace the most intricate parts of the kernel.
    To do this, I develop what we call shims — little pieces of new code that do nothing until the DTrace modules are loaded. The shims, or hooks, are the means that the DTrace modules use to register themselves with the kernel.
    In porting DTrace to FreeBSD, I find that I need to include CDDL header files to allow the shims to interact with the DTrace modules. It is the simple #include of what seem like simple header files which changes the entire license status of the FreeBSD GENERIC kernel. Sure, I can make the code optional and comply with FreeBSD guidelines, but I can’t enable DTrace by default if I do that.
    Let me show you an example of what I mean. Sorry, I can avoid going down to code level because people tend to simplify reality when it comes to license discussions. This is code that I would add to FreeBSD and enable by default if it weren’t for the CDDL. Here is a link to the FreeBSD Perforce repository and diff to a low level file, trap.c. The code displayed in blue is what I need to add to create hooks for DTrace to handle safety which is one of the most fundamental aspects of DTrace. You will notice that I have to include cpuvar.h, which is CDDL’d.
    Now, I could do as has been suggested to me and create my own header file containing similar code, but I can’t help referring to the publicity surrounding the SCO vs IBM litigation, and asking myself what happens if in 10 years time I get deposed about how I came to create that extra header file. My answer would have to be that I did it based on what I saw in the CDDL code. And therein lies my problem. Regardless of how a court of law would decide one way or the other, the fact that I had to look at CDDL code to even know how to create that extra header means that the CDDL notionally transfers in the process.
    As a developer, I find the CDDL hard to deal with. It takes a lawyer to interpret what it means. And during my work on DTrace, I’ve heard legal opinions from companies which embed FreeBSD stating that the CDDL isn’t acceptable to them because of the patent clauses.
    I can’t begin to argue with you what the license means. All I hope to do is convince you that differing interpretations of it are a problem and ask you to concede that we can’t wait for the result of a legal case to get a legal precedent.
    As it stands at present, I am prevented from making DTrace available in the upcoming FreeBSD release by default.
    I would like to take this opportunity to ask you to consider changing the license on the OpenSolaris header files to the BSD license. Doing that would resolve all the problems I am encountering.
    Please consider that Sun Microsystems’ intellectual property is embodied in the source code (C and ASM) that compiles to real machine instructions. I am not asking you to change the license on that. The header files are just a way of documenting the API.
    I’d like to point out that Sun has released the Hypervisor code under the BSD license and there are other API’s like BSM (the basic security module) which you’ve seen fit to release freely.
    In a recent blog, Jonathan Schwartz wrote that a rising tide lifts all boats. Please lift my boat!

  3. John: Some interesting points. I’ll discuss them with the OpenSolaris team. You may wish to write to me – simon dot phipps at sun dot com – so that I have your contact details.
    On a more general point for other readers, issues like this should be addressed to the Sun Open Source Ombudsman, ombudsman at sun dot com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s