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

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

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

> 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

> 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.


Reply to: