The 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
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
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.
Ghostscript team, unwilling to deal with the hassles of maintaining two
separate bug tracking systems, decided to cease making GNU Ghostscript
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 -
Comments (11 posted)
[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
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.
Comments (1 posted)
This 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
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.
Comments (5 posted)
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,
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:
- The source to various proprietary Unix systems tends to be more
widespread than many people think. Numerous companies have source
licenses, and, despite careful procedures, copies can leak out.
- There is considerable reputation value in making contributions
to the Linux kernel. Perhaps more than any other free software
project, the kernel is surrounded by developers who would like to get
their names into the changelog, even if that means submitting spelling
- Some people are lazy or unable to program at the level required
for kernel development (or both).
Some of those people may have access to some flavor or other of
proprietary Unix. And some of them might just be sufficiently
dishonest to present somebody else's code as their own.
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
Beyond all that, of course, is the unpleasant scenario of tainted code being
deliberately submitted to the kernel with the express intent of creating
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
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.
Comments (44 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: The networking hash vulnerability; new problems with cdrecord, gnupg, lv, sendmail
- Kernel: "Must-fix" list discussion; Compatibility and configurability; A new firmware interface
- Distributions: Caldera/SCO Linux: Obituary, plus Linux Audio Workstation (LAW), Bonzai Linux, DietLinux, Freepia and ThinStation
- Development: GCC 3.3 released, New versions of: Alsa, JACK, MySQL, SpamAssassin,
GNU Ghostscript, CMF, Zope Group Calendar, PABlog, Mozilla Firebird,
Formulator, MusE, Tkeca, Epiphany, KDE, GIMP, Samba, Gaim, PHP.
- Press: SCO, UNIX, and Microsoft issues, Playing the Linux Game,
Congress calls to arms against pirates, NASA selects the Mozilla MPL.
- Announcements: Linux Function Review, IBM Linux PCs, Red Carpet 2.0, LSB architecture
specs, Euro Zope Tour, Python conference reports.
- Letters: SCO; Defining "access".