David Berlind: The ripple effect of a GPL’d Java will reach far and wide

It's official. Despite some saying it couldn't be done, not only is Sun open sourcing Java, it's doing it under version 2 of the Free Software Foundation's GNU General Public License (GPLv2) using an FSF-endorsed footnote known as the "classpath exception." The FSF's classpath exception gives developers a bit more latitude than just the GPL itself by allowing developers to tie Java libraries into their executable code without forcing those final executables to conform to the GPL which is the normal GPL practice. 

It's official. Despite some saying it couldn't be done, not only is Sun open sourcing Java, it's doing it under version 2 of the Free Software Foundation's GNU General Public License (GPLv2) using an FSF-endorsed footnote known as the "classpath exception." The FSF's classpath exception gives developers a bit more latitude than just the GPL itself by allowing developers to tie Java libraries into their executable code without forcing those final executables to conform to the GPL which is the normal GPL practice. The exception text states the following:

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

The FSF's classpath exception was originally created to go along with FSF's GNU Classpath. GNU Classpath was a set of developer libraries that the FSF community was working on to build a free software (not just open source) version of Java much the same way GNU Linux represents free software versions of many of the utilities found in Unix. In open source fashion, essentially, the free software community had been working to produce a free software clone of Java.

Now that Sun has open sourced Java using precisely the same licensing terms that the FSF had applied to GNU Classpath, the FSF will have no trouble endorsing the code as true free software essentially springing the so-called Java trap that FSF patriarch Richard Stallman had, in a 2004 essay, accused Sun of setting. In fact, during today's press conference, Sun played a video of Stallman not just saying that "the Java trap won't exist anymore" (as it applies to Java), he gave a stunning endorsement of Sun's behavior and contribution (as the largest contribution of its kind to the free software community). It was a complete 180 degree turn in disposition for the leader of the free software world. Sun's open sourcing of Java means that efforts to continue cloning it (in GNU Classpath) should probably be supplanted with efforts to migrate. Over at the Classpath.org web site, after praising Sun's move,  open source developer Roman Kennke wrote:

…..this is from my developer POV only. The fact is that now there is really no hard need for the GNU Classpath project anymore. But I want to raise two aspects here: 1. Many projects are built around GNU Classpath right now. It won’t be exactly easy and trivial to port them over to Sun’s libraries. Surely, it can and will be done, but for the time beeing GNU Classpath is still needed. (And could IMO provide a migration path). 2. The development environment of GNU Classpath is much more flexible right now. This spirit of hack - test - commit is part of what makes GNU Classpath attractive for developers, including me. I don’t think that this will be possible with Sun’s code, and rightly so. So, what I really would like to see would be a development process on Sun’s (and our) side that would allow hackers to hack on whatever project they like, and let one project include code from the other. Now, that is not an easy task and might not be possible at all. But let’s dream for a moment (man, those endorphines seem to be high today ). So, I think both codebases will peacefully coexist for a while, and most likely converge too quite a great degree….

Kennke also wrote that by open sourcing Java, Sun can expect to see resolution to some of the platform specific dependencies that interfered with with Java's write once run anywhere promise (specifically on the mobile front).

Of important note is the fact that not all of Java will be going open source overnight. According to Sun's chief open source officer Simon Phipps, the first parts of Java to be open sourced will be a reference implementation of Java Enterprise Edition (JEE) and the Connected Device Configuration (CDC) piece of the mobile version of Java otherwise known as Java Mobile Edition (JME).

The reference implementation of JEE being open sourced under the GPL is the same one that was released under the name Glassfish using the Sun-authored CDDL open source license. Last week, Sun and Canonical, the outfit that distributes the Ubuntu distribution of Linux, announced that  Glassfish would be included in Ubuntu Linux. Ubuntu Linux was the first version of Linux to be certified to run on some of Sun's UltraSparc T1 "Niagara"-based servers and more recently was certified to run on the company's Opteron-based servers and workstations. 

In my opinion, having that sort of hardware support is a key element that Sun needed to have in place in order for the open sourcing of Java to make sense to the company's investors. One of Sun's talking points when it comes to explaining why it makes sense to open source Java is how open sourced ecosystems attract more participants which in turn should mean added traction for the company's hardware. But, with Linux being the most popular deployment platform for JEE-based applications (and Linux often perceived to be "water" when matched Sun's hardware "oil"), Sun needed demonstrable proof that its hardware platforms — particularly its higher margin N1 gear — are certifiably legitimate targets. 

On the mobile Java front, JME CDC JME CLDC is found in many cell phones and is one of many fragments of Java known as Java Specification Requests or JSRs, all of which are tracked and maintained under the auspices of the Java Community Process (to which many vendors contribute).

According to Phipps, CDC's immediate release will be followed by the release of the JME Connected Limited Device Configuration (JME CDC) which should be ready in the next couple of weeks. Set-top boxes and Blu-Ray DVD systems are examples of the types of devices that CLDC is used in. [Update: During the press conference regarding Sun's announcement, Sun's Richard Green announced that instead of being spaced out, CDC and CLDC would both be released immediately.]

Although JEE is often talked about as "big Java", the real big Java is probably Java Standard Edition (aka Java SE).  Not only does Java SE run at the heart of the version of Java found on many desktop and notebook computers, it's also the kernel that Java EE runs on. According to Phipps, the code behind Java SE is going to take a bit longer to publish as open source.  Perhaps six months.  Said Phipps:

At the moment all the code kept internally in a control system known as Teamware that's very old and it (the control system) is not open source.  We're going to move all the code from Teamware over to Mercurial, a distributed version control system. It's a process that's going to take some time. I don't quite know if will be released incrementally or if we'll wait to release it all in one big bang.

In the bigger picture, Sun's open sourcing of Java has also sorts of implications. Not just for Java itself and Sun, but for other companies and open source projects. For example, now that Java has been open sourced under the GPL, both IBM and Microsoft may have some recalibrating to do. 

IBM — one of Java's biggest proponents and one of Sun's biggest licensees — has long called for Java to be open sourced. Over the years, IBM has complained about a variety of issues ranging from the licensing fees it has had to pay to the fact that Sun had too much veto power over the what happens at the Java Community Process. But it already appears as though open sourcing Java under the most widely deployed open source license is still not enough to assuage IBM. Now, according to CNET News.com's Martin Lamonica, IBM is voicing concern over Sun's selection of the GPL versus that of Apache's open source license. IBM has been a supporter of a variety of open source Java efforts taking place at the Apache Software Foundation. Wrote Lamonica of a statement issued by IBM today:

"In light of the Apache projects, we have discussed with Sun our strong belief that Sun should contribute their Java technologies to Apache rather than starting another open-source Java project, or at least make their contributions available under an 'Apache friendly' license to ensure the open-source Java community isn't fragmented and disenfranchised, instead Sun would be bringing the same benefits of OS (open-source) Java to this significant and growing open source community," the statement said.

Although I'm not sure about disenfranchising part (how could anyone say that a large contribution to the FOSS community under the GPL will disenfranchise it), in reality, Sun had no choice but to make a fragmenting choice. By choosing to go with the GPL, the move equates to legal alienation of the Apache community. Had Sun gone with the Apache license, it would have legally alienated the GNU Classpath community. Sun had to make a choice. During today's press conference, via instant messenger, I noted IBM's comments and asked Sun executives why not pick Apache instead. In response, Sun's software chief Richard Green said "There is no perfect choice. We chose what we thought was best for Java and for the community." In the back of my mind, I was wondering whose endorsement was more important for Sun? Stallman's or IBM's? I think the answer is obvious.

But, in what was an obvious reference to the proprietary nature of IBM's JEE offering (Websphere), Sun CEO Jonathan Schwartz said "It would not surprise me in the least to see a growing number of proprietary software companies see this as a threat."

There's an obvious reason that proprietary software companies prefer the Apache license over the GPL.Via telephone earlier today, Larry Rosen, the open source lawyer who literally wrote the book on open source licensing, told me:

The Apache license allows you to take the software [distributed under it], create derivative works of that software, and distribute those derivative works under any license you want [including proprietary ones] whereas the GPL requires derivative works to be distributed under the GPL. The Apache license is compatible with proprietary software where as the GPL is not.

Even so, I can see why this was a tough choice for Sun. In choosing which direction to go, Sun had to make a choice to be more compatible with GNU Linux (licensed under the GPL), or more compatible with Apache. In terms of percentages, I'm willing to bet that a higher percentage of Java installations run side-by-side with Apache than they do with Linux.

But, in finally answering IBM calls to open source Java, there's no doubt in my mind that Sun knew exactly the sort of indigestion that selecting the GPL would cause to IBM. In doing so, much the same way it's probably best for the existing GNU Classpath project to be wound down, it probably doesn't make a lot of sense to continue redundant investments in other open source clones of Java at this point. With the selection of the GPL, Sun may have completely neutralized the enourmous investment that IBM has so far made into open source Java. Especially now that Sun's selection of the GPL paves the way for Red Hat, Suse, and others to include Java with their Linux distributions.

In fact Schwartz came right out and said that Sun consulted with Red Hat (which is rather amazing, in and of itself). In other words, the issues aren't just legal or technical. There will be a certain amount of gravity in existing market channels that could make redundant investment completely impractical.

If and how multiple but legally-incompatible open source Java projects can ever be reconciled, I have no idea. But just to throw another twist in the rub between IBM and Sun (perhaps fodder another post), open sourcing Java could shake things up a bit in NetBeans vs. Eclipse land. Personally, I think the news is more favorable to Eclipse than NetBeans given that Sun's beef with Eclipse has always been the extent to which it marginalizes Sun's write once, run anywhere promise. But the developer community behind Eclipse is big enough to say that Sun's arguments have been rejected to the point that a merger of Eclipse and NetBeans should be reconsidered. Now that Java is has open sourced, much the same way some write-once run anywhere problems may end up getting solved by open source developers, new ones, along the lines of the things that Eclipse originally did (and that enraged Sun) will spring up. Now, Sun has no choice but to go along with that sort of innovation and continued adherence to the party line would be somewhat hypocritical. But legal challenges. remain. Eclipse is not licensed under the GPL. 

Over in Microsoft land, some .Net folks may need to reach for the Pepto as well. After years and years of downplaying the legitimacy of the open source model and GNU Linux, I don't think anybody at Microsoft is under any illusion about the realities of operating system commoditization. Despite Microsoft's insistance that the open source model was incapable of producing a worthy operating system alternative to Windows, it did just that in Linux. Over the years, independent developers and commercial vendors alike have come forward with contributions that have caused the Linux ecosystem to hockey stick at the expense of Windows and proprietary Unix. By open sourcing Java (which was already off to a big head start over .Net), Microsoft could be in for a repeat of what happened with operating systems, but this time, with middleware instead. 

Where might the impact on .Net be felt first? Well, there are millions of developers out there all working with different languages most of which are not compatible with either Java or .Net. That's right. Compared to the number of languages that work with one or the other, there are many more that do not. Now that Java is being open sourced, the way has been paved for developers who want to connect their favorite language to the Java Virtual Machine to actually scratch that itch. In other words, in the past, it may have taken an act of Sun in order to get dynamic language support for some languages the way it has for Ruby. And, if there's one thing that can really put an open ecosystem on turbo-chargers, it's dynamic language support. Microsoft's .Net, by the way, offered dynamic language support long before Java did. But now, it will be far easier for the Java community to marshall the resources of the open developer community to cultivate a wider range of dynamic language support.

It was probably not a moment too soon that Sun open sourced Java. In my opinion, whereas Java has long been the platform of choice for enterprise-class networked applications, the dot com revolution along with the shift to Web services-based compositing of applications and the proclivity of startups to use lighter weight platforms such as PHP or Rails for rapid to market development are all trends that were well positioned to permanently marginalize Java so long as it remained a "closed" ecosystem. PHP and Rails may not have the industrial strength that Java has. But that would have been like saying years ago that MySQL will never drive mission critical applications (or evolve to the point that it can) or that JBoss can't be considered in situations where BEA's Weblogic or IBM's Websphere might normally be applied.

Real work actually gets done on lesser-capable platforms and over time, those platforms mature anyway. Ironically, the opening up Java could stimulate the sort of innovation that makes it just as viable in lighter weight situations as it always has been in the industrial strength ones. 

Read the original article: http://blogs.zdnet.com/BTL/index.php?p=3937