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

Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps

On Tue, May 27, 2003 at 05:11:21PM -0400, Nathanael Nerode wrote:
> Steve Langasek wrote:
> >This assumes that the FSF's interpretation depends on the claim that
> >dynamic linking creates a derived work.  While varies parties have
> >claimed this at one point or another, I have argued that the 
> >dynamically linked work is under the purview of the GPL by virtue of 
> >the license terms alone, *if* you are distributing the GPL library in 
> >question, which is always the case for Debian.

> Well, this statement is simply wrong, and I'll devote the rest of this 
> email to explaining why.

> If the dynamic linking does *not* create a derived work, you are 
> distributing two works:
> A. The new program which links to the GPL'ed library
> B. The GPL'ed library which is linked to

> Not one work.  A "mere aggregaton" of two works.

It is not "mere aggregation", for the same reason that a bug in a
library that makes it unusable by applications is a grave, not a
critical, bug: one piece of software is not "unrelated" to another if
the former depends on the latter.  This may or may not make the one work
a derived work of the other, but it does mean we're dealing with
something more than mere aggregation, because the application references
the library at several levels: in the ELF header, in the form of
undefined symbol references, and in the Depends: line of the package

If removal of foo makes bar unusable, the combination of the two cannot
be considered mere aggregation.

> Under the GPL, the library B is distributable under section 3, using 
> either the written offer (b) or the distribution of source code (a), and 
> the source code for the library can be distributed under section 1.

> There is no restriction on the distribution of B with other works.  In 
> fact, there's an explicit statement that there's no such restriction 
> (Section 2, final paragraph).  So the GPL imposes no restriction on the 
> distribution of A and B together.  Note carefully that *all* the 
> restrictions in the GPL (except for the very mild section 1 
> restrictions) are stated in terms of "incorporating parts of the 
> Program", "as part of a whole which is a work based on the Program", 
> etc., all of which are terms refering to the creation of a derived work.

Not all: the terms of section 3 talk about covered source code in very
broad terms of "all modules [the work] contains".  Can you expand on
your understanding of this phrase?

One possibility that I had not thoroughly considered is that in the case
of an application, "all modules" includes any libraries referenced by
the application; but that in the case of a library, "all modules" does
not include any applications which use that library, because the
*library* which is GPLed does not encode any information pointing to the
applications.  I'm not sure I like this asymmetry (I'm pretty sure it
isn't the FSF's intention), but I'm also not sure I can make a
convincing argument against this interpretation.  The best I can muster
is that it conflicts with the FSF's public interpretation of the GPL,
which *could* be seen as significant in a court case.

> Furthermore, it is not within the rights of the copyright holder to 
> decide unilaterally what constitutes a derived work.  I believe that is 
> considered to be a matter of facts, to be established by court cases and 
> precedents.


> Respecting the FSF's *opinion* that dynamic linking creates a derived 
> work is perfectly sensible and wise.  (Hey, they could be legally 
> correct!)  Claiming that the GPL somehow imposes itself on works linked 
> with even if linking *doesn't* legally create a derived work is just 
> plain wrong.

Noted.  I've come to believe that the basis for claiming the application
is a derived work in these cases is very weak, but it still seems
prudent to treat dynamically-linked works as covered by the GPL's source
code requirements for the time being.

Steve Langasek
postmodern programmer

Attachment: pgphB4oZVaQ_6.pgp
Description: PGP signature

Reply to: