Re: LGPL module linked with a GPL lib
On Wed, 2005-07-27 at 14:42 -0300, Humberto Massa Guimarães wrote:
> ** Jeff Licquia ::
>
> > On Wed, 2005-07-27 at 10:05 -0300, Humberto Massa Guimarães wrote:
> > > First of all, Debian GNU/Linux is *NOT* a derivative work of
> > > OpenSSL, GStreamer, nor any of its plugins. A derivative work
> > > has a definition in the statute (in the US case, 17USC).
> >
> > Hmm. I suppose this is part and parcel of the move in the USA to
> > copyright "compilations" or "databases"? I suppose I had never
> > thought of it that way.
>
> Derivative works are those that result of a (non-automatable,
> intelligent, intellectually novel) _transformation_ of a work.
>
> Compilation works are those that are composed of other works, in
> which the intellectual novelty resides in the selection and
> arrangement of contents.
>
> Debian, as a whole, is a compilation works on its packages.
Does such compilation in itself give Debian any rights on its own, or is
the compilation seen as non-copyrightable?
> Static linking can *not* create a derived work, because it is an
> automatic process. Poster case: is hello, generated from hello.c:
>
> #include <stdio.h>
> int main(int argc, char** argv) {
> printf("Hello\n");
> return 0;
> }
>
> a derivative work of something it's (statically) linked to?
> The answer is no, because derivative works, as intelligent
> transformations, can only appear when you *create* a work.
Hmm. I think this may be the source of a misunderstanding, for which I
will take the credit.
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.
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.
> > much as how a motion picture film contains its soundtrack. To me,
> > splitting the soundtrack off a movie, and creating a machine to
> > recombine them afterwards, does not cease to make the movie an
> > infringement on the soundtrack's copyright, which is equivalent to
> > the dynamic linking process. Is such a scheme really effective
> > from a legal standpoint in avoiding copyright liability?
>
> No, because you can't change the soundtrack of a film without
> changing the final result. OTOH, you can substitute (almost always)
> glibc for dietlibc in a program and have the same result. Such
> program does not *depend* on glibc for being what it is, and most
> certainly is *not* the result of a transformation applied over
> glibc.
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.
> Anyway, the person who "recombines" the "film" and "track", in the
> case of dynamic linking, is the *USER*, in the process of using the
> program, and copyrights protection do not apply at that moment, as
> per 17USC.
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.
> I think, in hindsight, that Debian (in the Qt/KDE case) fell for
> arguments that are not sound, nor based on the law, even if they
> were presented as such.
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.)
Reply to: