Sun's Open Source Java Moves Are Bold, Smart, and Limited
On November 13, Sun announced that large portions of their Java platform toolkit would be immediately available as open source software with a GPL v2 license, with more components to be released over the next months. This is a significant announcement, with the potential to alter the computing industry over the long term. But given that the announcement is several years later than it should have been, and given that there are some significant holes in what has been released, there is not likely to be much impact in the short term.
For most people, the most important part of the code release is related to Sun's Java Standard Edition (AKA, Java SE), which is the mainstream Java platform that most of us use on a daily basis. In particular, Sun released the HotSpot virtual machine interpreter, which is the engine behind Sun's own Java Runtime Engine (the JRE is the software package that most people download from Sun's Java site). Not only is HotSpot the de facto standard JVM for Java applications, it's also already platform independent, and one of the best JVM platforms around, with an intelligent interpreter that does on-the-fly compilation of the most-used code in an application, which makes it much faster than straight interpreters.
Cmulatively, releasing the HotSpot JVM source code under a GPL license should provide for better and faster interpreters everywhere, possibly to the point where the historical promise of "write once, run anywhere" is actually realized (the derisory variation--"write once, debug everywhere"--has been a running joke for almost as long).
For example, even though Sun has already ported their JRE to a fair number of computing platforms, they do not currently have builds for secondary platforms such as Linux on non-Intel hardware, or common BSD distributions, and so forth. Even on platforms that are supported, the lack of a suitable redistribution license has prevented many vendors from including the Sun JVM with their system (this is especially true for Linux, since most vendors will only bundle GPL licensed code with their kits). With the HotSpot JVM now being available under a GPLv2 license, the developers of those platforms can now port the de facto standard Java interpreter to their platforms, and get high levels of interoperability and performance essentially for free, without needing to develop their own JVMs (which are almost always saddled with some kind of interoperability and/or performance problems), and without having to negotiate complicated redistribution licenses from Sun.
In short, Sun has solved a lot of problems with Java, simply by eliminating the need for multiple JVM interpreters. Even in those cases where other interpreters may be desired for performance or size reasons (among others), the GPLv2 license allows developers to make changes to the core JVM code which can then be incorporated back into the original source, or the changes can be packaged as optimizations by other developers. In either case, interoperability can still be assured, since any changes to the JVM will have to be released under the same GPL license.
However, while the release of the HotSpot source code allows for all of this to happen, we aren't there yet. In particular, some of the support libraries that are used by Sun in their own JRE are sub-licensed from third parties, and Sun does not (yet) have permission to release that source code, nor do they have viable alternatives available yet. So while people can start working with the HotSpot JVM right away, it's not yet possible to build your own version of Sun's JRE, nor is it possible to guarantee 100% bug-level compatibility.
For example, the font and graphic rendering libraries that are used by Sun's JRE are not available in GPL licensed form, and until they are released as such (or drop-in replacements are made available), Java programs may not look and work as they do under Sun's own JRE. However, Sun says that they have already identified the missing pieces, and those components should be in place by the middle of 2007. So while developers can start working with the standard JVM today, users should not expect fully-compatible versions of Sun's JRE to start showing up until about a year from now.
There are other parts of the Java SE platform that Sun has also released, and other parts that are not yet ready, although most of these components will only affect developers, and do not impact end-users much. For instance, Sun has announced that the javac byte-code compiler and the JavaHelp documentation technologies were also released under the GPLv2 license, both of which are necessary and important for Java developers. However, the full Java Developer's Kit is not yet available, since problems with the encumbered libraries are preventing its release. The parts that are available (including HotSpot, javac and the JavaHelp components) are currently posted on Sun's openjdk site, and the remaining components should be available sometime in the first half of 2007.
Apart from the mainstream Java SE platform, Sun also released the Java Micro Edition as open source under the GPLv2 license. Java ME is essentially the "mobile and embedded" version of Java that is used in devices such as cell phones, PDAs, set-top boxes and other small and fixed devices, and is already widely deployed on a large number of those platforms. Releasing the code for Java ME under the GPLv2 license will only help to cement Sun's well-established position within that sector.
Sun also announced that the Java Enterprise Edition platform would be released under GPLv2 through their GlassFish project, which is Sun's own Java EE application server that more-or-less competes against application servers such as Red Hat's JBoss and IBM's WebSphere. GlassFish was already available as open source under Sun's CDDL license, and it's not clear that releasing it under GPL will help GlassFish grow into a full-service Java EE platform, but it certainly doesn't hurt.
There are also things that Sun has said they will not be releasing to the open source community. Most notably, Sun is keeping control of the Java language to itself, and is not allowing core components such as APIs to be tweaked by the hoi polloi. Whereas languages like Perl and PHP are developed in an open environment and are capable of being extended by anybody that can demonstrate a need and benefit (although single-source interpreters usually serve to enforce consistency by minimizing actual diversity), Sun has developed Java as a "standard" language and has unequivocally stated that they will retain executive control over the core language for the foreseeable future. In this regard, it's not Java that is being open sourced, it's Sun's Java software.
Likewise, Sun is retaining most of the Java "branding" such as the steaming coffee cup logo, as well as the Java name itself, although they have published guidelines that allow for their use.
Sun is also going to continue offering commercial licenses for the code that is being released, for multiple reasons. For one thing, it allows the existing encumbered code to continue to be made available to the organizations who have already agreed or will agree to comply with the terms of the relevant licenses. For another, it provides a way for developers to avoid some of the GPL language and limitations-if an organization needs to incorporate specialty libraries into the core software for some reason, but is unable to do so while also satisfying the GPL requirements, then a commercial license from Sun would allow them to do so without conflict.
This isn't a scenario that most people will need to be concerned with, however, since Sun has adopted the GNU Classpath exception license for their Java SE components. Under those terms, Java applications that make use of the JVM are not automatically bound by the license terms associated with the JVM, but instead are treated as separate entities for license purposes. As such, the only people that really need to worry about the GPL licensing restrictions are people who muck with the core components, and that's only if they are not using a commercial license from Sun.
All told, Sun's release of their Java SE, ME and EE software is a major industry event, and is likely to contribute significantly to further adoption of the language as a development platform. By many estimates, Java is already the most widely used language, and its certainly smart for Sun to make these moves while they are still on top of the pile. This is particularly true given that Microsoft's .Net development tools are continuing to gain momentum, and Sun had to do something to ensure that Java stays on top.
According to John Andrews, president of the Evans Data Corporation, their research panel of 20,000 developers indicate that Java is the most-used programming language globally, with over 50% of respondents reporting that they spend some time developing in Java. And while Microsoft's .Net languages are currently behind Java, Andrews reports that .Net is growing faster, and it may overtake Java usage in 2007.
Clearly, Sun needed do this if they wanted to retain their leadership advantage, and they had to do it now. But I have to wonder how much further ahead Java would be if these same efforts had been undertaken several years back. Think back to when Microsoft licensed Java, then released an incompatible JVM prior to pushing out their own .Net interpreted languages--if Sun had released an open source version of their own JVM back then, they wouldn't have had to rely on Microsoft for distribution as much, and would have avoided the inevitable collision of interests, weakening Microsoft's case for .Net.
Meanwhile, the UNIX and Web development worlds have proceeded apace with languages like Perl and PHP, even to the point of using them where Java would have been a better choice, and this has largely happened because of problems that have arisen from the lack of a common and consistent interpreter that was freely available. By all these measures, the recent moves by Sun are several years late in coming.
But having said that, these are still significant announcements, and should be applauded by users and the industry alike. In the short-term, the biggest beneficiaries will be those vendors who have committed to Java in a big way already, since this move should make it much easier to develop and debug Java applications. In the mid-term, operating system and embedded system vendors are also likely to benefit from this shift, since they will be able to incorporate an efficient and "standard" JVM into their platforms, without having to dance around vendor-specific licensing agreements. Long-term, users will win the most from having a widely-available cross-platform language and interpreter. The only loser here isMicrosoft, who now has to either match Sun's moves by making .Net runtimes available for other platforms (with GPL licenses), or risk losing developer mindshare to the free and ubiquitous Java.
The benefits to Sun are less obvious, unless you consider wounding Microsoft as a benefit (which, in this case, is probably accurate--if Microsoft doesn't control the common development languages, they can't dictate the future platforms as easily, which helps Sun in the long run). More immediately, Sun will likely increase the number of commercial licenses as a result of increasing the "pull" demand of Java within the market, since more developers means more licensing opportunities, and high-quality (supported) Java libraries may continue to be a strong incentive for a while yet. Sun also sees opportunities for service and support revenue, although that is a longer-term trend that Sun has not yet realized.
Now if they would just include a C compiler in Solaris again....
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 2006 CMP Media, Inc. Used with permission.