The GNU Operating System and the Free Software Movement
by Richard Stallman
(continued)
The first instance of this
problem was the Motif toolkit, back in the 80s. Although there were as
yet no free operating systems, it was clear what problem Motif would
cause for them later on. The GNU Project responded in two ways: by
asking individual free software projects to support the free X toolkit
widgets as well as Motif, and by asking for someone to write a free
replacement for Motif. The job took many years; LessTif, developed by
the Hungry Programmers, became powerful enough to support most Motif
applications only in 1997.
Around
the same time, another non-free GUI toolkit library began to gain in
popularity. This was Qt, from Troll Technologies. Ultimately Qt was
used in a substantial collection of free software, the desktop KDE.
Free GNU/Linux systems were unable to use
KDE, because we could not use the library. However, some commercial
distributors of GNU/Linux systems who were not strict about sticking
with free software added KDE to their systems--producing a system with
more capabilities, but less freedom. The KDE group was actively
encouraging more programmers to use Qt, and millions of new "Linux
users" had never been exposed to the idea that there was a problem in
this. The situation appeared grim.
The
free software community responded to the problem in two ways: GNOME and
Harmony.
GNOME, the GNU Network
Object Model Environment, is GNU's desktop project. Started in 1997 by
Miguel de Icaza, and developed with the support of Red Hat Software,
GNOME set out to provide similar desktop facilities, but using free
software exclusively. It has technical advantages as well, such as
supporting a variety of languages, not just C++. But its main purpose
was freedom: not to require the use of any non-free software.
Harmony is a compatible replacement
library, designed to make it possible to run KDE software without using
Qt.
In November 1998, the
developers of Qt announced a change of license which, when carried out,
should make Qt free software. There is no way to be sure, but I think
that this was partly due to the community's firm response to the
problem that Qt posed when it was non-free. (The new license is
inconvenient and inequitable, so it remains desirable to avoid using
Qt.)
How will we respond to the
next tempting non-free library? Will the whole community understand the
need to stay out of the trap? Or will many of us give up freedom for
convenience, and produce a major problem? Our future depends on our
philosophy.
Software Patents
The
worst threat we face comes from software patents, which can put
algorithms and features off-limits to free software for up to twenty
years. The LZW compression algorithm patents were applied for in 1983,
and we still cannot release free software to produce proper compressed
GIFs. In 1998, a free program to produce MP3 compressed audio was
removed from distribution under threat of a patent suit.
There are ways to cope with patents: we can
search for evidence that a patent is invalid, and we can look for
alternative ways to do a job. But each of these methods works only
sometimes; when both fail, a patent may force all free software to lack
some feature that users want. What will we do what this happens?
Those of us who value free software for
freedom's sake will stay with free software anyway. We will manage to
get work done without the patented features. But those who value free
software because they expect it to be technically superior are likely
to call it a failure when a patent holds it back. Thus, while it is
useful to talk about the practical effectiveness of the "cathedral"
model of development, and the reliability and power of some free
software, we must not stop there. We must talk about freedom and
principle.
Free
Documentation
The
biggest deficiency in our free operating systems is not in the
software--it is the lack of good free manuals that we can include in
our systems. Documentation is an essential part of any software
package; when an important free software package does not come with a
good free manual, that is a major gap. We have many such gaps today.
Free documentation, like free software, is
a matter of freedom, not price. The criterion for a free manual is
pretty much the same as for free software: it is a matter of giving all
users certain freedoms. Redistribution (including commercial sale) must
be permitted, online and on paper, so that the manual can accompany
every copy of the program.
Permission
for modification is crucial too. As a general rule, I don't believe
that it is essential for people to have permission to modify all sorts
of articles and books. For example, I don't think you or I are obliged
to give permission to modify articles like this one, which describe our
actions and our views.
But there is a
particular
reason why the freedom to modify is crucial for documentation for free
software. When people exercise their right to modify the software, and
add or change its features, if they are conscientious they will change
the manual too--so they can provide accurate and usable documentation
with the modified program. A manual which does not allow programmers to
be conscientious and finish the job does not fill our community's needs.
Some kinds of limits on how modifications
are done pose no problem. For example, requirements to preserve the
original author's copyright notice, the distribution terms, or the list
of authors, are OK. It is also no problem to require modified versions
to include notice that they were modified, even to have entire sections
that may not be deleted or changed, as long as these sections deal with
non-technical topics. These kinds of restrictions are not a problem
because they don't stop the conscientious programmer from adapting the
manual to fit the modified program. In other words, they don't block
the free software community from making full use of the manual.