From: "David Schwartz" <davids@webmaster.com>
To: <debian-legal@lists.debian.org>, <linux-kernel@vger.kernel.org>
Subject: RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Date: Thu, 14 Apr 2005 10:44:10 -0700
Message-ID: <MDEHLPKNGKAHNMBLJOLKCELDDCAB.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <425E5FA6.1030702@almg.gov.br>
Importance: Normal
Reply-To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 8570
Lines: 189


> That is the point: the result is not a single work. It is a
> collection or compilation of works, just like an anthology. If
> there is any creativity involved, is in choosing and ordering
> the parts. The creation of works that "can be linked together"
> is not protected by copyright: the literary analogy was to
> "create a robot short story". Such a story could go into an
> anthology called (duh) "Robot Short Stories", but its
> licensing is independent of every other robot short story in
> the world -- except those it is a derivative work of.

	That's fine then, if you want to define derivative work in this way, then I
can configure, compile, and link the Linux kernel without permission of the
copyright holder under first sale (since no derivative work is created). I
can write a program that uses a library, compile my program, and link it to
the library, again without creating a derivative work.

> You are making deaf ears: using a library (even by static
> linkage) does NOT create a derivative work unless:
>
>         (a) you make another version, subset or superset of
>         the same library, modifying, enhancing, the
>         functionality of the original library; or
>
>         (b) you make a program that is *so* dependent on the
>         *internal* implementation structure of the library
>         that it can be considered a derivative work.

	Okay. This gets to the same result that I get to, which is that you can do
all the things you want to do without permission from the copyright holder
under first sale. Since this is not creating a derivative work, no special
permission is needed.


>  >> >This is, by the way, the FSF's own position. It's not
>  >> >something I'm making up or guessing at.
>  >>
>  >>Please send us some pointers to this statements for the FSF.
>  >
>  >
>  >    Read any of Eben Moglen's posts.
>  >
>  >> >"The license does not require anyone to accept it in order
>  >> >to acquire, install, use, inspect, or even experimentally
>  >> >modify GPL'd software. All of those activities are either
>  >> >forbidden
>  >>
>  >>Wrong again. GPL, section 0, para 1: "Activities other than
>  >>copying, distribution, and *modification* are not covered by
>  >>this License". Emphasis mine.

>  >You are free to disagree with the FSF's interpretation of the
>  >GPL, but you are not free to misrepresent the FSF's
>  >interpreration.

> No. First of all: you are begin uncivil here. I did not accuse
> you of anything, other than not reading correctly what I
> wrote previously; which I can attribute to my poor knowledge
> of the English language. So, please, I am not being impolite
> to you, do the same.

	Read the quote above.

> Second: you did not provide a concrete pointer to one of Eben
> Moglen's posts, for instance, saying that modification is not
> covered by the GPL. Me, OTOH, showed you that the TEXT of the
> GPL says it covers modifications.

	Read the quote. For about the fourth time in this thread, here's the cite:
http://emoglen.law.columbia.edu/publications/lu-12.html "The license does
not require anyone to accept it in order to acquire, install, use, inspect,
or even experimentally modify GPL'd software."

>  >Feel free to disagree with the FSF about the meaning of the
>  >GPL, but it is the FSF's position that you can modify a GPL'd
>  >work without agreeing to the GPL.

> I don't disagree with the FSF -- you are alleging that this is
> their position, and I am disagreeing with YOU. And you have
> not produced evidence in contrary.

	I don't know what to say. The FSF has had a clear, consistent position on
the GPL for a very long time and it has always been that ordinary use is
permitted without agreeing to the GPL. For source code, modification is
often part of ordinary use. Anyone who has grabbed a package intended for a
different version of their OS and had to tweak things to get the code to
work knows this.

> We = You and Me disagreeing. And you still have to show where
> the FSF says the GPL does not cover modifications.

	I never said that the FSF says the GPL does not cover modifications, I said
it doesn't cover ordinary use. That means it doesn't cover modifications
when those modifications are made in the course of ordinary use.

>  >    2) The result is not a derivative work, hence you
>  >don't need permission from the copyright holder to do it.

>         ** THIS ** : yes, the result is NOT a derivative work.
>         So, to link with a library you don't need permission.
>         That's what I said since the beginning.

>  >    Either way you get the same result, permission is not
>  >needed beyond permission to use.
>
> Conceded.

	Okay. So you get to the same place I get by a different route. One of the
strange things I've noticed is nearly all cases, you get the same result
whether you think the final work is a derivative work or not.

>  >    Then all the people who think that creating a binary
>  >kernel module requires creating a derivative work and hence
>  >can be restricted by the GPL are wrong.  Take that argument
>  >up with them.

> I took. Google my name on lkml and you'll see. They ARE wrong.
> Linus himself studied carefully the situation and came to the
> conclusion they are wrong,

> I'll rewrite something, from this e-mail, for emphasis:
>
> "You are making deaf ears: using a library (even by static
> linkage) does NOT create a derivative work unless:
>
>         (a) you make another version, subset or superset of
>         the same library, modifying, enhancing, the
>         functionality of the original library; or
>
>         (b) you make a program that is *so* dependent on the
>         *internal* implementation structure of the library
>         that it can be considered a derivative work."

> If you make a kernel module that only uses something
> EXPORT_SYMBOL()'d from the kernel, you are NOT in principle
> writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d
> symbols, then you are incurring in (b) above and your kernel
> module is most certainly a derivative work.
>
> I think Linus' opinion pacified this point, at least on LKML.

	I don't think courts seem to agree with this, but I can only find cases
where the result really would have been the same whether or not the work was
derivative. For example, one case inolved a company that stole test
questions from another company. The courts ruled that the test with some of
the "borrowed" questions was a derivative work, even though there's no
special "integration" of the questions. But they could perfectly well have
reached the same conclusion without the "derivative work" argument.

	There are court cases on point that definitely disagree with you, for
example Mirage Editions, Inv. v. Albuquerque ART (cutting a picture out of a
book creates a derivative work). Also National Football League v. TVRadio
Now (embedding someone else's broadcast with your advertisements through an
automated process creates a derivative work).

	I think it would make a lot of sense if courts held that compiling and
linking are analogous to format changes (like converting an audio-visual
work from DVD to VHS). This process involves making copies of the work so
that it can be used in different environments that have different technical
requirements. (Except in cases where one work is heavily adapted to the
internals of another.) It's clear that anyone who tried to get an
independent copyright on their compiled Linux kernel binary should be
laughed off the planet.

>  >    I think even if the result is not a derivative work,
>  >the rules for distributing it would be the same. However, it
>  >would change the rules for creating it. Either way, however,
>  >you get that you can do it without agreeing to the GPL, and
>  >this is the FSF's position.

> You repeated this a lot of times, but you have not
> substatitiated it, at least WRT something I asked you: please,
> give me some *link* where EM, RMS, or any other FSF/GNU guy
> contradicts the GPL section 0 paragraph 1 ("modification")
> saying that you can modify a GPLd work without agreeing to the
> GPL.

	This has always been their position, when modification is needed for
ordinary use. See the quote from Eben Moglen above. Now, as I said, they
reach different conclusions based on this, but we agree on this.

	DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/