On Thu, 2008-05-29 at 14:11 -0700, Arjan van de Ven wrote:I do -- partly because it's not just from the fundamentalist camp, partly because (after the work I've been doing) it doesn't actually _hurt_ us to assume that they're right, but mostly because I have a horrible suspicion that they _are_ right. Expanding on those three points not in that order...: The firmware is an independent and separate work in itself. Section 2 of the GPL talks about such sections of the work, explicitly. The only way to excuse what we're doing at the moment is to call it 'mere aggregation' -- an exception which was intended to handle stuff like the 'freeware' CDs on the covers of magazines, distributing a bunch of unrelated software. Not a coherent work combining software from different sources into a single entity which works closely together as one, and where one part is useless without the other. The more that people claim it would be such a burden to split the firmware from their driver because they're so closely interrelated, the more they are arguing against the 'mere aggregation' defence, which was tenuous enough in the first place. And it isn't just the nutters. Fedora also wants to ship the firmware in a separate package from the kernel -- since the alleged GPL violation is such a _gratuitous_ risk given that we always use an initrd anyway, and because people want to be able to do 'Free' spins which don't feature the firmware at all, even in the source packages. I strongly suspect we'd end up building the Fedora kernel from a special 'linux-2.6.2x-nofirmware.tar.bz2' tarball, rather than using the stock tarballs if they continue to include the firmware. We do similar things with 'openssh-5.0p1-noacss.tar.bz2' already, for example. There are people who own copyright on firmware who refuse to put it into the Linux source tree, because their lawyers don't believe the 'mere aggregation' line, and believe that including it in the kernel source in any form would require them to license it under the GPL. But those same companies _would_ consider putting their firmware into a non-GPL'd 'linux-firmware' repository instead. So by moving our firmware out into a separate tree, we should actually make it _easier_ for people to find all the necessary firmware in one place. It's not as if it's hard to set CONFIG_BUILTIN_FIRMWARE_DIR to point to your checkout of the linux-firmware repository, and build your kernel with _whatever_ firmware you choose. You end up with _more_ choice, not less. And on the rare occasion that we really do have an incompatible change of firmware/kernel interaction from one kernel to the next, it really isn't difficult to add a version number to the name of the firmware file, and ship both old and new firmwares in the firmware tree for a while. That's a bogus argument, even if people _do_ manage to come up with a better example for it, where their firmware has actually changed in the last couple of years. As soon as we have firmware converted to ihex files in the kernel source tree, I'll set up a 'shadow' git tree like my kernel-headers tree, which automatically follows the linux-2.6.git tree commit by commit, and contains just the results you'd get from 'make firmware_install'. At that point, when the distributions want to do it separately and individuals who want to build firmware into their kernel really could continue to do so _very_ easily, I just don't see any good reason why we'd continue to keep them together. -- dwmw2 --
| James Bottomley | [Ksummit-2008-discuss] Fixing the Kernel Janitors project |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| David Miller | Slow DOWN, please!!! |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
