Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
If I take Windows 95 off my computer, it's also like a brick.
That is, until I put some new software on it.
The question is about what sort of software to put on these devices, and FSFLA is saying we should put free software on them. The default Linux kernel is unfortunately taking the other side.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 16:38 UTC (Mon) by cesarb (subscriber, #6266)
If there was a case where you had both non-free firmware and free firmware for the same hardware, and the Linux kernel developers rejected the free firmware on non-technical merits (they will not accept it if it is buggy crap that crashes all the time or introduces a security hole), then you would have a point. I know of no case where that happened.
Not to mention that the whole argument is a bit bizarre. Non-free binary code on flash memory within device = OK; the exact same non-free binary code running on the exact same device but uploaded from the operating system = not OK? Either both are wrong or neither is, since it is the exact same code running in the exact same place doing the exact same things. The only difference being where it is stored while the device is powered off.
Posted Nov 8, 2010 16:45 UTC (Mon) by mpr22 (subscriber, #60784)
Posted Nov 8, 2010 21:57 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257)
Posted Nov 9, 2010 7:27 UTC (Tue) by jmm82 (guest, #59425)
The only people in the world who care about this are the 10 people on LWN who are trying to push their politics. 99.99% of the world does not know this exists until their wifi diver breaks because the fsf was trying to prove a point. Now they have to find the correct firmware out of tree and load it themselves. That is the kind of stuff that scares away new users.
I love Linux, open source, and playing with my hardware, but in the end I would prefer my hardware works.
Posted Nov 9, 2010 18:20 UTC (Tue) by jebba (✭ supporter ✭, #4439)
Licence: Unknown, File: korg/k1212.dsp
Licence: Unknown, File: ess/maestro3_assp_kernel.fw
Licence: Unknown, File: ess/maestro3_assp_minisrc.fw
Licence: Unknown, File: yamaha/ds1_ctrl.fw
Licence: Unknown, File: yamaha/ds1_dsp.fw
Licence: Unknown, File: yamaha/ds1e_ctrl.fw
Licence: Unknown, File: kaweth/new_code.bin
Licence: Unknown, File: kaweth/new_code_fix.bin
Licence: Unknown, File: kaweth/trigger_code.bin
Licence: Unknown, File: kaweth/trigger_code_fix.bin
Licence: Unknown, File: ttusb-budget/dspbootcode.bin
Licence: Unknown, File: intelliport2.bin
Licence: Unknown, File: vicam/firmware.fw
Licence: Unknown, File: sun/cassini.bin
Licence: Unknown, File: e100/d101m_ucode.bin
Licence: Unknown, File: e100/d101s_ucode.bin
Licence: Unknown, File: e100/d102e_ucode.bin
Licence: Unknown, File: acenic/tg1.bin
Licence: Unknown, File: acenic/tg2.bin
Licence: Unknown, File: qlogic/isp1000.bin
Licence: Unknown, File: myricom/lanai.bin
I think *all* of those were "Found in hex form in the kernel source". Is that OK? Should we add another few hundred? Or better to remove?
How about these?
Licence: (C) F6FBB 1998, File: yam/1200.bin
Licence: (C) F6FBB 1998, File: yam/9600.bin
"Found in hex form in kernel source". You sure that file is redistributable? What about the others?
Posted Nov 9, 2010 19:21 UTC (Tue) by sfeam (subscriber, #2841)
If someone is self-motivated to do the work to split them out into a separate directory tree, whether in the cause of ideological purity or for other reasons, that's also just fine with me. If they then take the next step of removing them altogether in order to fork and distribute a less functional kernel - well, I think that's very foolish but ultimately harmless. That small number of people who feel that their karma is increased by following this route to ideological purity will cheer, while the rest of us will continue to use a distribution that actually runs on the machines we use.
What's not "just fine" with me is to actively hinder the continued improvement and popularity of linux by imposing unnecessary hurdles to adoption. The FSF is IMHO guilty of this many times over; the FSFLA rather less so. Leading by example is a good thing. So while I am dubious that a large community will gather behind the banner of linux-libre, I wish them well. By contrast the FSF seems to have lost it's way entirely. They are admonishing rather than creating, and proselytizing rather than leading.
Posted Nov 9, 2010 19:31 UTC (Tue) by jebba (✭ supporter ✭, #4439)
Really? Do you need any of the above firmware on your machine? Still hanging on to that 1998 sound card?
Boot up a -libre kernel and see if it works. Perhaps your system *can* run a kernel with non-free software removed.
Posted Nov 10, 2010 18:04 UTC (Wed) by nye (guest, #51576)
(I'm not asking rhetorically BTW; I'd just like to see some clarification of how this situation came about.)
Posted Nov 10, 2010 20:40 UTC (Wed) by jebba (✭ supporter ✭, #4439)
Well, taking the first one on the list as an example, it appears so. The firmware was found at sound/pci/korg1212/korg1212-firmware.h and moved into firmware/. I tried to find where it was added in Linus' git and in the history.git but I can't see where the file was actually added. Most of the ones above are pretty ancient. The firmware can't be under the same license (GPLv2) because no source code is provided for the firmware.
Posted Nov 11, 2010 15:25 UTC (Thu) by nye (guest, #51576)
Ah, right. So the issue is that the 'source' initially available actually included binaries in textual form, making that source GPL incompatible, and the combined work thus (potentially) non-redistributable.
That makes sense (in a sigh-inducing, twisted sort of way :P) - thanks for clarifying.
Posted Nov 11, 2010 20:37 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257)
It doesn't fly, at least not the part about accusing the Linux developers of complicity in "baiting" us into using non-free firmware. It would be similar to faulting Linux for allowing me to run a user-space binary that isn't "free". Should the kernel developers now be chastised for "baiting" us into using things like Matlab or Photoshop? Ridiculous, and FSFLA should be ashamed for framing their argument in such accusatory terms.
Posted Nov 12, 2010 4:00 UTC (Fri) by lxoliva (subscriber, #40702)
Consider smart fish, and scenarios in which one fish sees another going for a piece of food, that may or may not be bait around a hook.
1. the first fish knows it's bait around a hook, or in a trap
1.a) the first fish says there, go for it!
1.b) the first fish gets in the way and says hey, that's bait, you'll get trapped, you sure you want to?, so the other fish, if still decided to take the bait, has to take a detour to get to it
2. the first fish can't tell whether there's a hook or a trap, so it says nothing and doesn't stand in the way
Posted Nov 12, 2010 4:44 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
Or better yet, drop the analogies, since we aren't children; this is our field, we basically understand the scenario. Are cellphone technology providers to be chastised for "baiting" me into use one, while not providing free/libre firmware (even if the the OS is free), or are they to be thanked for allowing people to be able to call an ambulance when they are having a heart attack on a camping trip? I'll take the freedom to survive in that scenario.
If the firmware blobs are a copyright problem, by all means say so plainly. But to state that the Linux developers have set a trap for users, is low.
Posted Nov 12, 2010 4:56 UTC (Fri) by lxoliva (subscriber, #40702)
I'm not concerned with the copyriht issues. They're just a distraction. Even if there was no copyright issue whatsoever, the blobs would still be non-Free Software (i.e., software that deprives users of their four essential software freedoms), and inducing people to accept them is socially harmful practice that proponents of software freedom had better not engage in.
Posted Nov 12, 2010 6:45 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
Posted Nov 12, 2010 7:28 UTC (Fri) by lxoliva (subscriber, #40702)
The blobs we're talking about contain machine instructions that run on actual computers. Many of them are regularly modified fixing errors or even adding features. Some implement anti-features. You remember when Linux fit in a single floppy disk, and with a couple of floppy disks you could have an entire functional Free GNU+Linux operating system? Some of the blobs we're facing these days wouldn't fit in one of those floppy disks! They're entire operating systems for the computers hiding inside our computers, often hiding from you their true power.
Please help us (re)conquer freedom in that field! Don't let the expanding meaning of firmware fool you.
Posted Nov 12, 2010 8:09 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
Whatever. You don't appear to be responding to my points. Fair enough. A campaign to publicize the problems with binary code in the form of firmware blobs is perhaps a good one. But the way you go about it seems all wrong to me. It's kind of like PETA. A core part of their message (let's treat animals humanely) is pretty sane and agreeable. And yet they go about promoting it like complete dicks. I've stopped being a strict vegetarian, in very small part, because I didn't wanna end up like those kooks. I hope the same doesn't happen to my attitudes about Free Software...
Posted Nov 12, 2010 18:35 UTC (Fri) by lxoliva (subscriber, #40702)
Because the register file interface is hardly enough to write the software to run on the embedded computer, but it would likely be plenty to configure a device whose firmware is just configuration data.
Now, perhaps the VHDL description would be desirable to have, but if the embedded device contains a general-purpose programmable computer, having a description of its ISA would come in handier than the VHDL description for the purposes of writing the software to run on it.
Thanks for your apparent support to the campaign. If you can find better ways to spread the message, by all means go for it, and be sure to let us know!
Posted Nov 8, 2010 18:26 UTC (Mon) by lxoliva (subscriber, #40702)
The presented argument is a false dilemma. The short-term options are indeed blob or brick, but the long term options are blob, brick or freedom. Clever use of your freedom (and power) of choice will bring us all freedom, because hardware suppliers ultimately want to sell their stuff. Unwise choices will lead to progressive erosion of freedom, with more blobs controlling more parts of our computers.
As to whether non-Free code on flash memory is ok, I wonder where you got that idea from the announcement. If it's there at all, it was my mistake, and I'd very much like to correct it.
Posted Nov 8, 2010 19:30 UTC (Mon) by cesarb (subscriber, #6266)
I did not see it on this announcement, but I recall seeing it on other related discussions (that somehow it was better for wireless cards to have flash memory with their firmware instead of saving some cents and pushing the firmware storage into the driver). I think it is better that the code is free no matter where it is stored; it being distributed within the hardware itself, on a CD on the hardware's box, on the firmware tree, or on the main kernel tree, should not make a difference. I would prefer to avoid the main kernel tree only to avoid a very small possibility of confusion (the kernel being GPLv2 except for one small directory can be confusing, since most people would expect it all to be GPLv2; the separate firmware tree makes things more obvious).
> Clever use of your freedom (and power) of choice will bring us all freedom, because hardware suppliers ultimately want to sell their stuff.
Yes, but there is also the other side: users want to use the stuff they bought. If you do not have many users, your ability to put pressure on the manufacturers is much weakened. What you need is to put pressure on the manufacturers without driving away the users. I believe the way it currently works with drivers goes in that direction; if your driver is not on the upstream kernel it is a second-class citzen, subject to breaking every single kernel release, and to get into the upstream kernel it has to be GPLv2 or compatible. What we need is something like that but for firmware (which is completely separate from the drivers, since it even runs on a separate chip, so the "it is a part of the kernel thus it must be GPLv2" argument does not work).
Posted Nov 8, 2010 20:34 UTC (Mon) by lxoliva (subscriber, #40702)
Of course, none of this would prevent distros from going the Free Bait way, or users who already took the hardware bait from building and using the drivers themselves, possibly with help from other victims.
Posted Nov 8, 2010 20:35 UTC (Mon) by foom (subscriber, #14868)
It's implicit in how the FSF is not campaigning against non-free firmware on flash memory shipped with devices, but they are against non-free firmware that users have to upload themselves every time the device is booted.
The practical effect of making it difficult to use uploadable non-free firmware with linux is that users may instead purchase hardware which has the non-free firmware stored in flash memory on the device.
- Now you probably can't even upgrade your firmware without installing non-free Microsoft Windows and a non-free firmware flashing utility, as well as providing the non-free firmware.
- Permanently-stored Flash firmware has a greater chance of being verified by a cryptographically secure signature mechanism, ensuring that it is even more difficult to make a free replacement.
It's a total lose.
Posted Nov 8, 2010 20:57 UTC (Mon) by lxoliva (subscriber, #40702)
That said, there is *some* overlap in the shared opinions of all members of the FSF network, and there's also some difference between the opinions held by organizations and individuals. For clarity, what follows is my personal opinion.
Hardware circuits can't be modified by the users, but they don't generally present the ethical issue of creating artificial barriers for users to exercise this freedom, that non-Free Software on programmable computers generally does.
Programmable computers hidden inside hardware devices carry this ethical problem, but then a question that arises is, whose freedom is on the line. Say, if a hardware designer chooses between a hardware circuit and programmable non-volatile memory, the presented interface to the user is exactly the same, so one could argue it's within the hardware designer's freedom, in much the same way that say a service provider can decide what tools to use to perform a job s/he was hired to perform.
Now, the moment the service provider tells the user I need you to provide me with $whatever so that I can do the job, the user-visible interface changed, and now the user takes an active role in the process. When it comes to user-uploadable blobs, tt becomes perfectly clear that there is a programmable computer in there, and the only reason the user can't control it is because of the unethical imposition by the hardware designer, who's shifting costs to third-party distributors.
That's why I perceive the latter as a more serious offence, but I don't entirely dismiss the issue of hardware with non-volatile memory, or even hardware circuits. Denying access to specs that would enable users to copy and adapt the hardware (it's getting closer to possible), know in detail what it does or doesn't, verify that it is so, and adapt it so it does what you wish, are not quite the issues that the Free *Software* movement deals with, but there are similar ethical issues in there, and they are getting more relevant as they approach the realm of the possible.
So, even though uploadable non-Free firmware is a present problem, I keep the hardware-related freedoms on sight, for I consider them worth fighting for.
Posted Nov 9, 2010 14:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Our device requires a binary blob to operate. However, it's not code, but rather large data tables compiled using a proprietary tools from VHDL hardware description.
What would you achieve by getting the source? Exactly nothing. You can't modify VHDL since you probably lack a fab to manufacture the resulting schematics. You can't even recompile it, because it requires a proprietary tools (working only on Windows, alas).
So firmware blobs should often be thought as a part of hardware rather than software.
Posted Nov 9, 2010 18:30 UTC (Tue) by jebba (✭ supporter ✭, #4439)
I may be mistaken, but I think in those cases, the blobs are left in linux-libre. If I knew which driver in particular you were talking about, I could look it up.
Posted Nov 9, 2010 19:22 UTC (Tue) by dlang (✭ supporter ✭, #313)
Posted Nov 9, 2010 19:47 UTC (Tue) by jebba (✭ supporter ✭, #4439)
Personally, I can't; I defer to lxoliva on that. He has a script that he runs against the kernel that has an accept whitelist for code that looks like a non-free blob, but is ok. See:
An example would be something like this: drivers/input/keyboard/atkbd.c which has a blobby looking table, but is ok.
Posted Nov 10, 2010 2:26 UTC (Wed) by lxoliva (subscriber, #40702)
Posted Nov 10, 2010 2:33 UTC (Wed) by lxoliva (subscriber, #40702)
Posted Nov 9, 2010 6:23 UTC (Tue) by coriordan (guest, #7544)
Those were also the options in the 80s for computers. A bunch of people decided that neither was acceptable, and now we have a third option: free software.
When we tell device manufacturers that blobs are acceptable, we get blobs. We need to say loud and clear that we won't accept blobs.
Posted Nov 9, 2010 6:51 UTC (Tue) by dlang (✭ supporter ✭, #313)
you are saying that blobs loaded by drivers are not acceptable, but devices that contain the exact same blob in ROM or flash are acceptable (although, if the flash can be modified from the OS, the FSF may change and say it's no longer acceptable, but if it requires some special cable to plug into the board it is just as acceptable as ROM)
so something that nobody can change is accpetable, something that can be changed, but you don't have documentation on what is in it is not.
I (and many others) see the ability to load something in at startup time to be a step forward, it at least allows you to replace what was there once you develop an open replacement (and this has happened in a handful of cases)
Posted Nov 9, 2010 11:17 UTC (Tue) by kevinm (guest, #69913)
Posted Nov 9, 2010 15:13 UTC (Tue) by RobSeace (subscriber, #4435)
Posted Nov 8, 2010 16:40 UTC (Mon) by mpr22 (subscriber, #60784)
Posted Nov 8, 2010 19:07 UTC (Mon) by ewan (subscriber, #5533)
Posted Nov 8, 2010 19:48 UTC (Mon) by kirkengaard (subscriber, #15022)
"Help" that merely says "you made the wrong choice" is barely any help at all. "Help" that says "this is the choice you should have made" may be better, but isn't likely to be appreciated any more. Help that says "You made a choice that we don't have free support for yet, but here's what to do in the meantime," is much more likely to do The Right Thing in the long run. Especially if "what to do in the meantime" includes how to help change the situation. It says we're working on the problem (including you, now that you're with us), rather than suggesting that the problem will not be solved.
Posted Nov 8, 2010 20:04 UTC (Mon) by cesarb (subscriber, #6266)
For some reason, all this discussion reminds me of this webcomic: http://ninapaley.com/mimiandeunice/2010/08/11/advice/.
Posted Nov 8, 2010 23:14 UTC (Mon) by Zack (guest, #37335)
No, in my opinion ewan is correct. It should be made clear that the hardware manufacturer is the hostile party that is causing problems. Whether others want to shift the blame, and even others are willing to *take* the blame is something different.
>"Help" that merely says "you made the wrong choice" is barely any help at all.
If I understand the press release correctly, it is pointing out that the current appeasement strategy is not working, but is looking to be a slippery slope instead. It looks like it's not a matter of catching up with non-free software in the kernel and its presence declining over time due to replacing it with free equivalents. Non free components are increasing faster than they're being replaced.
So yes, for now users might have more functional devices in their computers, but those who feel that a larger market share will automatically lead to more pressure on hardware manufacurers are mistaken; it will only lead to complacency and too much commercial interests getting involved to ever reach the right percentage for a "big push" to take off before you've painted yourself into a corner.
"open core" (however ill defined it might be) might be a little far fetched at this moment, but it's not an illogical outcome if this process continues. And what is any FSF good for but pointing out the obvious, only to be ignored in the name of "pragmatism" ? It doesn't make them wrong though.
This is exactly what happens now, no?
Posted Nov 8, 2010 23:59 UTC (Mon) by khim (subscriber, #9252)
Help that says "You made a choice that we don't have free support for yet, but here's what to do in the meantime," is much more likely to do The Right Thing in the long run.
Yes, this is right thing to do (that's why I don't like FSF's idea that Debian is "unclean" since it includes non-free repository), but till now the message was "here is working thing - don't think about freedom, Ok"? I actually like the fact that firmware blobs are moving to separate repository (and in Debian they will probably marked "non-free"), but it means that people actually admitted that Linux is "open core" already - yet they don't like the consequences.
I don't see what the hoopla is all about. Yes, Linux is "open core" software. Yes, it is the problem and we should think about the ways to solve it. No, it's not the end of the world and no, it's not a reason to drop everything and switch to Linux-libre... just like the fact that Flash is proprietary is not a reason to stop visiting YouTube. But to say that this situation is "just fine"... I don't see how can you say that. If it's Ok for firmware blobs then why it's not Ok for nVidia drivers? And if it's Ok for nVidia drivers then why not for Flash? And if it's Ok for Flash then why not for ICC? And if it's Ok for ICC then why it's not Ok for MS Office?
People have different tolerance levels (witness huge amount of activity behind office suites and compare to stagnation of "free flash replacement" front), there are no absolute freedom and there are no absolute slavery - and it's just so happened that the mix usually described as "open code" includes Linux kernel - that's all.
Posted Nov 9, 2010 5:15 UTC (Tue) by gmatht (guest, #58961)
that's why I don't like FSF's idea that Debian is "unclean" since it includes non-free repository
If it's Ok for firmware blobs then why it's not Ok for ... MS Office?
Posted Nov 12, 2010 19:56 UTC (Fri) by lxoliva (subscriber, #40702)
What I find odd (but not really) is that people who accuse us of withholding useful information quite often also vehemently oppose sharing information that would cast the non-Free Software in question: they want things to just work, without informing the user of any problems.
I (obviously) don't agree with their stance, so here's an initial draft for a message that I think would be useful to display to users when a user-friendly system encounters a device that requires non-Free firmware or drivers to work:
We have found component FOO on your computer, and we're sorry to say inform you that, as of this release, it won't work on a wholly Free Software system. Here's why:
- the component designer does not provide you with Free Software (drivers or firmware) to operate this device
- the component designer does not provide you (or us) with enough information to write Free Software to make it work
- the component designer provides you with non-Free Software to run it, and so far we have not been able to reverse engineer it to develop equivalent software that respects your freedoms, at jurisdictions where the designer's hostile reverse engineering prohibitions are not enforceable
What you can do to fix this problem:
- if you're at a shop testing the computer or the peripheral device with Live media, keep your money and your freedom: don't buy it
- if you've already purchased it, try to return it for a refund, so that the hostile vendors who designed and selected this hardware component don't get the prize at your expense
- if you can't return it, try to find a replacement for the hardware component from a friendly vendor, and purchase it so as to offer incentive to vendors who respect you as a person, user and customer
- if you can't replace it, you may want to look at community support lists and web sites, maybe there are newer developments that can make it work in freedom
- if you don't find any, write to the hardware retailer, vendor and component designer to express your dissatisfaction, request a solution for the problem and let them and others in the community know how you feel about buying their products again.
You might find recommendations that involve installing non-Free Software provided by the vendors or from third parties. Please realize that those who offer you these recommendations may even think they're helping you, but in reality they're helping the hostile vendor keep you under control. We do not recommend or support the use of non-Free Software, for we find it harmful to you, the user, and to the community as a whole. Please remember this even if you decide to follow those recommendations, and keep them in mind next time you shop for a computer or try to help others.
Now, if at the end of this message, the installer wrote if you click on Ok, we will install the non-Free Software and make the device work for you, wouldn't you qualify it as highly hypocritical? :-)
Posted Nov 12, 2010 23:05 UTC (Fri) by mpr22 (subscriber, #60784)
Posted Nov 9, 2010 9:37 UTC (Tue) by nhippi (subscriber, #34640)
"Warning: We only provide support for %s on as-is basis. Due to licencing terms from %s we are unable to fix any problems you may have with it."
Non-preaching yet explains *why* non-free driver is bad for you as an user.
Posted Nov 8, 2010 19:32 UTC (Mon) by Lionel_Debroux (subscriber, #30014)
This is not to say that there _should_ be some work, somewhere, on replacing firmware blobs and proprietary drivers, though.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds