LWN.net Weekly Edition for August 17, 2006

Coming soon: a free Java

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:

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)

X.org, distributors, and proprietary modules

X11R7.1 (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 proprietary modules.

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:

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 update.

Needless to say, this decision has not been met with universal acclaim. One Fedora user asked:

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 X.org 7.1.

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)

cdrtools - a tale of two licenses

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 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 cannot mix.

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)