From: "David Schwartz" <davids@webmaster.com>
To: <debian-legal@lists.debian.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: How long is it acceptable to leave *undistributable* files in the kernel package?
Date: Fri, 18 Jun 2004 17:12:58 -0700
Message-ID: <MDEHLPKNGKAHNMBLJOLKOEINMLAA.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <40D2F463.6090104@almg.gov.br>
Importance: Normal
Reply-To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3221
Lines: 60


> But wait; firmware is *not* linking with the kernel, as the icons
> are *not* linking with emacs.  Or are they? What is linking? If you
> consider linking to give names fixups and resolving them, well, the
> char tg3_fw[] = ... is linked with the kernel all right. If you
> consider that a call (as in the asm CALL opcode sense) must be made,
> it's not. The firmware does not "execute", at least in the main CPU.
> Anyway, the non-GPL-compatibly-licensed icon in your previous emacs
> example is *most* *certainly* not linking with emacs (in the
> ld-or-ld.so sense) and it's OK.
>
> The (simplified) answer: the GPL "do not link" is weak because of
> the "mere aggregation clause" and because of the dichotomy between
> derivative and anthology works; it's weaker in the case of the
> binary kernel modules, especially if they are not distributed with
> the kernel (the linking is done at the end user, where many things
> are possible); it's even weaker in the case of firmware (because
> firmware does not /properly/ link in the software sense, even if it
> *does* link in the ld-or-ld.so sense); it's really faint in the case
> of an accompanying icon or image (or movie: eMovix comes to mind).

	I think there's a continuum here. If, for example, the firmware in the
Linux kernel is identical to the firmware in the Windows driver and the
Linux kernel contains no special code to talk to this firmware (in other
words, the firmware makes this device look like every other similar device
and the kernel contains a generic driver), then the 'mere aggregation'
argument is persuasive. We have two independently derived works that happen
to be combined in a single file. They each happen to implement the same
interface from opposite sides, but they do so for different reasons and are
not specifically designed to work as a unit.

	On the flip side, if the Linux kernel code were developed just to talk to
this firmware and this firmware were developed just to make this device work
with Linux, then the 'mere aggregation' argument seems ludicrous. Each work
is specifically designed to work with the other, they aren't just combined
after the fact. The two had to have been developed together and each has
portions that only make sense in combination with the other.

	There are, of course, points in the middle of the continuum.

	I personally have no issues with the lack of the preferred form for the
purposes of making modifications. I don't find that fight worth fighting in
any case. I do, however, have major issues with use restrictions and
distribution restrictions. Code that cannot be freely used, reverse
engineered, modified, used on whatever hardware or with whatever software,
or distributed subject only to the GPL restrictions should not be integrated
into the Linux kernel. These restrictions cut to the heart of the very
freedoms the GPL is supposed to protect.

	DS

	PS: Please CC me on any replies that you wish me to read and possibly reply
to.


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