When the General Public License should be preferred
to the Library General Public License.
by Richard Stallman
The GNU Project has two principal licenses to use for libraries.
One is the GNU Library GPL; the other is the ordinary GNU GPL. The
choice of license makes a big difference: using the Library GPL
permits use of the library in proprietary programs; using the
ordinary GPL for a library makes it available only for free
programs.
Which license is best for a given library is a matter of
strategy, and it depends on the details of the situation. At
present, most GNU libraries are covered by the Library GPL, and
that means we are using only one of these two strategies,
neglecting the other. So we are now seeking more libraries to
release *under the ordinary GPL*.
Proprietary software developers have the advantage of money;
free software developers need to make advantages for each other.
Using the ordinary GPL for a library gives free software developers
an advantage over proprietary developers: a library that they can
use, while proprietary developers cannot use it.
Using the ordinary GPL is not advantageous for every library.
There are reasons that can make it better to use the Library GPL in
certain cases. The most common case is when a free library’s
features are readily available for proprietary software through
other alternative libraries. In that case, the library cannot give
free software any particular advantage, so it is better to use the
Library GPL for that library.
This is why we used the Library GPL for the GNU C library. After
all, there are plenty of other C libraries; using the GPL for ours
would have driven proprietary software developers to use
another–no problem for them, only for us.
However, when a library provides a significant unique
capability, like GNU Readline, that’s a horse of a different color.
The Readline library implements input editing and history for
interactive programs, and that’s a facility not generally available
elsewhere. Releasing it under the GPL and limiting its use to free
programs gives our community a real boost. At least one application
program is free software today specifically because that was
necessary for using Readline.
If we amass a collection of powerful GPL-covered libraries that
have no parallel available to proprietary software, they will
provide a range of useful modules to serve as building blocks in
new free programs. This will be a significant advantage for further
free software development, and some projects will decide to make
software free in order to use these libraries. University projects
can easily be influenced; nowadays, as companies begin to consider
making software free, even some commercial projects can be
influenced in this way.
Proprietary software developers, seeking to deny the free
competition an important advantage, will try to convince authors
not to contribute libraries to the GPL-covered collection. For
example, they may appeal to the ego, promising “more users for this
library” if we let them use the code in proprietary software
products. Popularity is tempting, and it is easy for a library
developer to rationalize the idea that boosting the popularity of
that one library is what the community needs above all.
But we should not listen to these temptations, because we can
achieve much more if we stand together. We free software developers
should support one another. By releasing libraries that are limited
to free software only, we can help each other’s free software
packages outdo the proprietary alternatives. The whole free
software movement will have more popularity, because free software
as a whole will stack up better against the competition.
Since the name “Library GPL” conveys the wrong idea about this
question, we are planning to change the name to “Lesser GPL.”
Actually implementing the name change may take some time, but you
don’t have to wait–you can release GPL-covered libraries now.