[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: linking to GPL'd libraries WAS Re: One unclear point in the Vim license



On Thu, Jan 03, 2002 at 06:45:50PM -0800, Thomas Bushnell, BSG wrote:
> lloyder@canada.com writes:
> 
> > I do not really understand why, I guess accepting it 
> > in the definition of derivative work is the basis, but 
> > I cannot help, but wonder as I have not seen legal 
> > challanges that support this.  
> 
> It's a perfectly normal case of a derivative work.  When you link
> program A with program B, you are creating a derivative work, A+B.
> You can only distribute that work if the licenses of A and B permit
> it.  

Don't dismiss this as completely obvious. It's not uncontroversial.

For example, the kernel is GPLed but will load and run programs
with incompatible licenses. Those programs make syscalls to
the kernel to perform system work; how is this permitted?
It is so different from an incompatibly-licensed program linking
to a GPLed library?

The ldso license is interesting (/usr/doc/ldso/copyright, possibly
only on potato or earlier systems). The commentary implies that
ld.so deliberately uses the BSD license because the GPL is too
strict. It also has the following paragraph:

 * It is the general understanding of the above contributors that a
 * program executable linked to a library containing code that falls
 * under the GPL or GLPL style of license is not subject to the terms of
 * the GPL or GLPL license if the program executable(s) that are supplied
 * are linked to a shared library form of the GPL or GLPL library, and as
 * long as the form of the shared library is such that it is possible for
 * the end user to modify and rebuild the library and use it in
 * conjunction with the program executable.

This seems to suggest that a program linking to a GPLed library
does not have to be GPLed itself. Interesting that the ld.so
license avoids being GPLed anyway to avoid this exact problem.

Tcl can dynamically load shared libraries so that scripts can
use library functions. tcl itself appears to have a BSD-type
license. What if a tcl script, using a non-GPL compatible
license, causes tcl to load a GPL library (eg libreadline)?
The script is being interpreted by the Tcl shell, it's not 
capable of being linked to anything itself.

libterm-readline-gnu-perl is a package of a Perl module to
use libreadline from Perl progams. According to the license,
it's available under the same terms as Perl ie your choice
of GPL or the Artistic license. But since any combination
of GPL program + a GPL-compatibly-licensed program must
by GPLed, you really can't use it under the Artistic license
at all ie the GPL always dominates. So non-GPL programs
apparently can't use that library.

Getting off-topic a bit, there's an interesting clause in the 
license for libio, in /usr/doc/libc6/copyright (on potato anyway).

   As a special exception, if you link this library with files
   compiled with a GNU compiler to produce an executable, this does
   not cause the resulting executable to be covered by the GNU General
   Public License.  This exception does not however invalidate any
   other reasons why the executable file might be covered by the GNU
   General Public License.

Why does the license require you to use a GNU compiler? Bizarre.

Just some thoughts,

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



Reply to: