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!
