Editor Chris Adamson takes a look at the open source Java release and what it offers to the java.net community.
GPL for ME and SE. Good news for Java, good news for the community
The day that some never thought would come, has. Sun's Java SE and ME runtimes, and the GlassFish EE application server, have all been released under terms of the GPL. In this editorial, java.net editor Chris Adamson takes a look at the open source Java release and what it offers to the java.net community
Not a hoax. Not an imaginary story.
Comic book fans know those two cliches as defensive bullet-points on comic covers that seem to portray situations fans just know will never happen, like Superman dying or Batman getting married.
Sun Microsystems has GPLed Java. It's real. Not a hoax. Not an imaginary story.
That this day was coming is no surprise. Rich Green, Sun executive VP of software, promised as much at this year's JavaOne, saying that open-sourcing Java was a question not of "whether" but of "how." But the how, and the when, has been a much-debated question. How much of the JDK will be open-sourced? Under what license? How will compatibility be maintained?
Cynics presupposed that if Sun did choose to open-source their Java implementations, they'd choose the narrowest, most limited possible license that could lay any claim to the term "open source." The cynics certainly didn't expect GPL. When we ran a poll on java.net to ask "What license would you like an open-source JDK to use ?" the possibility of a GPL release, while preferred by 22 percent of participants, was dismissed out of hand by many. Many expressed concerns about forking, and one response claimed that the copyleft clause of the GPL would mean that "millions of Java professionals (unless you work for an open source project) would lose their jobs overnight and Sun would lose a lot of Java revenue and declare bankrupt[cy]."
Don't worry. You're not losing your job, and Sun anticipates this will be good for business. But how will commercial applications be able to use a GPLed Java? And what's going to stop a fork?
The Big Answers
The first place to go for answers to these questions is this new FAQ about the open source release on sun.com/opensource/java . This document anticipates a lot of the key questions: what's being announced today, the thinking behind it, and the expected results. For those who thought this was an easy matter of "just pick a license and put up a Subversion server," a thoughtful read of the FAQ may well change your mind. How does Sun, after all, allow for proprietary applications to run atop a GPLed JDK, or deal with licensed code in the JDK that is encumbered by its own licensing terms? The FAQ anticipates these questions and offers compelling answers.
To satisfy the reader who just wants to know what's being open-sourced and how today's announcement open-sources the JDK (specifically the
javac compiler and the HotSpot virtual machine, along with JavaHelp) under GPLv2 with the "classpath exception." The JDK code being released--and note that it does not include the class libraries at this time--is a very early version of JDK 7, which has seen its build process simplified from that of JDK 6 and is thus better suited to a wide open source release. As for license-encumbered pieces, those will be available in binary form until suitable open source replacements can be offered.
"Classpath exception?" you might be asking. "What's a classpath exception?" Perhaps the most important "teachable moment" of the release is the idea that applications that use the GPLed JDK are not themselves exposed to the GPL's requirement that they in turn be released under the GPL. This important exception isn't new--it was developed by the GNU/Classpath project, which faced exactly the same issue with the GPL.
The Java ME material being released is a phone implementation of ME, based on the Connected Limited Device Configuration (CLDC), and the ME Technology Compatibility Kit (TCK) framework. This is being made available under the GPLv2. There's no need for a "Classpath Exception" in this case, because it's impractical to distribute an ME implementation along as part of a phone-targeted application. More ME implementations, like a Connected Device Configuration (CDC) version, are expected in later releases.
As for Java EE, Sun's implementation was already open-sourced in June 2005 as the GlassFish project, available under terms of the Community Development and Distribution License. It will soon also be available under terms of the GPLv2 with the Classpath Exception.
What Happens Next?
OK, so commercial Java developers aren't rendered jobless by Sun GPLing their SE JVM--but what about forking? Wouldn't it be easy to fork Java at this point? Maybe--but then again, what would be the point of that? The value of Java is compatibility--an incompatible fork is not only not "Java" (indeed, Sun's trademark policies regarding the use of the word "Java" and the coffee cup logo still apply), but moreover, an incompatible fork is probably not terribly useful to anyone. And under GPL, the incompatibilities themselves have to be shared under GPL. Plus, the role of the Java Community Process (JCP) remains unchanged, governing specifications of the Java platform.
And one more thing: some forks are greatly beneficial, such as those that bring Java to new platforms, those not already supported by Sun or the platform vendors.
The GlassFish project on java.net is a good example of what does, and doesn't happen, when you open-source an essential Java technology. Remember, GlassFish has offered an open source implementation of Java EE under the CDDL license for almost a year and a half. Far from leading to a hodgepodge of embraced-and-extended EE implementations, it has accelerated development of all the EE application servers. As Sun's Ken Drachnik told Dr. Dobb's Journal : "Instead of a two-year timeline, it looks like most of the application server vendors will have implementations in eight to ten months."
Now the outreach is to developers. The FAQ states this is good for developers "because volume wins:"
Open-sourcing Sun's Java SE implementation will lower barriers to adoption in markets where open source software leads. As new markets adopt Java technology, developers will discover new opportunities. More applications. Innovations that leverage the industrial-strength foundation of Java to deliver valuable new products and services. And developers will be able to directly influence the future of the JDK implementation, participating with their peers in an open community. Taking Java where it hasn't been before, and helping to insure that Java technology remains a central unifying standard for the internet.
The next step is for developers to get involved. Visit openjdk.dev.java.net to see the emerging OpenJDK community in action. If you want to file or fix a bug, port Java to another platform, or get an understanding of how Java works "under the hood," it's never been easier than it is today. Do you fancy phones instead? Visit the new Mobile & Embedded community , where you can help create a new community of open source ME development. And the GlassFish project is becoming a community unto itself, one that you can join and make use of in your enterprise work.
Since its founding in 2003, java.net has offered an open source community for collaboration, discussion, learning, and achievement on the Java platform. As Java takes this next step forward, we're pleased to play a major part in providing a home for the OpenJDK, GlassFish, and Mobile and Embedded communities, and doing what we've done all along: help developers work together. The many projects on the site prove this is for real. Not an imaginary story.
width="1" height="1" border="0" alt=" " />