Re: GPL, yet again. (The kernel is a lot like a shared library)
** Raul Miller ::
> 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.
No, 90% of the questions are "is this eligible for copyright
protection?".
>
> > 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.
I thought that one was simple:
1. please assume every work mentioned in the argument (unless
otherwise noted) eligible for copyright protection;
2. please assume we are talking (unless otherwise noted) about
dynamic linking; and
3. please assume that those bits that end up in a compiled work by
way of being in .h file or any other similar thing are not eligible
for copyright protection (this is an explicit exception to #1
above).
>
> One of the confusing things is where you say "by way of being in a
> .h file (for instance)". As an instance of what?
Yes. one nice example are text of non-trivial inlined functions.
>
> 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).
Why is it outside the scope of copyright law? The copyright law
itself defined a derivation as the result of said processes. 17USC
enumerates some processes, and Brazilian Author's Rights acts
defines them.
>
> 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.
The processes are not outside the scope of copyright law.
>
> [For now, I'm skipping sentences which seem to depend on this
> "intellectually novel transformation" sentence for their meaning.]
Intellectualy novel transformation is the text of the code law that
defines "derivative work" in Brasil. I suspect -- but I don't have
the time right now to confirm -- that this text (which is already in
one of my recent posts) is directly copied from the Geneva
convention text. IOW, it's the letter of the law.
>
> > > 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.
I fail to see the correlation of the paragraph above and the
argument above it.
>
> 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?
Yes. The whole argument is: Can Debian distribute program X,
dynlinking to libcurl, dynlinking to openssl? Or MUST Debian make
its version of program X dynlink to libcurl + gnutls? Even if the
latter has worse performance than the first AND openssl is in the
distribution anyway?
>
> > > 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.
The relevance here is: do you consider MD5() and SHA1()
non-protectable? If you do, your argument leads to: Debian can
distribute program X dynlinking to libcurl dynlinking to openssl
without any preocupation.
>
> 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.
Yes, but we should decide on a general (simplified rule) first, and
then see if the rule is or not applicable to each case.
>
> 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.
>
I fail to see how. And you did not explain how, either.
My (only) argument is:
As a *general* rule, given a program P and a library L, both
eligible for copyright protection, unless P has a *creative* reason
for being a derivative work of L (*), the sole fact that P dynlinks
with L does NOT make P a derivative work of L (**) and, because of
all arguments already presented here about the text of the GPL, the
fact that one of them (either P or L) is licensed under the GPL does
NOT affect the licensing of the other.
(*) ie, P is the result of an intellectually-novel transformation on
L, or P is the result of any of the processes that 17USC enumerates
as making a derivative work of L.
(**) Andrew Suffield made the case that this would be true, ie, if my
program uses MD5() and SHA1() then it's a derivative work of
openssl.
--
HTH,
Massa
Reply to: