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.
GCC, for example, requires bison to compile it. GCC ships with both the source grammer files and the compiled grammer file.
Which is fine. There's nothing wrong with shipping the output file so long as the original source is shipped as well. Of course it's still not strictly GPL compatible if you can't freely obtain the entire toolchain required to build it (and have that provided on request) but such is life.
Most people don't need to use the source, but if there's a bug you need to fix then that source needs to be available so you can fix it.
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 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.
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
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
Yeah, we Debianers usually screen our hardware before shopping...
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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.
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.
It didn't even garner a simple majority.
Even if the vote passed you still would have been able to install non-free software on your debian machine, you just wouldn't be able to install it from debian or a debian mirror. Kind of like the blackdown java packages right now.
Frogs are primitive animals - so the occasional extra toe is not that unusual. But this is very unusual.
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?
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.
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?
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.
You need to learn about the various types of intellectual property recognized in law. Product names can be protected through trademarks, specific expressions of ideas can be protected through copyrights, and ideas themselves can only be protected through patents. Each type of intellectual property has its own set of laws and regulations which govern it. Issues involving the GPL fall under the category of copyrights.
In your comment you use the word information, which by itself has no legal meaning. Assuming you intended to ask about the expression of a program through its code, or an artistic expression of a corporate logo, then the answer is that the redistribution of such expressions can be restricted through copyrights. The owner of the copyright gets to decide conditions under which their work may be distributed to others. If anyone fails to honor those conditions, they have no legal right to continue distributing the copyrighted material. The GPL establishes a simple set of conditions under which software covered by a GPL license may be distributed, and everyone has the option of either abiding by those conditions or not incorporating software covered by the GPL in their products.
Debian's position is that including software components in the kernel without making available their source code violates the GPL requirements of other components in the kernel. Given this interpretation, their only available options are to stop distributing the GPL parts of the kernel, or stop distributing the non-GPL-compliant components. Not surprisingly, Debian has decided to strictly adhere to GPL requirements with regards to the kernel it distributes.
It's hard to get what your point is when you consistently blur the real distinctions between the different types of intellectual property. You said "While pentium is a trademark, the graphic logo is copyrighted. Neither is free to modify and redistribute and thus a violation of 'free software' "
For one thing, the word "Pentium" and the Intel graphic logo are both trademarks for Intel. No software license, especially the GPL, gives anyone the right to modify or use someone else's trademark. Also, there is no restriction on redistribution of a trademark, so long as it is made clear who owns the trademark and there is no confusion elicited in viewers about what it is representing. Your example plainly does not show an example of a violation of the GPL.
Second, there is no single definition of the term "free software" as you use it. There are only specific licenses, each of which has its own conditions, which fall under the wide umbrella of free and/or open source software. Before you can discuss a violation, you have to specify exactly which license you believe is being violated.
Third, you ignore the plain difference between a binary file representing executable code (even if it runs only on an embedded processor within a device) and a binary file representing a static image. The binary executable represents a program, which during the course of its execution may effect the state of the computer system within which it runs. It will likely effect the state of the kernel which contains the driver which accesses the firmware. Without the natural expression of this firmware, its source code, it is difficult to really understand what those effects will be under all conditions. The static image file would have no indeterminate effects on the system. Contrary to your unsupported assertion otherwise, since the graphic image is fully described by the binary contents of the file, that file can be considered a definitive source format.