Sun Microsystems took advantage of LinuxWorld to announce that, at long
last, it was serious about releasing much of its Java system under an open
source license. The upcoming releases - which could happen by the end of
the year - will include both the Java Standard Edition and Java Micro
Edition products. The Hotspot VM and the Java Development Kit are to be
part of this release. For many Java developers, this is the moment they have
been waiting for. Of course, there are a few remaining questions.
For years, Sun has resisted calls to release Java. The company's primary
reason for keeping Java proprietary was that it was necessary to keep Java
implementations compatible. A truly free Java would compromise the "write
once, run everywhere" promise frequently made (if less frequently kept) by
Sun. So, one might well ask what has changed. Here's the story from Sun:
now think the benefits of accelerating innovation, opening new
markets and opportunities, and fostering creativity that the open
source model brings now outweigh the risks to compatibility. These
risks are real, but at Sun, we believe that the wisdom of the
community has evolved to where the market and developer community
itself will act to demand compatibility as a bedrock feature of any
implementations based on Java technology.
So, in other words, we are now smart enough to be entrusted with a free
Java. Better late than never.
The usual post-announcement routine will have to be endured before a free
Java is a reality. A thorough review of the code must be done so that
Sun's lawyers can convince themselves that Sun has the right to release it
all, and any encumbrances must be dealt with. Some sort of governance
model must be chosen: who will decide what changes make it into mainline
Java? Sun will want to retain some control here, but an overly
tight-fisted approach could encourage a fork of the code and a potential
loss of the compatibility that Sun values so highly.
Then, there is the issue of what license is to be used for the Java
release. One might expect Sun to reach for the CDDL first, and that might
be just how it plays out. But Sun might just want to consider how the
newly-licensed Java would play with existing free projects. GNU Classpath is licensed
under the GPL, so mixing of Java and Classpath code can only happen if Java
carries a GPL-compatible license. On the other hand, the Apache Harmony project,
which has made great strides toward an independent and free Java SE
implementation, is using the Apache V2 license, which is not
compatible with the GPL. This license difference has helped to keep
Classpath and Harmony separate until now, and Java may have to choose a
side (or neither).
One intriguing possibility is that Java could be released under GPLv3 (as
soon as that license is real); version 3 of the GPL is intended to be
compatible with the Apache license.
All of this depends on whether Sun places any value on license
compatibility with the other projects or not - and how that value compares
to Sun's other goals. Sun will have to work through a lot of issues before
it can come to a real answer to these questions. But it does appear that
the company has committed itself to releasing Java under a free license,
and that can only be a good thing.
Comments (21 posted)
(also known as X.org 7.1) was released back in May. It contains a number
of useful new features, better 3D performance on a number of video
adapters, and tons of fixes. It is, in general, the platform that X users
probably want to be using. This release is not as widely used as it could
be, however, and the associated story illustrates one of the costs of
One of the developments merged into 7.1 was the AIGLX
project, dedicated to the important goal of providing better eye candy for
Linux users worldwide. Since this code had gone into the X.org mainline,
the Fedora-based AIGLX developers decided that there
was no reason to continue to maintain their own version. So the Fedora
AIGLX repository stopped seeing updates; Fedora users wanting to use the
current AIGLX code could get it straight from X.org 7.1.
The Fedora Core 5 distribution, however, shipped X.org 7.0. So, it
was asked: would FC5 be updated to X.org 7.1? A major upgrade of this
type might not be something all distributors would contemplate, but Fedora
is supposed to move rapidly. As a matter of policy, Fedora tends to fix
problems (and security issues in particular) by upgrading to the current
release rather than by backporting fixes. So, back at the end of July, it
was announced that there would be an
X.org 7.1 update for Fedora Core 5.
Just one little problem stood in the way: the binary-only drivers from ATI
and NVidia did not work with X.org 7.1 (ATI has since released an
update). Perhaps, it was suggested, the X.org update could be postponed
until such a time that the proprietary module vendors had released
compatible versions? This idea was fairly strongly criticized on the
mailing lists; Fedora is supposed to be a 100% free software distribution,
and should not have to concern itself with the behavior of proprietary
software vendors. Mike Harris, the Fedora X.org maintainer at that time
(he has since retired), was quite clear on the subject:
Fedora does not support proprietary drivers at all, and never has,
nor has any Red Hat OS that preceded it. Our OS products are not
held hostage to the release schedule whims of 3rd party proprietary
Part of the decision of choosing proprietary software, is making a
conscious decision that you are held hostage by the vendor of that
software to provide you with support for it. That unfortunate
limitation should not expand to encompass all users of open source
software. If that happens, everyone loses.
By this reasoning, everybody has lost. The Fedora advisory board met to
discuss the issue; the resulting decision
was that Fedora Core 5 would not be updated to X.org 7.1. The
conclusion was that the interests of Fedora users using proprietary NVidia
modules outweigh the interests of other users who would benefit from this
Needless to say, this decision has not been met with universal
acclaim. One Fedora user asked:
If you were the owner of a company that had just announced plans to
open source your drivers, would you feel you had made the right
decision if a major linux distribution announced it had changed its
mind about releasing the software that enabled your driver to run
and delayed its shipment for two months *because* there were still
vendors whose proprietary drivers were not updated?
The board has spoken, however, and the decision stands. Fedora users who
are not up for the (sometimes hair-raising) experience of running from the
development repository will have to wait for Fedora Core 6 to get
Lest anybody think that this is a Fedora-specific issue, a
visit to this
Gentoo forum discussion may be of interest. X.org 7.1 remains
masked in Gentoo for the same reason - lack of proprietary vendor support -
and over half of the people voting in the attached poll believe that
situation should continue. Interestingly, only the x86 and amd64
architectures are being held back. The other Gentoo-supported
architectures, for which NVidia and ATI modules are never available anyway,
have moved forward to the current X.org release.
In both cases, distributors are acting in what they believe is the best
interest of their users. Regardless of what one thinks of the outcome, it
is encouraging that quite a bit of thought is clearly being put into the
effects of changes on the user base. What is rather less encouraging is
that the best interest of (at least) Fedora and Gentoo users is in the
hands of proprietary module vendors, and that this dependency is imposing a
cost on all users, whether they use the modules in question or not. These
vendors should not have veto power over the release plans of free software
distributions. One can only look forward to the day when current video
hardware from all vendors can be used on 100% free systems.
Comments (124 posted)
When Sun Microsystems set down to create a license for the release of
Solaris and other code, the end result was the Common
Development and Distribution License
or CDDL. Most people who have
looked hard at the license have agreed that it is, indeed, a free software
license. It is also, however, considered to be incompatible with the GNU
General Public License (GPL); the Free Software Foundation has this to say
about the CDDL:
This is a free software license which is not a strong copyleft; it
has some complex restrictions that make it incompatible with the
GNU GPL. It requires that all attribution notices be maintained,
while the GPL only requires certain types of notices. Also, it
terminates in retaliation for certain aggressive uses of
patents. So, a module covered by the GPL and a module covered by
the CDDL cannot legally be linked together. We urge you not to use
the CDDL for this reason.
This license incompatibility has, among other things, put a roadblock in
the way of incorporating any Solaris code into the Linux kernel (and vice
versa). The two remain in their own separate licensing universes, and
Not everybody appears to share this opinion, however. Consider Debian bug
377109, filed by the sharp-eyed license watchers in that camp. It
seems that Jörg Shilling, the maintainer of cdrtools (containing
cdrecord, mkisofs, and other tools), decided to license his build system
for those tools under the CDDL. The GPL requires that build tools and
scripts also be released under the GPL, so mixing the CDDL build system
with the GPL-licensed CD/DVD tools made the whole thing undistributable -
at least, in the eyes of the Debian developers.
Since that bug was filed, the situation has evolved somewhat. The current 2.01.01
cdrtools release has relicensed a number of code components under the CDDL.
The relicensed bits include cdrecord and libscg. Other components, such as
mkisofs and libparanoia, remain under the GPL and LGPL, respectively. Some
of these licenses are unlikely to change; the mkisofs code has copyrights
held by a number of people (and companies) other than Mr. Schilling, and
going back as far as 1986. Since mkisofs, at least, is built with libscg,
the resulting system is a combination of GPL and CDDL-licensed code. In
the minds of most observers, this combination is not distributable.
The Debian developers are now trying to figure out what to do about this
situation. As most people familiar with the relevant personalities would
likely expect, conversations with Mr. Schilling have not come to any sort
of productive outcome - though it has yielded an amusing nine-point plan from Mr. Schilling
on how to fix Debian's cdrecord problems. A very possible outcome is that
Debian will drop Mr. Schilling's cdrtools distribution and maintain a fork
starting from the last distributable version; other distributors may well
follow suit. The dvdrtools project has
been pointed out as a possible starting point.
Forking cdrtools is not a particularly new idea. This package has been the
subject of a long series of inflammatory disputes with its maintainer, who
does not always agree with the Linux way of doing things. People have
often wondered in public just why this version of cdrtools was still in
use. The answer, presumably, lies in the fact that (1) cdrecord works
for most people, who can happily ignore its maintainer, and (2) CD/DVD
recording is a complex and tricky business which intimidates many
developers who might otherwise jump into the code. Whatever the reasons
might be, no cdrtools fork has gotten very far.
The licensing issue might just be the final straw that makes a viable fork
happen. Distributors can ignore a difficult maintainer, but it is harder
for them to ignore possible licensing issues. If they decide that cdrtools
cannot be distributed in it current form, they will have no alternative to
ceasing distribution - and that means coming up with a replacement. This
may be the year when, finally, cdrtools for Linux finds a new maintainer.
Comments (75 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: OpenOffice.org security concerns; New vulnerabilities in drupal, gallery, heartbeat, rails, ...
- Kernel: Network block device deadlock prevention; Code of (still) uncertain origin; The cdev interface.
- Distributions: Speedy Fedora updates; Ubuntu 6.06.1 LTS; RHEL 4 Update 4; Slackware 11.0 RC 1; openSUSE 10.2 Alpha3; Gentoo Overlays project
- Development: Tux Droid brings Tux the penguin alive,
new versions of dkop, Linux-HA, MySQL, SQLite, sendmail, Hobbit Monitor,
SSL-Explorer, Gallery, acpitool, Jitterbit, GanttProject, Wine, SquirrelMail,
FreeMED, stygmorgan, Parrot.
- Press: Extending the GPL for application service providers, Linux's Legal World After SCO, LinuxWorld coverage, proprietary vs. open graphics drivers, Testing Apache configs, printing labels with Linux, Twisted programming, Ubuntu's
New Users Network, SeaMonkey review.
- Announcements: Creative Commons 3.0 license discussion, EFF: legal fees for the wrongly
accused, OpenVZ for RHEL4, Ingres announces Project Icebreaker, LinuxWorld announcements, LPI Linux jobs, SCALE 5x CFP, LinuxBIOS Symposium EU,
Wizards of OS, GFiles.org launched, Yahoo's Python developer network.