Re: LGPL module linked with a GPL lib
** 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.
> > Yes. There is no derivative work status on the program that uses
> > a library. I and M.K.Edwards, in the last 3 months or so, have
> > brought a lot of arguments and case law to this extent to d-l,
> > and my own and humble conclusion is that: especially in the case
> > of dynamic linking (and more so in the case of dlopen()ing), the
> > distribution by debian of both a program A and a linking-to-A
> > B.so is subject only to the *separate* compliance to the terms
> > of both A and B.so, independently of any terms applied only to
> > derivative works of A or of B.so.
>
> Mr. Edwards, elsewhere, refers to the GFingerPoken thread, which I
> had followed. There may be other threads I did not follow, and I
> will look for them.
>
> I confess to not seeing how the manner of linking makes a
> difference from a copyright point of view. Static linking creates
> a derived work, in that the resulting binary contains the library,
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.
If I translate "Helter Skelter" to Portuguese -- not by babelfish --
then I am doing a derivative work. When I write the above hello.c,
not.
> 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.
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.
> > I do not have enough time right now to answer properly (ie, with
> > the links to the discussions, examples, and caselaw that I,
> > amongst others, presented here on d-l), but I trust that you can
> > find them if you are interested.
> >
> > As I said two paragraphs above, I consider that I presented all
> > my arguments in this direction, and (to me, at least) I consider
> > my point proven.
>
> That's great. Other people with legal expertese (the FSF legal
> team, for example) have done the same, and have come to entirely
> different conclusions. Others with legal expertese commented, as
> I recall, on the KDE/Qt controversy back in the day, too, and I
> don't recall seeing any argument against it that wasn't based on
> emotion or wishful thinking ("the KDE and Qt people are good
> people, they wouldn't sue anyone").
>
> I am not a lawyer, and thus am forced to accept arguments from
> authority (and regurgitate them when necessary, as was the case in
> this thread). It seems clear in my interaction with you that my
> understanding of the copyright process is hopelessly inadequate
> for evaluating these arguments; there always seems to be some
> exception to the general rule that people can throw at any
> position people can take.
>
> And, it seems to me, that in the authority face-off, you lose.
> I've never heard of you outside this forum. Mr. Edwards has
> already admitted to a lack of formal legal training. The GPL, on
> the other hand, has a law professor and a team of lawyers behind
> it, as do other groups promoting free software and open source,
> and their efforts at enforcing their view of the world have been
> quite successful to date. Are you seriously telling me that these
> people don't know what they're talking about regarding the law,
> and that you do? On what basis can you make such an extraordinary
> claim?
>
> Now, the standard answer when confronted with such a quandary is
> "go hire your own lawyer". Which is a great idea, if you have
> hundreds of dollars to throw away. If I wanted to throw money at
> legal crap, I would have stayed in the Windows world.
>
> So, you will forgive me, I hope, for continued skepticism. You
> may be right, and the entire free software community may be wrong,
> about the way things work. But I'm betting not.
Well, your argument makes a lot of sense, for I am just an
ex-paralegal, and you are completely forgiven.
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.
In the case of Debian, the project *does* have the dollars needed to
consult a copyrights lawyer that does not have a conflict of
interests, and to obtain from him/her a detailed legal analysis. I
think it's time to do that, because of all the different
interactions between our 14000+ packages.
--
HTH,
Massa
Reply to: