[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mico-devel
Subject:    Re: [clip@cc64317-a.hwrd1.md.home.com: Re: MICO: MICO 0.9b5]
From:       Richard Stallman <rms () santafe ! edu>
Date:       1997-11-05 17:14:51
[Download RAW message or body]

There is no fundamental difference between static and dynamic linking,
as regards the GNU GPL or the GNU LGPL.  Our position is that if you
link a GNU program into a combined program, no matter what kind of
linking you use, you have to obey the terms of the GNU program in
distributing the combination.

Thus, if you link with GNU libc, the result is always a derivative
work of GNU libc.  There is just one exception: if your program does
not actually use any of the functions in the library, then the linker
might look at the library but not actually use it.  Then the output of
the linker is not a derivative work of GNU libc.

But Thompson is right as a practical matter.  If you use dynamic
linking, on most systems the dynamically linked executable itself
satisfies the requirement in section 6 of the LGPL to give the user a
way to link with a modified library.  So you do not need to provide .o
files in addition.  You can validly say that the executable serves as
the .o file too.

The LGPL requires distributing the library sources with the
executable.  In the case of dynamic linking, this requirement does not
serve a practical purpose.  The user, in order to run the executable,
has to get the library from somewhere else; he can get the library
source code from the same place.  So we are going to change this in
the next version of the LGPL--it will not require distribution of
library source with such dynamically linked executables.

Because we've decided to drop the requirement in this case, we will
give everyone and anyone permission to disregard it now, in this case
only.  So you need not distribute the GNU libc source along with
dynamically linked executables that use GNU libc.

[prev in list] [next in list] [prev in thread] [next in thread]