InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

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

Posted by Floyd Marinescu on Nov 12, 2006

Sections
Operations & Infrastructure,
Enterprise Architecture,
Development,
Architecture & Design
Topics
Business ,
Open Source ,
Java
Tags
Java SE ,
Open source Java ,
Java ME ,
Apache Harmony
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.

10 comments

Watch Thread Reply

Congratulations on the scoop! by miko matsumura Posted
GPL? by shitpot shitpot Posted
Wow! by Stuart McCulloch Posted
GlassFish and CDDL by eduardo pelegri-llopart Posted
Congrats to all by anjan bacchu Posted
Re: Sun open sources Java SE, ME, and Glassfish under GPLv2 by David Skelly Posted
likely by Cameron Purdy Posted
Re: Sun open sources Java SE, ME, and Glassfish under GPLv2 by Floyd Marinescu Posted
Re: Sun open sources Java SE, ME, and Glassfish under GPLv2 by David Skelly Posted
Re: Sun open sources Java SE, ME, and Glassfish under GPLv2 by Mark Richards Posted
  1. Back to top

    Congratulations on the scoop!

    by miko matsumura

    Good job Floyd, this is hot news!!!

    This is going to be really great for Java/Linux to have a compatible source license, people can really start digging it now. Was hoping to get some of that done many years ago as Java Evangelist, but better late than never =)

    Miko

  2. Back to top

    GPL?

    by shitpot shitpot

    Now we get to shoot Mike Milinkovic. It's not CDDL!

  3. Back to top

    Wow!

    by Stuart McCulloch

    This really is great news: as an ex-JVM developer, I wonder if this means I can start dabbling around again inside the JDK?

  4. Back to top

    GlassFish and CDDL

    by eduardo pelegri-llopart

    Good summary, Floyd. One clarification on GlassFish and CDDL: we are going to add GPLv2 as soon as we can (we in the middle of Milestone 3 freeze for GlassFish v2) and we are planning to keep CDDL in the future.

    Thanks, - eduard/o

  5. Back to top

    Congrats to all

    by anjan bacchu

    Hi Floyd/all,

    I'm thinking that this will make it easier to ship JDK for everyone.

    Otherwise
    =========
    Some of the /bin utils that ship on linux/solaris don't get shipped on windows. Hopefully, the open source community will pitch in.

    I hope that in 2 years, there will be more Java developers that now! I hope that sun will create a version of JAVA which is server only (no swing, etc). Also, a version of java only for the browser (which will be for most purposes as fast as a flash plugin).

    Good Luck sun and java developers!

    BR,
    ~A

  6. Back to top

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

    by David Skelly

    GPL is well suited because it will minimize any likely hood of proprietary forks in the codebase


    Please tell me you didn't really write that. Surely it's not asking too much to hope that a reasonably well-educated person would know the difference between a likelihood and a "likely hood". Is the English language doomed to a slow tortured death at the hands of Americans? Sometimes it feels that way.

  7. Back to top

    likely

    by Cameron Purdy

    When he wrote "likely hood", he was writing about the possibility of an intentional proprietary fork, and was no doubt thinking of Microsoft (a "likely hood"), thus planting a subtle joke that you have now messed up by pointing out the otherwise obvious error.

    </justkidding>

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Cache

  8. Back to top

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

    by Floyd Marinescu

    Hi David, sorry about the blunder, it was really late at night. The blatant literary transgression has been rectified.

  9. Back to top

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

    by David Skelly

    Hi David, sorry about the blunder, it was really late at night. The blatant literary transgression has been rectified.


    It's OK, I was just having a "Mr. Angry of Tunbridge Wells" moment.

  10. Back to top

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

    by Mark Richards

    GPL is well suited because it will minimize any likely hood of proprietary forks in the codebase


    I rather liked the pun. keep it if you can!

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.