Re: How long is it acceptable to leave *undistributable* files in the kernel package?
Raul Miller <email@example.com> writes:
> On Wed, Jun 16, 2004 at 07:25:17PM -0400, Michael Poole wrote:
>> How to use it without Linux? There is more than one operating system
>> in the world. At least a few of them (including Linux) provide more
>> than one way to load firmware to a device, although not all device
>> drivers may support all the mechanisms.
> Likewise, the compression routine in linux can be used without the
> kernel -- and if it's available under some other copyright that can
> be used in that context. But this doesn't mean that the compression
> routine in the linux kernel can have a conflicting copyright.
Because of the nature of interaction, I believe a court would treat
that case very differently than firmware.
> I'm trying to ask you about the case you proposed -- where the kernel
> is the "medium". How do you use the firmware without the kernel in that
> case? In what way is this sort of extraction of the firmware different
> from the extraction of any other kernel code which happens to be useful
> in some specific context?
I do not understand the question. The question is not whether you
extract the work later, but whether the collective work is governed by
the GPL. Copyright covers creative content, not mechanical
transformations, so whether the firmware is in an ASCII format --
suitable for input to a compiler -- or a binary format -- suitable for
loading as part of a kernel module, userspace module, or Windows
device driver -- is irrelevant. Assuming the firmware author(s) grant
such permission, I could use the firmware with FreeBSD or Windows or
I (and others, including Linus) believe that is sufficient to qualify
as mere aggregation: the firmware defines a very clear and strong
interface. This is in contrast to the executable parts of a kernel
module, which have no limits in the kernel's address space. To borrow
the US federal court idea of abstraction, filtration and comparison,
you can define a very abstract (high-level) interface for firmware;
you cannot do so for most modules because they depend so closely on
the rest of the kernel.