| |||||||||||||
|
| |||||||||||||
The kernel and binary firmwareThe kernel and binary firmwarePosted Apr 7, 2005 15:18 UTC (Thu) by bfields (subscriber, #19510)Parent article: The kernel and binary firmware
Recently, the issue has come up again with a new twist: the fear that, even if a firmware blob comes with a free license, it cannot be distributed as part of the kernel because it's not in "the preferred form for modification." It's true that that may be a problem, but I think that you've missed the point of the linked-to message, which is actually that firmware blobs with certain kinds of licenses *can* be legally distributed with the kernel. To quote from that message: It is obvious in this context that the non-free firmware constitute a mere aggregation and not an act of linking with the rest of the kernel. This is at least the consensus that debian has reached with input from the debian-legal lists, and what we will stand by this. Despite the use of the word "obviously" here, this is the new insight: previously some have claimed that merely redistributing a kernel with such blobs was illegal. Now the debian community, at least, seems to accept the argument that since firmware blobs execute on completely different hardware, it makes more sense to think of the kernel tarball, containing both firmware and linux source, as a "mere aggration" of the two constituents, more akin to a gnu/linux distribution than to the source for a single program. *That* is the "new twist": not that distributing binary blobs under the GPL was questionable (that was always obvious--source availability is, after all, exactly one of the things the GPL is meant to ensure) but that distributing binary blobs in the same tarball with the GPL'd kernel source is OK. That is, it's OK *if* the owner of copyright in the blob has given permission to do so. And that's the one remaining problem which the debian developers would like to see fixed: they want to see resolved those cases where binary firmware is included without clear permission to do so. This includes cases where the firmware appears to be GPL-licensed, since that is obviously nosensical. Of course it's a separate question whether this is actually a big deal, and whether the problem wouldn't be better solved by moving the blobs out of the kernel anyway. --Bruce Fields
(Log in to post comments)
The kernel and binary firmware Posted Apr 7, 2005 15:44 UTC (Thu) by ballombe (subscriber, #9523) [Link] I don't think the statement you quote quite match the fact:> It is obvious in this context that the non-free firmware constitute a mere aggregation and not an act of linking with the rest of the kernel. This is at least the consensus that debian has reached with input from the debian-legal lists, and what we will stand by this.
First Sven has no autority to speak as "Debian", and secondly is unclear whether the debian-legal has reached such a consensus.
The kernel and binary firmware Posted Apr 7, 2005 16:25 UTC (Thu) by bfields (subscriber, #19510) [Link] First Sven has no autority to speak as "Debian" OK, fair enough. and secondly is unclear whether the debian-legal has reached such a consensus. Hm, but that wasn't the impression I got; can you provide pointers to opposition within Debian? (Something reasonably thorough and well-reasoned, not just someone saying they don't agree, without providing a good argument.) I still stand by my original point, though: the main new argument I saw in that email was *not* that firmware blobs would be non-distributable in some cases (that's been beaten to death before), but that they were distributable in more cases than people had previously assumed, so that moving them out of the kernel is no longer required. Whether the argument put forth there represents a concensus within Debian I don't know. --Bruce Fields
The kernel and binary firmware Posted Apr 8, 2005 0:16 UTC (Fri) by giraffedata (subscriber, #1954) [Link] it makes more sense to think of the kernel tarball, containing both firmware and linux source, as a "mere aggration" of the two constituents, more akin to a gnu/linux distribution than to the source for a single programI don't see how that could even be controversial or new. Many projects distribute tarballs that contain both GPL and non-GPL source files, and people agree that the tarball is not a derived work of the GPL files. I thought the issue was the kernel binary -- the bzImage file. Many people believe that whole file is a derived work of GPL source code and therefore I cannot distribute the file to someone without offering source code for every byte in it. If some of those bytes are binary-only firmware, I can't meet that condition. But I can easily see a novel controversy in the question over whether the binary-only firmware in the bzImage file is part of the derived work. Is that what's in question?
The kernel and binary firmware Posted Apr 11, 2005 21:17 UTC (Mon) by czr (guest, #13701) [Link] Given the recent 2.6 kernel ability to piggyback cpio-files in the bzImage(initramfs), I find this interesting. The piggybacking mechanism is a quick and dirty way of "append" in initrd-image into the bzImage so that one can get a working initrd without relying for the boot loader to know how to load initrd-files. If, indeed, the whole bzImage file to be thought as derivate work of the kernel, that would mean that also the contents of this piggybacked cpio file would fall under the GPL. Note that the initrd might easily contain software which is not "part of the kernel" or even know/care what kind of UNIX-like kernel it runs on (unless you distribute kernel modules with it, but even then you'd not be restricted by GPL per se). Does anyone have a clear picture on this issue and the rationale on why exactly the whole bzImage file should be considered under GPL, or just the kernel part (in this case)? If this is indeed the case, how would this be different from the bootloader loading the non-GPLed initrd-file and patching system memory with it before starting the kernel (which is what is normally done)?
The kernel and binary firmware Posted Apr 14, 2005 9:34 UTC (Thu) by xoddam (subscriber, #2322) [Link] If you can include an archive into a kernel image and an archive consistsof 'mere aggregation', then the bzImage may as well be considered a self-extracting archive just like a shar or an executable installer for a Windows application. The line the GPL draws between 'linking' and 'aggregating' looks a bit like the 'strange' screensaver right now :-)
|
|
||||||||||||