Renaming the Library GPL

[Richard Stallman <rms@gnu.org>]

The name "Library GPL" suggests to many programmers that "the LGPL is
the right thing to use for any libraries."  But that's contrary to
what the GNU Project says.  For some libraries, it is better to use
the GPL.

In effect, this means that the name is working against us.  Maybe it
would be easier to explain that some libraries should not use the
LGPL, if we used a different name instead of "Library GPL."

Any suggestions for another name?

Here's a draft of an article to explain why we want to find some
libraries to place under the GPL.  Please don't save or redistribute
this version; please wait for the final version.


   Why you shouldn't use the Library GPL for your next library

The GNU Project has two principal licenses used for libraries.  One is
the GNU Library GPL; the other is the ordinary GNU GPL.  Most GNU
libraries are covered by the Library GPL, but that needs to change.
We are seeking more libraries to release *under the ordinary GPL.*

The choice of license makes a big difference.  When a library is
released under the LGPL, it can be used in proprietary programs.  When
a library is released under the GPL, then its use is limited to free
software.  Which license is best for a given library is a matter of
strategy, and which strategy is best depends on the details of the
situation.

When we use the ordinary GPL for a library, the purpose is it to give
free software developers an advantage over proprietary developers.
Proprietary software developers have the advantage of money; free
software developers need to make advantages for each other.

Using the GPL for a library is not always advantageous.  If a free
library's features are already available conveniently for proprietary
software through other libraries (presumably non-free ones), then it
will not give free software an advantage over proprietary software.
In such as case, it is better to use the LGPL for that library.

This is why we did not put the GNU C library under the GPL.  After
all, there are plenty of other C libraries; using the GPL for ours
would have driven proprietary software developers to use another.

However, when a library provides a unique capability, like GNU
Readline, the situation is different.  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 large collection of 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 so in
order to use these libraries.  University projects can easily be
influenced; nowadays, as companies begin to consider making software
free, even some company projects can be influenced in this way.

Proprietary software developers will try to convince us not to
contribute our libraries to the GPL-covered collection.  If they
succeed, their free competition will lose an advantage.  For example,
they may appeal to the ego, promising "more users for this package" if
we let them use it in proprietary software products.  Popularity is
tempting to the ego, 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 most.

But if we resist the temptation, and stand together, we can achieve so
much more.  If we link our egos with the spread of free software and
the freedom it brings, rather than with the success of specific
programs, we can make free software more powerful, and that will boost
the success of free software as nothing else could.