Your analogy would make sense if there was a free software replacement for these firmware blobs. Since there isn't, the options are "binary firmware" or "brick". There is no question as to what sort of software to put on these devices, since there is only one option.
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)
[Link]
I'm pretty sure the line is drawn between ROM (permanent storage) and EEPROM (field-programmable storage) rather than between EEPROM (non-volatile programmable storage) and RAM (volatile programmable storage).
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 21:57 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257)
[Link]
So wait. If the logic is hardcoded, but you cannot get the circuit schematics, that's fine? Why not insist that *every* logic gate must be published in order to be "free"? If an opaque firmware blob is distributed via the internet, rather than via an EEPROM on the device itself, what difference does it make to "freedom"?
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 7:27 UTC (Tue) by jmm82 (guest, #59425)
[Link]
plus 1 for this comment.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 18:20 UTC (Tue) by jebba (✭ supporter ✭, #4439)
[Link]
So this stuff in the linux-2.6.xx.tar is just fine with you? Anyone suggesting they be removed is just playing politics?
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?
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 19:21 UTC (Tue) by sfeam (subscriber, #2841)
[Link]
So this stuff in the linux-2.6.xx.tar is just fine with you? Anyone suggesting they be removed is just playing politics?
Yes, on both counts.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 19:31 UTC (Tue) by jebba (✭ supporter ✭, #4439)
[Link]
> while the rest of us will continue to use a distribution that actually runs on the machines we use.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 18:04 UTC (Wed) by nye (guest, #51576)
[Link]
I don't really understand what 'found in hex form in the kernel source' actually means - are these sections extracted from drivers of entirely unknown provenance? Why would they not be licensed in the same way as the containing code, which presumably is considered legally sound?
(I'm not asking rhetorically BTW; I'd just like to see some clarification of how this situation came about.)
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 20:40 UTC (Wed) by jebba (✭ supporter ✭, #4439)
[Link]
> I don't really understand what 'found in hex form in the kernel source' actually means - are these sections extracted from drivers of entirely unknown provenance? Why would they not be licensed in the same way as the containing code, which presumably is considered legally sound?
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.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 15:25 UTC (Thu) by nye (guest, #51576)
[Link]
>The firmware can't be under the same license (GPLv2) because no source code is provided for the firmware.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 20:37 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257)
[Link]
Ah, but that is a copyright issue, and that, as far as I can see is *not* the topic of debate here. The kernel developers should obviously be concerned with clarifying and keeping clear the distinct copyright of the firmware (which moving into a separate directory, or tarball, may help). I think most everyone can agree on that. The issue really being discussed is that these binary firmware blobs represent non-free "taint" of the system/hardware in use, not the kernel itself. Hence, being "baited" into using "proprietary" hardware, even if the kernel drivers themselves are free.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 4:00 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
Baiting is inducing, allowing means not standing in the way. There's a fundamental ethical and moral difference in there.
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
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 4:44 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
[Link]
These fishing analogies you keep using really aren't the best metaphors, imo. Can you phrase it in terms of sports or movies?
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.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 4:56 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
I don't see that their offering you the ability to make calls at emergencies justifies or legitimizes their depriving you of your freedoms. The ability to make calls is still a way of luring you to give up your privacy and your freedom (there's a reason why these tracking devices are called *cell* phones :-) So, thank them for what you're grateful of, but also complain and use your freedom and power of choice to demand respect. Don't let the bait buy your silence or make you complacent.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 6:45 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
[Link]
I want your pledge that when one of the providers of these firmware blobs has said, "Fine, here's the register interface to the custom chip we built, feel free to write your own firmware.", you'll refuse to use them until they also provide the VHDL files they used to create it. Because *clearly* there can be no design firewall that you don't deem as an affront to your freedom.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 7:28 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
Wait a minute! You're thinking of firmware as pure configuration data, with a few dozens of registers set to a certain fixed values so that the device does the job it was designed to do? That's is not what this is about! That's not non-Free Software, it doesn't even qualify as software!
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.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 8:09 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
[Link]
I'm not sure why you chose to interpret my statements that way. I said elsewhere, for example, that a distinction must be made between firmware blobs that run outside of the kernel (ie. on processors not running Linux), and binary driver blobs which run in kernel space. So I, and others, are aware that the firmware blobs represent code and running programs. Not just "configuration data".
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...
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 18:35 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
> I'm not sure why you chose to interpret my statements that way
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!
Freegards, ;-)
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 18:26 UTC (Mon) by lxoliva (subscriber, #40702)
[Link]
Whether or not a replacement exists is orthogonal to whether the code in question is Free or not, right?
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.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 19:30 UTC (Mon) by cesarb (subscriber, #6266)
[Link]
> As to whether non-Free code on flash memory is ok, I wonder where you got that idea from the announcement.
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).
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 20:34 UTC (Mon) by lxoliva (subscriber, #40702)
[Link]
I'd go further than pushing blobs out of the tree: drivers that require non-Free firmware should be kept out, so as to put pressure on the hardware suppliers to respect users' freedom.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 20:35 UTC (Mon) by foom (subscriber, #14868)
[Link]
> 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.
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.
This should be considered exactly as bad in terms of user freedom, except for two things:
- 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.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 20:57 UTC (Mon) by lxoliva (subscriber, #40702)
[Link]
It looks like you are mistaking FSFLA for a subsidiary of the FSF or some such, but it's an independent organization.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 14:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
"Whether or not a replacement exists is orthogonal to whether the code in question is Free or not, right?"
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.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 18:30 UTC (Tue) by jebba (✭ supporter ✭, #4439)
[Link]
> 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.
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.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 19:22 UTC (Tue) by dlang (✭ supporter ✭, #313)
[Link]
how can you tell the difference between a binary blob that is a large data table and a blob that is code that will be run on an embedded cpu?
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 19:47 UTC (Tue) by jebba (✭ supporter ✭, #4439)
[Link]
> how can you tell the difference between a binary blob that is a large data table and a blob that is code that will be run on an embedded cpu?
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.
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 2:26 UTC (Wed) by lxoliva (subscriber, #40702)
[Link]
In the general case, that's not possible. The procedure I use starts with a sniff test, looking for regularity in the sequences of numbers or trying to make sense of them from their given names, numbers and the way they're used. If I can't determine it's just data, or find strong indication that it's code, I try to get ahold of the driver maintainer or the hardware designer. Ultimately, I have to go by whatever info I get and a sense of trust for whoever provides it and, in the worst case, make a conservative assumption that it may be software (instructions to configure a general-purpose computer to behave in a certain way) or a mix of software and pure data, and go with that.
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 2:33 UTC (Wed) by lxoliva (subscriber, #40702)
[Link]
In the general case, that's not possible. The procedure I use starts with a sniff test, looking for regularity in the sequences of numbers or trying to make sense of them from their given names, numbers and the way they're used. If I can't determine it's just data, or find strong indication that it's code, I try to get ahold of the driver maintainer or the hardware designer. Ultimately, I have to go by whatever info I get and a sense of trust for whoever provides it and, in the worst case, make a conservative assumption that it may be software (instructions to configure a general-purpose computer to behave in a certain way) or a mix of software and pure data, and go with that.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 6:23 UTC (Tue) by coriordan (guest, #7544)
[Link]
> the options are "binary firmware" or "brick"
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.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 6:51 UTC (Tue) by dlang (✭ supporter ✭, #313)
[Link]
but that's not what you or the FSF are saying.
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)
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 11:17 UTC (Tue) by kevinm (guest, #69913)
[Link]
Exactly - to turn coriordan's example around, it would have been like saying back in the 80s: "... but if you want to burn the OS into ROM instead of loading it from disk, that'll be fine."
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 15:13 UTC (Tue) by RobSeace (subscriber, #4435)
[Link]
Indeed, and I actually had an old Tandy 1000HX that had DOS (2.something, I think)
burned into ROM, so it needed no disks (floppy or hard) to boot... Was that
somehow acceptable from FSF's POV, or actually superior to being able to load
any OS one wanted via disk (merely because the disk happened to ship with DOS
on it by default)? If so, I think they've gone completely off the deep end...
But, if not, they're being hypocritical regarding this "binary blob" situation...