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.
Although removing any possible licensing issues is a good thing, this will only hurt Debian. People simply expect their hardware to work, without having to jump through massive hoops. Requiring full source code only makes certain hardware harder to get working, and does not contribute to the adoption of Linux. Now that RedHat is mostly focusing on the enterprise market, there has to be another distro to take its place (Fedora is still in its infancy), and Debian will soon not become that distro.
US businesses that currently accept chip and PIN/signature
I see this as a similar problem with Lex/Yacc based applications. GCC, for example, requires bison to compile it. GCC ships with both the source grammer files and the compiled grammer file. Yes, I call the .c file compiled because it is an output file. That way, GCC can be compiled without having to have bison installed.
This is a boring sig
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?
This is usually firmware for a device connected to the pc.. .. Why ?
Do we really need the sourcecode for it ?
And where does this stop ? Should we not install linux
on computers with a non open source BIOS ?
What about devices with firmware already loaded and where it need not
be loaded by a driver from an OS, should we "ban" those as well ?
"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.
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.
Firmware is not "linked" with the kernel driver. Why would it be a problem for the kernel driver to load it?
Sorry, but I think this is a bad decision. Yes, it would be nice to have sources for more firmware available, but that doesn't strike me as a battle worth fighting right now and it doesn't strike me as something that the GPL requires. And Debian hardware support is iffy enough as it is relative to other distributions.
Of course it's hard to grok. Remember your audience. How many times have people played lawyer on this board...and got it wrong? Freedom is about laws, and laws aren't like code. Debian and others realize that. Now why can't the Slashdot crew realize that?
All this because we don't want to play by OSS rules, but CS (Closed Source) rules. You'd think the whole SCO affair would have taught people something, but apparently we'll have another round with MS and Mono, to drive the lessons home. You play by other people's rules, then they can have dominion over you(1). You get them to play by your rules and...well you have OSS taking over the world. Live and learn people, hard way, or easy way. It's your decision. Just don't drag the rest of us down with you.
(1) And to belabour the obvious. Binary drivers is playing by someone elses rules. They have your money, remember.
The hurts Debian argument is a false one. What's going to happen? Is Debian going to go out of business? You'd think after all these years that people would realize what Debian stood for? Issues like this have been raised before, and dealt with by Debian (hell, I believe the whole QT issue got it's start with them, not RedHat). I guess some people never learn.
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.
I think Debian has done a good job handling issues like this in the past. For example, when using apt you have the CHOICE to include non-free software if you choose, and it is just as simple as including free software, if they are able to make it as easy to use as they have for the free/non-free choice this will essentially be a non-issue.
It reminds me a bit of how Gentoo operates with Java, when you install it, emerge (apt for Gentoo) tells you to go and grab this file and put it here. That way you can easily install, yet they stay true to their principles.
Ah yes, pragmatism. The thing we adopt when we have no stomach for idealism. Or to look at this from the other end. Idealism is the thing we adopt, when we can't stomach the consequences of our pragmatism.
Which do you thing will last the longest?
this is the best summary of the question I have read... pls squiggleslash, post it to debian-legal!
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I kid you not, the Debian Weekly News has several times included discussions about dropping "non-free" entirely.
This is something I personally consider a bad idea, as a long time Debian user. As dcocos says, just make it available explicitly as non-free the same way the nvidia drivers are now.
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics
If it is a few hardware devices then it wont be a huge issue to debian users. But if suddently all wireless devices stop working ( probably overkill ) then what will be left? Replace wireless devices with your favorite hardware device that may stop working. I hope he puts out a list of all things that will stop working or will require users to do more in their configs.
Only 'flamers' flame!
Does slashdot hate my posts?
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!
I see the reasoning for this, but is it practical?
What happens if the card has an embedded controller that uses an architecture that isn't easily compiled by gcc or something?
What do you do then?
Obviously is keep it precompiled.
This, while good intentioned, I can see breaking a lot of things which aren't really purposefully breaking a lot of things without easy solutions.
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.
"The problem here is that using binary garbage is against the spirit of the GPL."
The issue is whether GPL'd products can contain binary-only non-GPL'd products.
Does GPL override it by 'distribution' or only associate. Richard thinks that anything shipped with a GPL'd product becomes, by proxy, GPL'd.
To mix the two does not violate either the spirit or letter of the GPL any more than enjoying having sex with your wife violates the marriage commitment.
However, if the GPL can extend beyond it's borders by proxy or in actuality, then it becomes an oppressor of rights.
Frankly, your shaming of software that does not abide by your licensing concept amounts to an attempt to curtail my freedom as a developer. That does not in any way empower me under the "spirit" of the GPL.
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.
When the code with a different license is distributed within an otherwise GPL source file I think it is clear that the resultant GPL+non GPL single file of code is a derived work.
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?
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.
It certainly seems a reasonable (to me) limitation that I can't call my new CPU the "LinuxPentium" or "Pentium X". If however I got the name from a GPL product it is a restriction on the use of information in the distribution.
If it is OK to restrict information...
Is a chunk of hardware specific firmware information or code?
Do we even know that it is the code and not the graphic logo to display at boot time for example?
Do we need to?
In my opinion it does not hurt Debian. Debian represents de ideas and convictions of Free Sorfware Fundation and GNU movement. Debian Distribution is for experts and people who believe in GNU convictions (read Debian Policy), for that reason Debian has to represent GNU/Linux vanguard according with their policy. If you think that it is not correct you would probe another distribution. Debian is bigger than an distribution. Debian is a movement.
It's about time a linux distro stop pandering to hardware providers and demand they start thinking open source. It's a ballsy move, lets see where this goes...
I don't see violent or extravagant writing there. I see thoughtful analysis which ties together the issues of leaving out credit for GNU, choosing Bitkeeper over free software replacements, and ending up with a kernel which is itself non-free but is ironically commonly taken as the symbol of the free software movement. These issues are related because the thought that leads from dismissing software freedom will give rise to encouraging people to make choices based on technical efficiency instead of software freedom, thus resulting in becoming dependant upon software that is not completely free.
Nowhere in the article do I see Bitkeeper described as "evil" and nowhere in your summary do I see you justifying your inaccurate description of RMS' words. To me, it's telling that this article is over a year old and yet we're still seeing the same profound shortcoming--the most popular variant of the OS built to be free includes non-free software.
Digital Citizen