Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/9/05, Humberto Massa Guimarães <humberto.massa@almg.gov.br> wrote:
> Raul, 90% of your questions (below) are rethoric.
Given the context, I haven't a clue what that means. This could be anywhere
from begging the question to a desire to focus on some useful 10% of
my questions.
> 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.
This is even more confusing. "assume every work eligible for copyright
protection...are not eligible for copyright protection"? In principle, I
ought to be able to figure out what you're saying by looking at the grammar
of your sentences, but in this case I can't.
One of the confusing things is where you say "by way of being in a .h
file (for instance)". As an instance of what?
If I start by assuming the conclusion you want to draw is correct, I
can work backwords and fit the pieces together so they make sense,
but that's not the same thing as these pieces being a valid argument
that your conclusion is correct.
> All the assumptions above create a simplified model, that we can
> refine later -- if we can come to any conclusion at all.
In other words, let's just start with the conclusion we want to draw?
Oh well, on to the questions:
> ** 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.
I'm trying to find an interpretation of this sentence that has
some meaning and I'm clueless.
As a general rule, all derivative works are produced by humans.
As a general rule, when we talk about transformations we're
talking about processes -- something outside the scope of
copyright law (thought not outside the realm of human
activity).
What I'm not getting is how the presence or absence of some
process which is outside the scope of copyright law has any
bearing on the question of whether one work is a derivative work
of some other work.
[For now, I'm skipping sentences which seem to depend
on this "intellectually novel transformation" sentence for
their meaning.]
> > 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.
>From my point of view, the technical features of a system (what
gets linked against what, and what the system does, etc.) are
not the deciding factors. They're just evidence about what the
nature of the creative work under discussion. Evidence, in and
of itself, does not decide the case. Evidence just paints a part
of the picture.
In other words, B and C could actually be the same program where
B is an independent work, where B is a derivative of O, or where
B is a derivative of M or where B is a derivative of both O and M.
Now, obviously, other facts about these cases would have to be
different for each of these possibilities. And there's plenty of room
to argue about exactly where the boundaries between these cases
would be. And, there's potential to argue about what licenses
on these works would mean in each of these different cases.
> > 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.
I don't think I've been enlightened.
Unless your point was that I should assume the conclusion so
that the argument makes sense.
> > > 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.
I'm interested in what you mean by "relevant" here. Do you mean
relevant to Debian's treatment of some software package? If so,
which software package would that be?
> > 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?
There are elements of glibc which "don't have much creativity", and
thus have only very thin copyright protections. As almost no programs
use glibc as a whole (most programs incorporate only a small fraction
of glibc), this can become relevant in some examples. Of course, in
other cases it's not at all relevant.
But, even if glibc is a heavily protected work in the context of some
example, that doesn't mean that the program in that example would
have to be a protected work.
> 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?
And the answer depends on the specifics of the programs in
question.
There is no legally valid answer to that question which applies
to all cases.
> > 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.
You have not said those particular words.
You have presented examples whose reasoning I would characterize
this way.
--
Raul
Reply to: