LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
|
| |||||||||||||
LWN.net Weekly Edition for May 22, 2003GNU and Ghostscript part waysThe recently announced GNU Ghostscript 7.07 release will be the last. GNU Ghostscript - a free PostScript and PDF interpreter which lurks at the core of free print systems worldwide - is the result of several years worth of cooperation between its developers and the Free Software Foundation. Disagreements over the best way to create free software have brought an end to that cooperation - and to GNU Ghostscript. Fortunately, users of GPL-licensed Ghostscript should see little, if any, change.Many companies have tried innovative licensing schemes as a way of creating free software while making enough money to pay their programmers. Ghostscript works with a variant of the "escrow" approach. New Ghostscript developments are released under the Aladdin Free Public License (AFPL), which is not a free license. It gives users the right to use, modify, and distribute copies of AFPL Ghostscript - with an important restriction:
Distribution of the Program or any work based on the Program by a
commercial organization to any third party is prohibited if any
payment is made in connection with such distribution, whether
directly (as in payment for a copy of the Program) or indirectly
(as in payment for some service related to the Program, or payment
for some product or service that includes a copy of the Program
"without charge"; these are only examples, and not an exhaustive
enumeration of prohibited activities).
In other words, the Ghostscript copyright holder (artofcode LLC) reserves the right to make money from the distribution of Ghostscript. If you want to distribute AFPL Ghostscript as part of a commercial product (i.e. inside a printer), you must come to an agreement with Artifex Software, which handles these deals. After one year has passed, however, the AFPL-licensed code is re-released under the GPL as (until now) GNU Ghostscript. Of course, by that time a new batch of code will be just beginning its time under the AFPL. The end result is the the GPL version is always a bit old. It is, however, clearly good enough for most users; most Ghostscript users probably never bother to download and install the AFPL version, even though they have the right to do so. According to the Free Software Foundation's Bradley Kuhn, the FSF, while accepting the GNU Ghostscript releases, has never been entirely comfortable with the method by which they are produced. There is, he says, "nothing important enough to be worth sacrificing freedom for." So the non-free Ghostscript releases have always gone against FSF principles - even if, in the end, it results in a much improved free Ghostscript. (The FSF also is not convinced that the Ghostscript model results in improved free releases; Mr. Kuhn cites the MySQL approach as, perhaps, a better way of doing things). The difference in viewpoints between the FSF and the Ghostscript team have resulted in two issues which have, at this point, brought about the end of the GNU Ghostscript releases. The first is the FSF's insistence that nothing in GNU Ghostscript can even mention that AFPL Ghostscript exists. This is not a new situation - see this note from Richard Stallman in response to the GNU Ghostscript 5.10 release announcement back in 1998. That announcement mentioned AFPL Ghostscript 5.50, which was set to become GNU Ghostscript 5.50 several months later; this mention violated the FSF's rules on information control and had to be corrected. More recently, Mr. Stallman told the Ghostscript developers that there were "major and pervasive problems" with the GNU Ghostscript release.
The most pervasive problem is that the GPL notices in every source
file are not the standard ones, and they refer to a web site that
describes non-free software.
The Ghostscript team did comply with the FSF's wishes, and changed the copyright notices for the 7.07 release. The other issue has to do with bug tracking systems. The Ghostscript team wants to use a single, unified bug tracker for both versions of the code. Among other things, a common bug database makes it easy to determine whether bugs reported in GNU Ghostscript have been fixed in the AFPL version; in such cases, according to Ghostscript maintainer Raph Levien, the bug fixes are always backported to the GNU version. The FSF was unwilling to agree to a single bug tracking system, however. They would like to see a real development community form around the GPL version of the code and a bug tracking system which includes the AFPL version, in their opinion, works against that goal. The Ghostscript team, unwilling to deal with the hassles of maintaining two separate bug tracking systems, decided to cease making GNU Ghostscript releases. Ghostscript users may not notice the difference, however. Given that each side continues to express great respect for the other and the two remain on friendly terms, there is a real possibility that things could yet be worked out in the future. In the mean time, as Mr. Levien told us: "...while we are discontinuing the GNU affiliation, our commitment to GPL releases of Ghostscript is as strong as ever." GNU Ghostscript will, in the future, bear a name like "GPL Ghostscript," and it will not be considered as part of the body of GNU code. But the GPL-licensed Ghostscript releases - a valuable gift of high-quality code - will continue.
D.H. Brown Linux Summary[This article was contributed by Joe 'Zonker' Brockmeier] What a difference two years makes. D.H. Brown recently released its 2003 Linux Function Review and finds that Linux has improved dramatically since 2001 — though still lagging behind commercial Unix. The executive summary of the report is available to non-subscribers, though you have to provide some contact information in exchange. In the 2001 report, D.H. Brown compared SuSE 7.2, Red Hat 7.1, Caldera OpenLinux 3.1, TurboLinux Server 6.5 and Debian GNU/Linux 2.2r3 against commercial Unix. In the 2003 review, the race is pared down to three Linux contenders: Red Hat Advanced Server 2.1 (RHAS), SuSE Linux Enterprise Server 8 (SLES) and Debian GNU/Linux 3.0. The D.H. Brown Function Review is based on "functional capabilities as of January 1, 2003" in five areas: Scalability; reliability, availability and serviceability (RAS); system management; Internet and Web application services; and directory and security services. Note that the report looks at Linux only as an enterprise system, not in terms of desktop functionality. According to the report, there are 167 items total that have been reviewed by D.H. Brown — the same criteria used by the company to analyze Unix systems. These are rated according to what is offered by each vendor, so add-on packages from third parties don't count. This puts Linux at a slight disadvantage when rating results, since some technologies may be available for Linux from vendors like IBM, HP or SGI, but not provided directly by Red Hat or SuSE. As with the 2001 report, SuSE comes out ahead of Red Hat, particularly in terms of systems management. SuSE ranked "Very Good" in systems management thanks to YaST2 and advanced support for LVM but falls behind RHAS and Debian because it is not suited for managing multiple systems from the same interface. Red Hat scores points for enabling multiple system management with its Red Hat Network. In all categories SuSE either tied with or surpassed RHAS, with Debian taking third place or tying for second place with RHAS. Linux fared poorly in the review in the RAS category, with all three distributions scoring below "Unix minimum" with a rating of "OK" -- Debian GNU/Linux was significantly behind SLES and RHAS, which were tied. In particular, Linux was dinged for not having the same kind of failure recovery features available with high-end RISC Unix systems. For example, none of the distributions reviewed included processor failure recovery or software-based support for advanced memory redundancy. Linux really excels in terms of support for networking protocols, even pulling ahead of some commercial Unix systems. It's interesting to note that a careful reading of the report shows Linux to be handily matching or pulling ahead of SCO UnixWare in many areas. SLES even pulls ahead of the strongest Unix vendor in terms of protocol support, though it's unclear how relevant some of the protocols are to real-world use. For example, both Debian and SuSE have support for IPSec over IPv6, something which isn't exactly in widespread usage. Another thing that is interesting to note is that Linux is shooting for a moving target in trying to catch up with commercial Unix. If commercial Unix systems had not evolved significantly between 2001 and 2003, Linux would have caught up or surpassed most commercial systems in D.H. Brown's ratings. The report gives bar graphs showing the 2001 in grey and the 2003 score in green. In almost every case, Linux is scoring ahead of the top Unix score from 2001. One also wonders whether commercial Unix distributions would have advanced so quickly in two years without Linux nipping at its heels. It's disappointing that D.H. Brown did not compare Linux to Windows Server 2003, particularly since they recently released a report that looks at the advancements made with Windows 2003 Server: Windows Server Platform Reaches Maturity. In that report, Windows 2003 server is mostly examined only in the context of previous Microsoft offerings. In all, the report does a good job pointing out some of the areas where Linux could still use improvement or benefit from additional features while noting that Linux has come a long way in a short time. It seems, at least to this Linux user, as a fair evaluation of Linux's place in the enterprise market. In fact, the report could serve as a useful roadmap for SuSE and Red Hat when planning new features and improvments to their enterprise offerings. It will be interesting to see how well Linux fares in two years.
Fun with SCOThis week's most amusing development in the SCO case is the announcement that Microsoft, that great purveyor of Unix products, has agreed to buy a Unix license from SCO. The amount of money involved has not been disclosed, but there are reports that Microsoft is paying between $10 and $20 million. It is surely coincidental that SCO predicted that licensing revenue would be $10 million this quarter. That is, incidentally, almost half the revenue that the company was expecting over the quarter.There has been no end of speculation regarding Microsoft's motivation for funneling that much money into SCO. It all remains just that, however: speculation. We may find out what is really going on eventually, but it will take a while. The community's attitude toward SCO and its lawsuit remains scornful (at least). It is a matter of faith that SCO's claims are without merit. That faith will probably prove to be justified, but one might wonder about what might happen if SCO turns out to have a point. LWN's standalone article on the topic (reprinted below) was criticized by some as obvious and/or naive, but the question, we believe, deserves a bit more thought than it is receiving. Even if SCO's case turns out to be no more than the hollow, baseless slander that it appears to be, the free software community remains vulnerable to injections of proprietary code.
...and if SCO is right...?As a general rule, the reaction to SCO's lawsuit against IBM has been one of derision and disbelief. It is generally assumed that SCO does not have a legal leg to stand on. SCO's tactics (ever-expanding FUD while refusing to point out the allegedly infringing code) have certainly served to reinforce that perception. But it is worth taking a moment to consider what could happen if SCO turns out to be right. Forewarned, as they say, is forearmed.The Linux kernel (which is the subject of at least some of SCO's claims) is, as a whole, clearly an independent development. The development history is sufficiently public to make that clear. But it is worth considering a few things:
It is also worth bearing in mind that there is no process for checking the pedigree of code submitted to the Linux kernel. Kernel developers (like other free software developers) have more than sufficient integrity to keep them from stealing code, and the process relies upon that fact. If a developer can convince Linus or another major kernel hacker that a patch makes sense, in it goes. Some kernel code is heavily reviewed, but there are vast amounts of code that may not have ever had a serious look by anybody other than its author. Beyond all that, of course, is the unpleasant scenario of tainted code being deliberately submitted to the kernel with the express intent of creating legal problems. The end result is that there might be code of dubious parentage in the kernel. Such code is probably small, and not in the kernel core. But the existence, say, of a purloined device driver somewhere in the kernel would not be entirely surprising. The kernel community might just wake up one morning to find that there are plagiarists in its midst. What happens then? Obviously, a code purge would be called for. Unless SCO explicitly puts any offending code under the GPL (which it might have to do to preserve its own right to distribute the kernel), any infringing code must be pulled from the kernel. That code could be excised even if SCO does release it; its presence would certainly be galling to a number of people. A big "purge and rewrite" operation could, among other things, delay the release of the 2.6 kernel. Future code contributions would receive a higher degree of scrutiny - this may well happen regardless of how the SCO suit turns out. Even if it has not yet happened here, free software projects are vulnerable to injections of tainted code. Developers may have to be prepared to explain how they came up with a particular patch. It is hard to imagine the kernel adopting a bureaucratic mechanism where develpers must sign code releases with warranties and indemnification agreements, but it could happen. Adding that kind of friction to the system can only serve to slow down development, of course. Most frightening, perhaps, is what happens if the kernel development community discovers that one or more of its members has been polluting the well with unfree code. The resultant shattering of trust could impair that community's ability to work together for a long time. In the worst case, if important developers are implicated in dishonest activities, a major fork of kernel development is not out of the question. A successful suit would also make waves in the business world, of course. In the worst case, companies could move away from free software out of fear of lawsuits; this scenario seems unlikely, however. But companies could hold back on code releases or contributions to free software projects out of fear of being accused of illegal copying. A general chilling effect which slows adoption of Linux is a real possibility. Happily, the most likely outcome is that SCO and its lawsuit go down in flames. They have picked on, perhaps, the most transparently developed piece of code in history by way of a huge company with seriously scary lawyers, deep pockets, and the will to defend itself. But the worst-case scenario is worth keeping mind for this simple reason: even if the Linux community doesn't get burned this time, it could happen in the future. We need to pay a great deal of attention to where our code comes from.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|
||||||||||||