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

Re: LGPL module linked with a GPL lib



On 7/27/05, Jeff Licquia <licquia@debian.org> wrote:
> Does such compilation in itself give Debian any rights on its own, or is
> the compilation seen as non-copyrightable?

The collective work (special case of compilation) that is a Debian CD
is copyrightable.  The copyright covers the creative expression that
goes into "selecting and arranging" its contents.

> I would agree that hello.c is unencumbered with regards to its
> copyright.  But the hello executable created through compilation
> (statically, to be clear) certainly has some kind of copyright
> obligation with regard to the libraries contained within it, doesn't it?
> Perhaps "derived work" is not the right term, but I find it thoroughly
> incredible that the copyright of the library is irrelevant with regards
> to the executable.

The statically compiled executable contains a copy of (non-trivial
parts of) the C library, and of course copying and distributing those
bits requires license from the copyright holder.

> And, if so, then by the terms of the GPL, the whole of the executable
> must be itself covered by the terms of the GPL if any component part is.

Nope.  The GPL is written with passim references to "works based on
the Program", which is defined in Section 0 in terms of the copyright
law meaning of "derivative work".  I'm not going to rehash the whole
detailed parsing of the GPL language here (see the d-l archives or ask
for a copy of my write-up), but to the extent that the drafters
intended to forbid the (uncopyrightable) combination of GPL library X
and library-using program Y, they failed to do so.  (IANAL, TINLA.)

> Well, yes, in the case of glibc.  In fact, one of the possible solutions
> to the KDE/Qt problem involved reimplementing Qt under the GPL, at which
> point the proprietary Qt would not be a prerequisite for KDE.

The existence of an alternate implementation of a given published
library interface certainly disposes of any question of whether a
program is a "derivative work" of either implementation; but this is
by no means necessary for the program to be non-infringing.

> So does this mean that libraries cannot impose restrictions on the
> programs that use them?  I think far more groups than the free software
> community rely on this being the case; see the license agreement on any
> Microsoft SDK for an example.

Whether or not that agreement purports to bind a developer in ways
that copyright law does not, there are limits to what terms a court
will permit in a contract of adhesion.  The license terms might create
a cause of action for breach of contract, but that's a very different
animal from copyright infringement.  If you know of a case more
applicable than Lexmark v. Static Control and Specht v. Netscape, I'd
be very interested to hear about it.

> It would have been good for someone to have made those arguments at the
> time.  Why they did not do so is a mystery.  (Of course, those arguments
> could have been made, and missed by me, in which case cites for those
> arguments would be worthwhile.  Obviously, the cites were missed by far
> more people than me.)

How many participants in the KDE/Qt brouhaha actually cited relevant
case law?  In any case, there's a perfectly good argument that for
Debian to piss off the FSF is not a good idea whether or not they have
a legal leg to stand on.  I personally would be ashamed to lend my
good name to their conduct in recent years, but YMMV.

Cheers,
- Michael



Reply to: