Technology and Trends
 USENET Archives
From: (Richard Stallman)
Newsgroups: gnu.misc.discuss
Subject: Questions about the GPL
Date: 13 Jul 1993 00:35:15 -0400
Organization: GNUs Not Usenet
Lines: 180
Distribution: gnu
Message-ID: <>

[This message did not appear sooner because I wanted to think
carefully and get feedback from friends before posting it.]

The purpose of the GPL is to make sure that changes and add-ons to GNU
software are free--by not allowing non-free changes or add-ons.

There are three questions to ask about any particular case of this:

* What requirements are ethically allowable?
* What requirements are advantageous for us to make?
* What requirements are we able to make?

The first question is, in essence, whether people sometimes have
a basic right to write non-free software, so that it would be
wrong to stop them.

For the GNU project, the answer is simple: making software non-free is
wrong in general, whether it incorporates GNU software or not.  So any
requirement that "You can't make a certain program non-free" cannot be
ethically objectionable.

(I know that most of society doesn't share these principles.  But
these are the principles that the GNU project is based on, and always
has been; the project is not going to abandon its principles, nor
adopt the other principles merely because they have many adherents.)

(The GPL doesn't try to say anything about development of non-free
software in general.  It only addresses the question how GNU software
can be distributed and incorporated into new programs.  The reason for
this is partly that we want to cooperate with everyone who wants to
work on the specific practical work of the project--building the GNU
system--including people who don't share the motivation on which the
GNU project was founded.)

The question of what requirements are advantageous is a complex one.
Sometimes we might gain more free software development by permitting a
certain kind of use of GNU software in proprietary software.

Some cases are very clear.  For instance, we would never try to say,
"You can't run any proprietary program on any GPL-covered kernel"
(regardless of whether this were legally possible), because it is
clear that this would discourage the use of all such kernels, and
would yield next to no benefit (benefit meaning more free software).

To facilitate/prepare for running proprietary programs on a GNU
kernel, we put the system call stubs into GNU libc, under the Library

Likewise, it would be disadvantageous to try to stop people from using
a GNU utility such as awk or grep from a proprietary shell script.

Sometimes it isn't clear what choice will work out best for
encouraging more free software.  We originally distributed libg++
under the ordinary GPL, but moved it to the Library GPL to see if that
would encourage more development of libg++ and other GNU software.
(So far this particular change does not seem to have had much effect
of any kind; at least, when we asked people to tell us about its
effects, we heard about hardly any instances.  If you know of any such
instances, please send e-mail about them to

As to what requirements we can make, copyright lets us restrict
anything that is done by combining GNU code with some other software
to make one larger combined work.  What precisely this means is a
difficult question: when do we have two separate programs, and when
do we have a single program made up of two parts?

It is impossible to be sure what the answer is.  Different courts
might rule differently.  What the FSF can say is when it will try to
claim two parts make one combined program.

I believe that the proper question to ask is, "Is it reasonable to say
that these two parts have been combined into one program, or is it
reasonable to say they are separate and independent programs."  This
depends on what the parts are and how they relate to each other, not
on how they are packaged.

Some people have asked the FSF to state a simple, mechanical
criterion, based on what sort of commands are used in building the
program or programs involved.  It's clear why such a rule would be
convenient in some ways.  But a mechanical rule has to be
superficial--it closes its eyes to what is really important.  The fact
that such rules tend to be easy to sneak around is an indication that
they aren't good rules.

Some people would like to see a line drawn which is clearly correct
and not at all arbitrary.  Unfortunately, that is an unrealistic
demand; it can't be satisfied, not in this question, and not in many
(perhaps most) legal questions.  Gray areas always arise.  They are
much worse in some other instances than it is here; consider the gray
area between drunk and sober, and the arbitrary numerical criterion
that was set up to separate them.  The only way to avoid this gray
area is to cut the guts out of the GPL, and that would not be an
improvement in terms of the GNU project's goals.

While it's impossible to state a general rule, I can address some
cases that I think will take care of almost all practical situations.

* Normally, when two different source files contain calls to each
other, combined by linking, we say they are part of a single program.
So when people make a collection of files intended to be linked
together, and some of these are GNU software, we say this means the
collection is one program and is covered by the GPL.

This is true just as much for libraries, even for libc, as it is for
tools such as the C compiler--whether a given set of object files are
packaged up into an archive is not a significant factor.  The reason
that you can link any program with GNU libc, and even distribute a
linked executable if you wish, is that the copying conditions for GNU
libc explicitly permit this (with certain conditions).

* Use of a shared library is intermediate in its significance between
distributing an executable and letting the user do the link.

* A program written in a language is normally separate from an
interpreter for that language or a compiler for that language.

* A separate program can run a GNU utility and communicate data with
it through the interface we implemented.  (If you make extensions that
are at all reasonable to call clean and general-purpose, the same
would be true for the extended utility.  On the other hand, if you
extend it in an arcane way that makes sense only in terms of the
internals of some specific other program, we might claim that makes
one combined program.)

Normally, people speak of separate programs that interact by fork and
exec, and by exchanging data in a common format.  For example, uucp
consists of many separate programs that interact in this way, but
there's general agreement that these are separate programs.

* An application program running on the GNU kernel we release will be
a separate program from the GNU kernel.  (Likewise, if you make kernel
extensions that are at all reasonable to call clean and

* A compatible replacement for a GNU program is separate from the
program it replaces.  (In fact, "separate" is an understatement; these
two programs are less likely to be combined than any two programs
picked at random, because either one makes the other unnecessary.)

The claim that a compatible program infringes the copyright on the
original program is what's generally known as "interface copyright".
The FSF does not do this; we do not legally object to making a
compatible replacement for a GNU program (though we might well think
it's a shame or a mistake).

* If your work is not a combined work including GNU software, but
somebody else goes ahead and combines them, that is not your
responsibility.  For example, if you make a program that expects to be
linked with termcap--any termcap implementation--then there's no way
to claim you have incorporated GNU termcap in particular.  (There are
non-GNU termcap implementations that are clearly serious.)  If someone
else decides to link the program with GNU termcap, that does produce a
combined work, but it isn't your responsibility.

These positions are not new; the FSF has not changed its position on
these questions for several years.  The FSF may change its position to
permit additional modes of use whenever we see an advantage for the
free software community in doing so.  But we will not make a change in
the other direction unless loopholes appear and we change the GPL to
close them.  (If a new version of the GPL has additional requirements,
they will naturally apply only to new software versions released
subsequently; we can't make them retroactive.)

However, there are some areas that are gray, where we won't take a
position until we have to.  If you are actually planning a project and
you are not sure what the GPL says about it, please contact the FSF
via and ask.

We can't undertake to answer all hypothetical questions.  Thinking
about these questions is often a lot of work, sometimes too much work
to do just for the sake of curiosity.  Besides, the answer to a
hypothetical question often must be "It depends on other details," or
"We have to ask our lawyer."  (And that costs money, which we might
not decide to spend for hypothetical questions.)

If you simply try to keep free and non-free software at arms length,
not only in terms of how you package them but also in terms of how
they interact, then you will probably not have a problem.