Face it, the GPL has become an
almost guaranteed stamp of approval for software to be included in
a Linux distribution. The Debian GNU/Linux distribution, for
example, held out on inclusion of TrollTech's Qt toolkit, which
prevented the KDE desktop from becoming part of their basic
The issue is not one of whether or not Java will become Open
Source by definition, it's one of whether or not Java as a standard
will become Free Software. It is far more important than it might
appear on the surface.
The issue can be sliced many ways. The possibility of Sun losing
control of Java (read, an incompatible, competing version being
spawned) to a nebulous group of Internet-based people might be one
fear. A simple run down of the Linux landscape proves this is not
just unlikely -- there's no proof of this kind of harm ever being
Possibly it's a economic issue -- Sun doesn't see how it would
make any money on Java under the GPL. The latest action by
TrollTech seems to suggest that going from an almost-GPL license to
the GPL itself isn't all that bad, but who am I to judge? I don't
own the property in question (Java) -- it's not my call.
But I can suggest. I can point out that if Sun wants the support
of the Linux and Open Source communities, they might just want to
consider the benefits of the GPL license -- they might also want to
take a good close look at how the GPL helped KDE become a more
widely accepted technology because of the actions of TrollTech.
I come to the most interesting point, I believe, by slicing this
issue in the direction of trust. Not releasing source code under
the GPL has become a red flag to the Linux community that the
technology in question isn't set in stone. It almost says that the
interests that govern it might not trust us that much. I
think a lot of people want to address this issue and remove
emotional content, but I have to point out that it is an emotional
issue as well, and possibly an important one.
This is not to say it doesn't impact the end demographics -- by
GPL'ing Java, Sun will practically ensure that every Linux
distribution contains a copy, or can easily ship with a version
that is easily included. This in contrast with a new (possibly
Java-uninitiated) user finding it, downloading however many tens of
megabytes of code needed, and loading it on their system.
Why is this important? Because Java will get glued into the
nebulous "Linux Standard" (not to be confused with the one the
Linux Standards Base people are working on). When or if Java
becomes part of the borg-like entity a good Linux distribution
currently consists of, it will morph into something else. Something
with far more potential.
Part of what is going on here has to do with Linux as a powerful
baseline product. When new technologies get added to the baseline,
the number of possibilities for what can be done with that product
by the Linux distributors goes up by another exponential. Think of
what the inclusion of Python has done, for example, or Tk, or Perl
-- each new language, tool, toolkit or package yields another
degree of freedom.
Allow me to expand upon this, from my own point of view. We use
Linux for the Linux/Open Source Channel web sites at internet.com. We use Apache, Perl, PHP,
MySQL and to a much lesser degree, a host of other products. We
don't often use anything that isn't published under the GPL or a
GPL compatible license to do our important work.
The reasons are many. First, I think it would be almost
heretical to publish Linux Today using proprietary software. It
would almost be synonymous with "I believe Linux is going places,
but I don't think it's up to the task of publishing a simple news
site." I don't think I could face the crowd with a straight face.
This, you would think, would be fairly easy to understand, and yet
at times I've been approached by people who suggest that we should
be using Java (JSP technology) and even proprietary web server
This, in the face of perfectly good server side programming
technology -- PHP. To use Java,
instead of PHP in this case, would ignore the licensing issues that
my target audience holds dear. To use another web server -- and
especially a proprietary one -- almost totally ignores the
incredible success story of Apache.
I've said it before, Apache is the real poster child of the
success of Free Software. To ignore it, and use a proprietary
product -- no matter how cool, is in my own non-humble opinion,
stupid for a web site like Linux Today.
Some of the members of the audience may take issue with this,
pointing out that downloading and installing products isn't that
big of a deal. I would counter that with the fact that new users
and people who just wish to experiment with something don't always
see it that way. On top of that, the Linux distributors themselves
can increase the functionality of their distributions when products
like these are available as tools.
So, getting back to the issue at hand: Java. I'm in the slow
process of learning Java right now myself. I'd like to bank on it,
as part of my own hacker toolkit for the future. I have to say that
I'm less excited about it if the creators of that technology can't
see what benefits they gain by GPL'ing the software. I almost feel
that they want to pull a Microsoft on me in the future, to
put it in more emotional terms.
I almost question the sincerity of Sun at times. I was impressed
to see them finally publish Star Office under the GPL. They talk
the talk a lot -- about being open, that is. They don't always walk
the walk. When they finally broke down and GPL'd Star Office I
thought they might finally be getting it.
The issue is that of providing tools to the base installation of
an operating system. By doing so, they provide the developer and
end user communities with yet another set of tools to improve the
power of an operating system out of the box, and they provide
themselves with a platform to raise the awareness (and dependence
upon) their products. This, I believe, is a win-win scenario.
The same goes for Sun's Java, as a matter of fact. They can
choose not to use the GPL. I can chose a different language. These
are balancing forces.
Exclusive Control as a Marketing Bottleneck
It's also a Chinese puzzle of sorts. People don't want to depend
upon a technology that doesn't have some kind of guarantee of
longevity. By releasing some control on Java, Sun will in some
respects be increasing it's power as a platform tool. I don't doubt
that it's a delicate balance, and I also don't doubt that it's not
easy to decide. But by being the sole entity in control of Java,
Sun in effect weakens my perception of the technology from a
skeptics' viewpoint. If Sun goes under, Java can potentially go
This is yet another dimension, in many. If you've been paying
attention all along, you might notice that I've tried to cover the
issue of a GPL license for Java from many points of view. The
reason is because the Linux and Open Source communities are
diverse, and the people involved see the issue from these different
directions (and many more, I'm sure).
Whatever the direction Sun chooses, they now have a motivating
force on the other side of the fence. Microsoft is now attempting
to market a Java-like language (C#). In typical fashion, they show
how not to do it as far as open standards are concerned.
C# is controlled solely by Microsoft, published only as a language
(we don't get the source to it, in other words) and so on.
Microsoft hopes to kill off Java, in other words, using whatever
diminishing market clout they have remaining.
To cover the issue from another direction, I asked Rob Levin, an
engineer at Transvirtual Technologies, what his opinions were
regarding the subject. Transvirtual Technologies makes, among other
things, a Java virtual machine (JVM) that runs on many platforms,
and is released under the GPL license.
"From the standpoint of the customer and end/user -- the people
who use the technology -- releasing Java as an open-source item has
no down side. What you get is a truly open standard. A standard
that the customers can affect directly. They can have input and
make sure it does what they need it to do."
"From the standpoint of Sun, it may not be as big a win because
they're playing the zero sum game. They want the flexibility to
charge or not charge for a license to their software. That's the
flip-side of the coin."
"A closed standard ensures the vendor has a lock on it. The
vendor has control over its product, but also the products of any
competitor who signs onto that standard. And the very existence of
a standard is a big marketing advantage to the vendor who controls
Levin was clear about the disadvantage Sun will likely face if
they don't Open Source Java: "It's a real problem for the growth of
Java and the people who use it."
But would this be an advantage for Transvirtual? "That's hard to
say." Levin explained. "It would give us more source code to work
with. It would let us collaborate better with Sun in the standards
"From the customer standpoint, it would mean there's more than
one open source vendor for Java available. Choice is always a good
For example, Transvirtuals' Java engine is already available as
part of Debian Potato, Sun's JVM could be offered easily as an
alternative if it were available under the GPL.
"There are various free alternatives to Java that are out there,
including our stuff which is a pretty complete embedded solution.
If Sun does not open-source their product, and if they don't help
move the standards process along instead of holding it back, we
will be less concerned with Java compliance than with the features
in Kaffe that our users need.", said Levin.
Clearly, the ball is in Sun's court. Nobody is saying that they
need to give away the store here. The consensus seems to be that
the language and the source code for the JVM at least should be
made available to the community. By continuing to hold to non-free
licenses like the one that used to cover Star Office, Sun seems to
demonstrate an unwillingness to "Walk the walk" of a modern Open
Part of that walk is trusting that the communities that surround
Linux and Java would add to the power of the product in the long
run, which would enhances Sun's position as a provider of truly
What will be the fate of Java without this commitment?
Levin elaborates: "I haven't taken a poll of the other
open-source Java related projects, but I suspect that a number of
us would end up standardizing our products around something other
than Sun's Java implementation. And unlike Sun, Open Source people
know how to collaborate on standards."