---

Digging Deep into the Sun/GPL Announcement

By James Turner
Senior Editor

Human sacrifice, dogs and cats living together – mass
hysteria.
      – P. Venkman, Ghostbusters

Well, the other shoe has dropped.

It’s been an open secret ever since Sun open sourced Solaris
(albeit under their own GPL-incompatible license) that Java was
likely to be the next target. With C# and Mono, not to mention PHP,
Python and all the other P-prefixed languages chasing at Java’s
heels, something had to be done to keep Java near the top of the
pack.

The conventional wisdom for most of the previous year has been
that Java would be released under the same one-off-for-Sun license
that OpenSolaris was, the CDDL. The most notable thing about the
CDDL is that it is neither compatible with the GPL, Apache, or BSD
licenses. This meant that while Solaris code was in the wild, it
was not mergable with Linux or BSD code. Essentially, the Solaris
code lives in a open source island of its own.

By placing Java under the same license, Sun could have
technically open-sourced Java while still keeping any useful
cross-pollination of technology from occurring, either with the
existing open source Java projects such as Kaffe, or with other
open source projects (such as Linux itself.)

About a month ago, surprising rumors started to emerge that
instead of the CDDL, Sun had chosen to release Java under the GPL.
Today, Sun has confirmed the rumor and made the initial set of
sources available under that license. This is indeed a significant
development, and has a number of important ramifications.

Firstly, let’s look at exactly what’s being released under GPL.
To begin with, Sun is releasing the entire Java Development Kit
(JDK) for the Java 2 Standard Edition (J2SE). In reality, a few of
the class libraries use closed source technology, and will have to
delivered in binary form until new open source alternatives are
written, but now that everything is out in the open, Sun seems to
think that this task can be done relatively quickly. The JDK
includes javac, the Java compiler, and the JRE (Java Runtime
Environment) It also includes all the standard libraries. In
addition, the Java Mobile and Embedded (J2ME) codebase is also
being placed under GPL. This is the technology used inside mobile
phones and other embedded devices.

If you look closely at the announcement, you’ll see that the
actual license being used is “GPL2 with Classpath Exemption.” By
their own admission, this essentially is the same as placing the
class libraries under the Lesser or Library GPL (LGPL.) This means
that non-GPL licensed applications (such as Apache, BSD, Mozilla or
even commercial applications) can access the J2SE class libraries
without being required to be GPL compliant. This is an important
point, because otherwise the “virality” of the GPL license would
apply to software that required the J2SE libraries. In summary, the
only time the GPL kicks in is if you want to modify the compiler,
runtime or libraries themselves.

I was discussing the potential GPL-ing of Java with some friends
last week, and made the comment that if Sun used a pure GPL license
for Java, it would represent a clever dual-license model. Any
commercial product that wanted to ship a JRE along with their
product would have been forced to purchase a commercial license.
However, Sun has apparently decided to adopt a RedHat-style
business model instead, looking to support contracts from their
high end customers to provide their revenue stream.

I have to say that I think this is a big win for Sun, and for
the Java community in general. To begin with, Sun gets a massive PR
boost and an infusion of good will from the open-source community.
By choosing the GPL, and allowing unlimited linking to the
libraries, Sun avoids the negative perception that the CDDL would
have brought, that it was open sourcing in name only. They also
avoid alienating commercial customers who wish to incorporate Java
into their products. It will also probably encourage more
widespread use of Java in open source projects, and more eyes on
the Java code.

It’s a win for the Java community because it keeps Java
relevant. There have been a lot of mutterings over the years that
Java was bloated and slow; a dinosaur in the age of PHP, Python and
Ruby. While I tend to disagree, a GPL Java can be dissected and
tweaked by the army of open source hackers that have kept Linux so
lean and clean. It also puts Java head and shoulders above C# (and
to a lesser extent, Mono), as a pure and unencumbered open source
technology.

It’s a win for Linux distro developers because Java can now be
included in every Linux distribution, rather than requiring a
post-installation download. Consequently, it means that Linux
system applications could be written in Java (when appropriate.) I
expect that Java will be a core part of every Linux distribution
within a year. And this has the cascading benefit of making it
easier to deploy commercial and open source distributions written
in Java onto Linux. Right now, every self-contained Java
application has to bundle a copy of the JRE, making them pretty
huge. Once the JRE is a standard part of Linux distributions,
they’ll be tiny.

It’s a win for GPL-licensed Java clones such as Kaffe and the
GNU Classpath project. They can choose to raid the JDK for code to
improve their own versions, work to contribute their improvements
back into the base Java codebase, or a mixture of both. It’s less
of a win for Apache’s Project Harmony. Since it has an incompatible
license, no code transfer can occur. Frankly, since the goals of
Harmony are essentially to do exactly what Sun has done today, I
expect Harmony to go away over time, and their developers to shift
over to the OpenJDK project instead. Of course, I’m sure some
die-hards will stick with Harmony out of irrational loyalty,
otherwise it wouldn’t be an open source project.

It’s a win for the FSF because it brings another major
technology under the GPL. Linux has always been the poster child
for the GPL, now they have another one with Java. And Java is even
better, because it shows that there’s a model for industry to work
inside the GPL. It’s significant that both Eben Moglen (chief
council for the FSF) and Stallman himself has nothing but good
things to say about the announcement. And in return, Sun was very
careful to use only the awkward GNU/Linux moniker in their press
releases.

There is the minor danger of forking the Java codebase. The last
thing the world needs is a dozen incompatible versions of Java.
Preventing this is the fact that Sun retains ownership of the
trademark and the ability (through the Java Community Process) to
define exactly what “Java” is. They also retain branding rights on
the well-known coffee cup logo, although the much more obscure
“Duke” mascot has been placed under the GPL. So Microsoft still
can’t product a Windows-only version of Java, and call it Java. And
if they based their version on the Sun codebase, they’d have to
place their changes under the GPL as well.

This step represents a major evolution of Sun as an open source
player. I was intimately involved with Sun’s decision to open
source Solaris, as initial editor of their OpenSolaris web site. At
the time, Sun was just beginning to “get” open source, I spoke at
an all-day symposium they put together to educate their engineers
about how the open source process worked and it was clear that
there was a lot of suspicion about the whole enterprise.

Fast forward to now. In a little over a year, Sun has moved to
embrace the GPL and placed what many consider their crown jewel
under it’s wing. It will be hard for anyone to find fault in Sun’s
move, since it offers the maximum amount of freedom (in the FSF
meaning of the word) without restricting freedom (in the commercial
software sense of the word.) After a week of nervous analysis
concerning Novell’s new alignment with the Forces of Ultimate Evil
(Redmond Edition), the open source community needed a piece of good
news.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis