Slashdot Mirror
Debian Removes Binary-only Firmware From Kernel
mbanck writes "The Debian Linux kernel maintainer has announced that he will remove firmware from GPL'd drivers which obviously lack source code in its preferred form (i.e. something more appropriate than a hexdump inside a char[]), in accordance with the release manager's decision. The alternatives are user-space loading of the firmware via hotplug's request_firmware() API or making the vendors aware of the issue. How do the other distributions handle this?"
I agree that this is going a little far.
The firmware code doesn't get executed by the CPU, and thus in a sense it doesn't get executed by Linux. Firmware is used by an off-board processor, and thus I don't see a GPL violation here.
Consider if a piece of hardware needed a Magic Number string to start up. No code, no logic, no meaning; just a magic number required to activate the device. Can't we consider the firmware code as just a magic number? After all, Linux doesn't interpret or execute it.
(\(\
(^.^)
(")")
*beware the cute-bunny virus
The GPL does not permit this bundling. It is clearly linked, and it is not the source code.
To distribute it like this is a violation of the GPL.
Your choices in your situation would be to add the driver yourself. The supplier could likely write a trivial patch to install it into your kernel source. You could then freely use it.
You're complaining about debian holding you hostage when it is actually the supplier of the closed module who is causing the problem. They could always release a GPL compatible driver.
The difference between shipping with your firmware in the device itself and putting it in the kernel is the same as the difference between putting your firmware in a file and having a user-space utility upload it and putting it in the kernel. The difference is a legal one - in both these cases, the "putting it in the kernel" means you're bound by the GPL, and you must release source to that firmware if you choose to redistribute the kernel. In both of these cases, not making the firmware "part of" the kernel means the code is unencumbered and you can go ahead and be as mean, from a free software advocacy point of view, as you want.
I agree it would be nice to have the source code for everything I have software for. But there are only certain areas where the absense of source code causes an actual problem. If you link with a GPL'd program, then it's an issue, because you've chosen to modify and redistribute that program directly that way.
You are not alone. This is not normal. None of this is normal.
while we may all be fine and happy with drivers that work using vendor supplied binary-only bits of firmware inside an otherwise open driver, those vendors are not guaranteed to continue supplying that firmware or keep it free forever (as if buying their hardware isn't enough!).
keeping that out of the kernel and as something to be loaded by hotplug is the best that can be done for devices that the vendor won't (and often can't) provide full source for.
the messier issue is where do you draw the line at what is allowed and what is not? is a sequence of 20-odd magic values written to proprietary chipset registers any different than 800 bytes stored in a string and sent to the device on startup? both are equally obfuscated but only one is likely "code" in any sense due to its size.
less and less devices will bother to have any rom and firmware on them in the future as a flash rom takes space and costs money and is not needed when the OS can load it for you. tackle this now!
Except in this case the principle their sticking to is rabid legalism.
What? Debian's goal is to be a complete, *Free* operating system, where the definition of "Free" is the one put forward by RMS and the FSF, namely: Free to use, free to examine, free to modify and free to share. These binary-only firmware components are not Free. You may have freedom to use and share them, but you can't examine or modify them. Debian wants to be a Free operating system not Mostly Free, or Very Nearly Free.
What's "rabid" or "legalistic" about that?
It's pragmatism taken to an extreme.
That sentence parses just fine (no misspellings, even!) but it makes no sense. What are you trying to say? How can such an impractical decision be "pragmatism taken to an extreme"? What would that phrase mean anyway? Extremes, by definition, are not pragmatic!
It has nothing to do with FSF style "save the users from themselves" ideology.
Now you've switched to a different target, choosing to mischaracterize the FSF's position. FYI, the FSF has no intention of saving users from anyone, the FSF just wants to make it possible for people who want to to create, use, read, modify and distribute Free Software, with the assurance that the original author's wishes (that it be Free) will continue to be honored as long as the copyrights are in force. If anything, it's about saving developers from having their work misappropriated, not about saving users from anything.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Exactly. It seems to me that you could make a good argument that the firmware is not being linked to the kernel, and therefore is not required to be under the GPL. All the module is doing (if I understand things correctly) is taking a binary firmware file and uploading it to the device. Doesn't seem to me to be any different than using a GPL'd FTP client to upload a non-GPL'd binary to a fileserver, and I'm pretty sure even RMS wouldn't say that was a violation of the GPL.
"If English was good enough for Jesus, it's good enough for everyone else."
It's amazing how inconvenient it can be to stick to one's principles. In this case, we have binary globs being shipped in the kernel. The question isn't about whether you're allowed to use them as the end user. You are. The question isn't whether this is a GPL violation. It's not.
Normally we think of the kernel as being one package licensed under the GPL. Instead, if we take Torvalds' claim as gospel (and we can since it's estoppel), the kernel is GPL'd but ships with non-GPL'd parts. This is no conflict; the firmware is not a derived work and need not be covered under the GPL. As long as Torvalds has the right to redistribute those binary blobs, under any license, then he can distribute them with his kernel.
Debian, however, has a more difficult decision. The Debian Free Software Guidelines (DFSG) dictates that "The program must include source code..." and this clause applies as much to firmware as it does to the kernel core.
It's easy to criticize Debian as being overly pedantic without due concern for their users, or to say that they aren't being pragmatic. Instead Debian alongside hardline Free software advocates such as Stallman himself are being very pragmatic; their efforts of refusing non-Free software promotes the continuing development of Free software. They are consistently working towards a world of Free software, and pragmatically, compromise is a step in the wrong directory.
Maybe the code isn't shipped because we don't have compilers that will compile it. Obviously, the solution isn't to ship binary firmware with the kernel, the solution is to author a Free software compiler for this architecture! Or at least a GCC backend.
The other reason for Debian to be extremely pedantic about legal issues which is commonly overlooked is their dependence on the goodwill of their ftpmasters. The ftpmasters are the group of ISPs donating storage and bandwidth to Debian. Debian offers these people a guarantee: debian-legal (and lawyers with parent company Software in the Public Interest (SPI) are prepared to prove that the ftpmasters do indeed have the rights to redistribute all Debian software. Now, can you prove that with the kernel firmware? What license does it fall under, since it can't possibly be the GPL without source?