Re: GPL, yet again. (The kernel is a lot like a shared library)
Raul, 90% of your questions (below) are rethoric. Assume every work
eligible for copyright protection, for the sake of the argument, and
for $DEITY's sake. AND we're talking ONLY about dynamic linking.
AND, to boot, that those bits that end up in a compiled work by way
of being in a .h file (for instance) are not eligible for copyright
protection.
All the assumptions above create a simplified model, that we can
refine later -- if we can come to any conclusion at all.
** Raul Miller ::
> On 09 Sep 2005 17:52:00 +0200, Claus Färber <claus@faerber.muc.de>
> wrote:
> > The argument, simplified, basically goes like this:
> >
> > 1. Program A is licensed under the GPL. => Debian can
> > distribute A.
> > Library M is licensed under the GPL. => Debian can
> > distribute M.
> > Program B is a derivative of A, which dynamically links against
> > M. => Debian can distribute B.
>
> (Question: is B a derivative of M? For that matter is A a
> derivative of M?
Is B a derivative of M? Is A a derivative of M? -- those are the
million-dollar questions.
I don't think so, because there is no intellectually-novel
transformation of M that produces A or B. The GPL text would think
it is -- at least for its own "a work based on the Program"
definition of a derivative work IFF we were talking about static
linking, which we're not. AT LEAST NOT INTRINSECALLY (sorry for the
caps, but this is important -- there *is* the possibility of A or B
being derivative works of M, but for this to be determined the
criteria of abstraction, filtration, comparison would have to be
fullfilled -- for the sake of our simplification, we assume NOT:
like a program that uses SHA1() and MD5() is NOT a derivative work
of OpenSSL and a program that uses printf() is NOT a derivative work
of glibc)
> Is A+M a work eligible for copyright protection? Is B+M a work
> eligible for copyright protection?)
>
> > 2. Library O is licensed under the a BSD-like license, which
> > contains an advertisting clause. => Debian can still distribute
> > O.
> > Program C is a derivative of A, which dynamically links against
> > O. => Debian can't distribute C.
>
> (Question: is C a derivative of O? Is C+O a work eligible
See above.
> for copyright protection?)
>
> > 3. Library M is fully compatible to O. So programs B and C are
> > actually identical.
> > => Debian can and can't distribute B/C at the same time.
> > => This can't be right.
>
> (M can be fully compatible with O without B being identical to C.
> And I've some other questions about the nature of B and C -- see
> above.)
Imagine that B and C are actually the same program, and you'll see
the argument.
>
> > So one of the assumptions made above is wrong. The only
> > assumption that is not obviously right is: "Debian can't
> > distribute C".
>
> I can see other things which rather obviously could be wrong. But
> there's too few details here to really say for sure.
Hope I enlightened you.
>
> > Well, you can replace "Debian can't distribute C" by "Debian
> > can't distribute C unless M is available". But this is very
> > strange as it would mean that the advent of M changes the
> > copyright status of C, which is actually derieved from A and O.
>
> One of the issues here is that in the typical case the advertising
> clause isn't enforced, nor is it enforceable. So, in the typical
> case, it isn't a restriction on redistribution, and can't be a
> problem with the GPL.
Not relevant. Suppose advertising clause enforceable and actively
enforced.
>
> Further, in the cases where it could be an issue, it's likely a
> trademark issue rather than a copyright issue, so it's still not a
> restriction on redistribution.
>
> Unless... well, we probably could cook up a hypothetical case
> where this advertising clause is a copyright problem. But your
> above presentation has enough problems even without this kind of
> hypothesis.
Please, back to the subject, so we can construct a coherent thinking
framework...
>
> Put differently, what you're probably arguing is that there are
> programs (and libraries) which don't have much creativity in them,
> and so aren't eligible for more than an absolute minimum of
> protection. But this kind of argument is rather specific to those
> kinds of programs and those kinds of libraries.
>
No! Is glibc below your line of "don't have much creativity"? or
OpenSSL? It's not below my line. The problem /in/ /casu/ is: can a
GPLd program that dynamic links with a GPL-imcompatible-licensed
library be distributed at all? Especially if there is another,
fully compatible, GPLd, library that is distributed in the same set
as the program and the library?
> You might even argue that most programs (or libraries, or exported
> elements of libraries, or code bases, or whatever) are lacking in
> creativity, but this argument can never apply to all
> programs/libraries.
I never said any of this, nor did Claus.
--
HTH,
Massa
Reply to: