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?"
How do other distros handle it? What a retarded question.
Obviously, other distributions just include them because they want their stuff to work and don't like pissing off their userbase.
Ah, debian we love you for it though.
Liberty.
One of the drivers I use - the tg3 Gigabit Ethernet driver - is affected by this. The driver currently contains non-free firmware that is uploaded to the card in a couple of cases.
An interesting thing about this driver is that it appears to work (to the extent that most people need) without the firmware. There has been some attempt on the linux-kernel mailing list to make the firmware part of the kernel optional. That way Debian can just turn that option off and presumably remove the associated firmware from their kernel. Anyone who needs the bug fixes/features provided by the firmware can use a non-Debian kernel.
Not everyone's in favour of this idea though. There's more about it on the mailing list if anyone's interested.
Meep meep
Correct me if I'm wrong.
There are currently some vendors whose hardware require firmware to be uploaded to them (for example, Broadcom NICs), and these vendors have esentially embedded the binary for the firmware into the kernel source.
Since the firmware is most likely not GPL, and the kernel source is GPL, we've got a GPL violation on our hands.
So the suggested fix is to have these vendors pull the firmware out into its own file, and rewrite that part of the kernel source to pull in the firmware dynamically.
Doesn't really seem like that big of a deal, unless I'm missing something?
In some ways this is what Linux needs. Darwin's system, where kernel extensions are packaged up with XML files that describe capabilities, requirements, etc, strikes me as a good model to follow.
As far as Debian's choice with the kernel as-is, I honestly don't think they have much of a choice. There are licensing issues with including binary-only code in the kernel, I see nowhere in the GPL that gives a get-out if that binary is supposed to be run on a different CPU. Right now the practice is tolerated, but it probably shouldn't be.
You are not alone. This is not normal. None of this is normal.
Your comparison would be valid if the firmware files also included the source to that firmware, just as GCC comes with the Bison file and the file generated by Bison.
You are not alone. This is not normal. None of this is normal.
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
I second that... hell we should not run linux on any computer where we cannot have an open source bios.
Debian has to be the biggest bunch of holier than thou morons... why would you intentionally make it hard on the user of your software to get something done?
And I am not even trying to troll on this. It is a valid question. There is no good reason to do this other than a few zealots who are SO out of touch with the rest of the world.
If I was using Debian in a commercial setting that required the use of one of the "bad" drivers... what would my choices be? Stop my business until the "evil" drivers magically become open source? No I tell you what I would do... I would switch distros or even worse jump to Windows where the damn things are supported and probably already work.
Debian is doing nothing but causing problems just because they can.
This could be a very good thing for linux. It could encourage vendors to provide updated firmware that can be installed from userspace, without requiring a kernel patch. It could encourage vendors to provide firmware at all designed for linux. For some other vendors it will surely encourage them to release the source, which will only lead to a massive hack-fest and fast improvement in capabilities of the firmware, which the company can negotiate to include in their windoze product. It seems to me separating firmware is win/win for both vendors and users, even if it is rocky while the separation is taking place.
-- Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
Debian would be happy with firmware updaters as long as the source to the firmware is available and code to compile the firmware and update the module's binary with that firmware is available. The problem, at the moment, is that rarely is the firmware available.
You are not alone. This is not normal. None of this is normal.
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.
But, a point I was trying to make, what if the toolset required to generate isn't open? There could a dozen reasons for that from technical (the device's CPU is not supported by GCC) to political (tool used by vendor is closed - either by the vendor or by NDA).
Now were back to the discusion of device proliferation and hardware compatability. This point is already begin discussed quite well with one noteable exception.
What about vendors who lock their code into on-board EEROM chips? That class of vendor surely covers over 95% of them out there. Think about it CD-ROM drives, Video card 3D engines, Printers, Phones, Music Players. These all have on-board systems. But if the firmware is locked in the device for the most part, it's out of sight, out of mind. But, when you get right down to it, there's no difference between a hex-dump in a kernel file or code locked in on-board EEPROM.
The "Great Moment" that launched Richard Stallman's crusade to liberate software was when his trying to get a printer manufacturer to give him the source code to a buggy printer so he could fix those bugs. They said no. Not long after that incident and watching computer makers "steal" X11 for their own versions of UNIX, the GPL was born.
This is a boring sig
How does RMS expect us to compile a kernel for our architecture and for every architecture which we need embedded firmware for? We could end up being required to have dozens of different compilers (think ARM7, i960, MIPS...), not to mention libraries and other tools installed. Many of these are closed source, or are restricted from distributing the source. A good example is the DSP I am using at an optical controller company - the silicon vendor is the only source of the compiler which costs $4000 U.S., not to mention that many of the libraries we use are not available in source form.
Trust me, the embedded market is a completely different picture than the desktop when it comes to development. Even if the firmware source was released it would do you no good.
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!
Q: "But why don't they include the accelerated NVidia driver?!? That would be useful!"
A: Because it's not Free.
Q: "But why don't they include qmail?!? That would be useful!"
A: Because it's not Free.
Q: "But why don't they include pine?!? That would be useful!"
A: Because it's not Free.
Despite that, every time Debian removes (or refuses to add) a piece of non-Free software, the "pragmists" queue up to swear that Debian is irrelevant because they don't care about market share, or that they're a bunch of extremists.
Understand this: Debian has a very explicit social contract with their users. If you continue to be surprised by their strict adherence, then either 1)you need to accept that they will always side with Freedom over pragmatism, or 2)you have a seriously warped worldview that causes you to be mystified by integrity. Either way, find something else to gripe about.
Debian is Free and increasingly popular among those of use who share that value. Every time they make a difficult decision like this, even at the expense of practicality, I respect them even more. Even if you hate Debian, you still benefit from their hard-line observation of their ideals every time you execute a bit of Free code that exists because they otherwise would have rejected it from their distributions.
I just don't why some people are still surprised each and every time. A real news article would be "Debian includes Qmail in 'main'". Now that would be a reason to criticize them. This is not.
Dewey, what part of this looks like authorities should be involved?
If the firmware really is the preferred form of modification and is (along with the rest of driver) GPL'd, everything is fine. Of course, this is a bit hard to check, but talking to the vendor might help here.
But keep in mind that we are talking about the preferred form of modification here, from the POV of the vendor.
Michael
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?