Sun open sources Java SE, ME, and Glassfish under GPLv2

It has finally happened. Sun today announced that Java SE, Java ME, and Glassfish are being open sourced under the GNU General Public License v2 (GPLv2) with Sun today releasing an early build of the Java SE 7 HotSpot JVM, the javac compiler, and JavaHelp in the new OpenJDK project at Java.NET which will be the project site for future JDK development, releases, bug fixes, etc.  The fully buildable Java SE 7 JDK classlibraries will be available in Q1 2007.

Glassfish, Sun's open source Java EE appserver (and Java EE RI) is now available under GPLv2 license as well as CDDL. A buildable version of Sun's feature phone Java ME implementation and testing/TCK's will also be available on java.net.  Later this year, Sun will release additional source code including its advanced operating system phone implementation and the framework for the Java Device Test Suite.

Java SE 6 wil be open sourced in the Spring once the final version comes out.  According to Sun's Mark Reinhold, it would have been too agressive to release Java SE 6 right now as it would affect its release timeline - the first release candidate just went out last week, and JSR 270 (Java SE 6 release contents) was just approved by the JCP on Oct 24th. "We needed to make changes to the HotSpot JVM and the compiler in order to build them outside of Sun, and those changes were integrated into the early build of JDK 7. When we do the full release in the Spring, we will release both 6 and 7."

The two most important aspects of open sourcing Java are the license and the governance model. On governance,  nothing is being announced at this point, it is still to be determined.  Tim Bray told InfoQ that "It should end up as something unsurprising and true to open- source values; which is to say, committer-centric.  And we do anticipate having committers from outside Sun."   On the other extreme, some in the community have been pushing for a governance model where Sun gives up its absolute control (see an Eclipse governance model for open source Java).   The only thing said related to governance was that committers will need to sign a contributor agreement that provides for joint copyright assignment and also assigns patent licenses to Sun.    Tim Bray explained the reason for patent assignment:

we have to ensure that users of Java don't have to worry about getting claims that by using Java they're infringing a patent held by any of the contributors to Java (including Sun); so we have to prevent anyone, whether by accident or on purpose, from contributing code to Java and then being able to launch claims against people who use it.

Why GPL? As reported on InfoQ in the past, there were a number of tangible needs for an open source java.  According to Sun, a GPL license accomplishes two major objectives: driving more volume and adoption for Java and maintaining the "write once run anywhere compatibility promise."

On volume and adoption, open source Java under GPL can allow: 

• Java becomes Linux friendly, and can now be shipped by default on GNU/Linux distro's since it's free.
• Government-friendly. Foreign governments can now bet their infrastructures on Java without worrying about being dependent on proprietary, or US-owned intellectual propery (which could one day be embargoed), since Java's license makes it completely free. Sun officials specifically named China and Brasil as examples of countries that have been lobbying Sun for open source Java.
  
• Even in the US, some projects won't accept bids not built on open source software.
• New technical use cases. Companies can now freely port Java to new hardware platforms & operating systems, and customized app-specific JVMs can also be created where needed - however due to the viral policies of GPL - all such ports must also be released as GPL which may limit such activities for commercial purposes since the ports could not be made proprietary.
  

On the compatibility promise, Sun officials said:

GPL is well suited because it will minimze any likelihood of proprietary forks in the codebase....it drives innovation into the open, any modifications to the codebase have to be published...

Expanding on the issue of GPL and forking, Tim Bray told InfoQ:

It doesn't [prevent forking], it totally allows forking, and there will be forking. Which presents the problem of how we keep the Java promise of compatibility.  We'll use a business/legal approach, rather than a technical approach.  Which is to say, you can take the code, you can change the code, you can compile the code, you can publish the code,  you can sell the code, no permission required.  But you can't call it Java or use the coffee-cup logo without going through all the same processes you have to now: pass the appropriate TCK and secure the copyright clearance.  So for businesspeople who want to be sure that  they're running real compatible un-forked Java, the Java brand - the  name "Java" and the coffee-cup logo - is the stamp of approval to look for.

GPLv3 was not chosen since it is not finished yet, but when asked if Sun will move to GPKv3 an official said "at this point we don't know what the final license will be."

The license for open source Java has been the subject of much confusion among Java developers, with some fearing that even extending from java.lang.object could be considered a derivative of the JDK, and being GPL, might cause Java applications to all have to be released under GPL.  Dalibor Topic, lead on the open source JVM Kaffe (licensed under GPL) clarified that this is not the case:

The GPL doesn't require that bytecode classes using a GPLd java.lang.Object be licensed under the GPL as well. That's because neither the bytecode nor the source code using it are derivative works of java.lang.Object, as all that ever ends up in them are interface names and constants, and those remain the same, regardless of the license of the java.lang.Object class. Those symbols are standardised through the JCP, and published as specifications. They are necessary for interoperability. Therefore, the symbol names and constant values can not be claimed as original works by a GPLd java.lang.Object, and accordingly don't meet the bar for copyrightability.

Putting it simply, Dalibor later explained:

You can create a derived work by taking GPLd code from the standard class library and copying it modified or verbatim, into your own code, of course, but that's the same regardless of the license.

On the impact of the move on the JCP, Tim Bray clarified to InfoQ:

The JCP doesn't govern implementations, it governs specifications. It defines what the various Java packages (SE, EE, ME) are, using in part reference implementations. At the moment, we're not planning any big changes in the JCP as a function of the open sourcing move.

It's unclear at this point what the announcement will mean for existing open source Java works, including the Kaffe VM, GNU Classpath classlibraries, or the GCJ compiler.   With regards to the Apache Harmony project which is also trying to make a cleanroom open source Java implementation. Update:  Apache Harmony PMC Chair Geir Magnusson told InfoQ that Harmony's development will continue:

it won't change much for us.  Apache and Sun have different communities, with different licenses, different conditions for contribution and different governance models.  While each contributor to Apache Harmony has their own reasons for participating, and I therefore can't speak for them, I believe that this good news today from Sun doesn't change what we'll be doing - it just means even more open source Java, and that's a good thing.

Harmony is released under an Apache license which cannot incorporate GPL'd code and thus cannot use any of the OpenJDK code. Since GPL prevents proprietary modifications to Java (since GPL requires you to release changes under GPK), various commerical interests may still want to see Apache Harmony continue.

The largest such commercial interest is IBM, who has been pushing Sun to open source Java for years.  On every JSR passed by the JCP since 2003, IBM has included the following clause in it's vote (excerpted from the final ballot votes of any JSR):

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.

IBM has also been a backer of Apache Harmony and with Intel has a made many contributions to the project, which has been speculated to have been indirect attempts at pressuring Sun to open source Java.  

Further details on the open sourcing of Java will be published by Sun at http://www.sun.com/opensource/java where a public webcast  will be made at 9:30am PT today.  Update: Sun has published a press center for analysts containing more info including video quotes from various personalities on what they think.

What will be the impact of open source Java? Tim Bray's personal wish is that "people building the GNU/Linux desktop are unshackled from the tyranny of C++." What do you think?

This post was first published Nov 13th at 12:01am and will be updated throughout the day as new links and information become available.