Results of "downloading compressed program images" request

Richard Stallman rms@santafe.edu
Sat Jan 10 17:46:00 GMT 1998


    Since this is such an important question,

Unfortunately, I am not sure which question is the one that you find
so important.  You quoted a message which talks about a whole range of
different issues.  I will respond to a few of them.

	Joel> I dismissed kermit because I remembered that it could not be
	Joel> included in Linux distributions because of the licensing.

Kermit is not free software; it is far too restricted.  Thus, it
cannot be included in any free operating system.  For the definition
of free software, see http://www.gnu.org/philosophy/categories.html .

    Joel> Someone else may be able to give a better explanation but
    Joel> let's take the Every discussion I have ever seen of the LGPL
    Joel> on-line says that if you use an LGPL'ed library in your
    Joel> application, then you must provide the proprietary part of
    Joel> your application in a form such that it can be relinked
    Joel> against the LGPL'ed code.

Yes, this is what the LGPL requires.  The LGPL was designed
specifically to require this.

The danger of a spurious liability lawsuit is a part of life in our
society, and it makes sense to be concerned about it.  It seems to me
that Joel is disproprortionately worried about one scenario out of
many that could lead to this result--and not a particularly likely
one.  Using an LGPL-covered library makes no real difference to the
situation, because it is always possible for a customer to tinker with
the box he bought, and break it.

People usually deal with this issue with warning labels, such as,
"Don't mess with this, that voids the warranty and it might even be
dangerous."

	Joel> LGPL for example.  I have assumed for so long that the GPL
	Joel> is inappropriate for libraries and link-in code, that I have
	Joel> forgotten why it is not appropriate.

We use the ordinary GPL for some of our libraries.  In fact, that is
our default choice, for a library just as for any other program.

The GNU project's goal is to encourage and facilitate the development
of free software.  We want to encourage people to use free software,
even when they are proprietary software--but that does not mean we
think that developing proprietary software is a good thing, or that we
aim in general to help people do that.

Using the GPL for a library means it is available only for free
programs.  That way, we help the development of free software but do
not help the development of proprietary software.  In many cases that
is exactly what we want to achieve.

We make an exception, and use the LGPL or the libgcc.a distribution
terms, when there is a specific reason to do that.  The most common
reason is that a particular library is the key to using a much larger
body of free software, instead of some proprietary alternative.

For example, libgcc.a is a tiny part of GCC; if libgcc.a were covered
by the GPL, it would be blocking proprietary developers from using
GCC.  We judged it was better for free software development to have
more users for GCC, and thus more development of GCC.

Likewise, GNU libc is a small part of the GNU system, or of the
Linux-based variants of the GNU system that people usually call
"Linux" (see http://www.gnu.org/gnu/linux-and-gnu.html ).  If GNU libc
were covered by the GPL, that would make it impossible to compile a
proprietary program for any these systems.  We designed the LGPL for
GNU libc specifically so that this would not be impossible.

The existence of equivalent alternatives is also a crucial factor.
There are many proprietary compilers, and many proprietary operating
systems that have C libraries which, while not free software, may be
linked into compiled programs.  So if we did not allow using libgcc.a
and GNU libc in this way, that would not hamper the development of
proprietary programs; it would only give the developers a reason to
pick a different compiler, or a different operating system.
Clearly it is better for the progress of free software to allow
use of these particular libraries in proprietary software.

But that is not true for for all libraries.  If a free library
implements some useful special feature, often it is better (for the
development of free software) to distribute it under the ordinary GPL
so that it gives free software development efforts an advantage
over proprietary development efforts.




More information about the crossgcc mailing list