From: "David Schwartz" <davids@webmaster.com>
To: "Sven Luther" <sven.luther@wanadoo.fr>
Cc: "Marco Colombo" <marco@esi.it>, <linux-kernel@vger.kernel.org>
Subject: RE: non-free firmware in kernel modules, aggregation and unclearcopyright notice.
Date: Wed, 13 Apr 2005 18:54:32 -0700
Message-ID: <MDEHLPKNGKAHNMBLJOLKAEHLDCAB.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <1113359021.13407.42.camel@localhost>
Importance: Normal
Reply-To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1088
Lines: 26


> It seems to me, that to be consistent with the argument you seem to be
> presenting concerning binary data in GPLd code, that you also need to be
> demanding the "source" hardware design for binary register values.
>
> Why not consider the binary firmware in the same category as binary
> register programming information?  You poke these magic bytes into these
> memory locations and it works.
>
> Where do you draw the lines between "write this byte to set the input
> gate here and the output gate to there" and "write this byte sequence to
> send the input byte through this loop, into this buffer, add it to the
> last byte entered, and output it over there"?

	You draw the line at the source code, the preferred form of the work for
the purpose of making modifications to it. See GPL section 3. Firmware is an
executable work.

	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/