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.
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.
I would guess that people who simply expect their hardware to work and those using Debian are (mostly) different groups.
:w!q
"The alternatives are ..."
;-)
Nah, the alternative is to roll your own kernel.
The firmware licensing issue has been debated and resolved by the kernel people already.
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 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.
Very good point. Now what would you do if some asshole of a kernel developer decides that the drivers amount to a violation of the GPL on his code? The developer could sue one or more of the distros, and might get a restraining order on distribution of his code. What would your business do then? Move to Windows? Or Debian?
I am not remotely implying that kernel developers are assholes - but think how much damage a smart and hostile person (or company, I'm looking at you, MS) could do by this method if they could get a "sleeper" into the kernel dev team.
Yours paranoidly,
I
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.
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 you can't distribute the entire collective work under the GPL, you can't distribute the GPLed portions. The only exceptions are for "mere aggregation" or "fair use" as you stated. Those are not the case for large binary chunks embedded into a GPLed driver. Distributing it is a copyright violation (a GPL violation isn't a real thing, it's always a copyright violation). Please don't spread misinformation on this issue!
News for nerds, stuff that matters
:oP
Deciding just what is open source when it comes to the kernel gets stuck in developer section, but a rumor that Darth Vader may be setting some new fashion trends that's about 3 paragraphs long - stop the presses.
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
The explicit social contract is the #1 reason why I stick with Debian. In the past, Debian had a number of unique features like apt and a sensible filesystem layout. But other distros have caught up and Debian no longer has a lead in those areas. But Debian is still the "most free" of the Linux distributions. I can rest assured that everything in main has been argued to death over its actual freeness. This might not mean much to some people but it means a lot to me.
If Debian ever reneged on its social contract and started compromising "free" for "convenient" then I'd have lost my last good reason to stick with Debian. I'd probably switch to Fedore Core because at least that's more like the systems I install for customers (typically RHEL). So I'm grateful that Debian has stuck to its charter on this one. We need at least one distro that gives freedom the highest priority.
To be fair, RedHat seems to be as pedantic as Debian with regards to licensing. Look at the MP3 situation on RedHat. So perhaps RedHat can give Debian a serious run for the trophy in the "most free" category.
The letter of the GPL allows one to the use of a non GPL compiler/translator. If a vendor wrote their on compiler/translator, then the source is whatever the vendor uses to generate the binary. The module could load the firmware with a statement such as: "load_firm(board_id,port,parm1,...)". The compiler/translator could generate an inline routine to load the firmware and buffer with the firmware data. The module is compliant with the GPL as the source is written in The language of the compiler/translator. The Compiler/translator is not under the GPL, but if all Macros to generate the output are static loaded into the compiler/translator then the source of the firmware does not have to be delivered, nor the I/O sequences, as it is embeded in the tool. If all scripts, Makefiles, source for the module, and libraries used by the module are delivered, the the module is under the GPL. This satisifies the letter of the GPL, but not the spirit. But as the actual source of the tool used to generate a GPL module is not required, the source that is delivered does not have to give a view of whats under the hood, only a Macro view of the program flow. Therefore the source delivered is not as useful for modification, but the output could be linked into the kernel and still have a GPL kernel. This loophole could allow a vendor to provide a GPL driver for linux and still keep the actual interface closed, if they provide the Macro source for their compiler/translator and the support files to build a binary/module for linking into the kernel.
That Debian's decision even appears on anyone's radar is a testament to it's success in attracting a significant number of users who have chosen it in preference to many alternative distributions. People have to remember that proactive support of free software has always been the primary goal of Debian. The fact that reliance on software meeting relatively strict definitions of being free has also produced a distribution that many people have come to trust and rely on is appreciated, but popularity has never been the main impetus for Debian's developers. Some people seem to view Debian's current stance on binary-only firmware to be disrespectful of its users, who may be temporarily inconvenienced by lack of kernel drivers for some hardware. But people should respect the Debian developers and their wishes to produce the best system they possibly can using only truly free software. Debian cannot and should not be bound to placate people who want the quality and stability of Debian software, but who do not honor the primary reason for Debian's very existence.
There are plenty of other distributions to choose from for users who find Debian's actions unacceptable. People who insist on pragmatism over principles should probably choose one of those alternatives. Debian should be left alone to pursue their software ideal, especially since they are one of the few to place such a high value on software freedom. Rather than chide them for not following the pack and refusing to compromise their principles, they should be encouraged in their efforts demonstrate what can be accomplished using clearly free software.
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
While I can understand the fuss about binary-only drivers, I think embedding firmware code should be allowed. It should be seen as data needed to initialize the device in a workable state. I think there's no difference between only a few bytes written to some registers, or a whole firmware download. Including that firmware in the GPL code will allow others to use it in their modified drivers. The manufacturer could have put the firmware in an onboard ROM, but chose not to, so the firmware could be easily upgraded in case of bugs. Once the firmware code is stable, it will probably not change anymore anyway.