Weekly Edition
Return to the Front page
| |||||||||||||
Papering over a binary blob
Nobody likes binary blobs. When those blobs come in the form of firmware
for peripheral devices, though, it is probably fair to say that most of us
are able to live with their existence. Yes, it would be nicer to have the
source and to be able to create modified firmware loads, but, as long as
the firmware itself is distributable, Linux users usually do not worry
about it. That is not true of all users, though, as can be seen from an
effort underway in the GTA04 project.
GTA04 bills itself as the next-generation OpenMoko phone. The end product is intended to be a board that can fit inside an existing OpenMoko handset case but which provides a number of features the OpenMoko phone never had: 3G/HSPA connectivity, USB 2.0 on-the-go support, BlueTooth, an FM transceiver, various sensors (barometer, gyroscope, ...), and the obligatory flashlight device. Also provided will be a Debian port to make the whole thing work. The hardware design is reasonably far along, with boards from an early adopter program about to make their way to developers. There is, though, one nagging problem that the project would still like to solve. The GTA04 uses a Marvell 8686 "Libertas" chip for its WiFi connectivity; that is the same chip used in the first generation OLPC XO laptop. That chip requires a significant firmware blob to be loaded before it can function. One of the earliest bugs filed at OLPC called for the replacement of this blob with free software, but nobody stepped up and got the job done. So, five years later, the GTA04 project, whose goal is the creation of a 100% free handset, is stuck shipping that same firmware blob. Some projects would shrug their collective shoulders, treat the blob as part of the hardware, and move on to the long list of other problems in need of solution. Others might bite the bullet, get hardware documentation from somewhere, and write a replacement blob. Yet others might decide that Marvell's hardware is incompatible with their goals and find a different WiFi chip for their board. GTA04, though, has done none of the above. What the GTA04 developers would like to do is documented on this project page:
The task is to develop a prototype of a microcontroller that sends
an immutable firmware program through an SDIO interface into a
Marvell 8686 based WLAN chip independently from the main CPU. The
goal is to isolate the non-free firmware binary from the main CPU
so that it becomes effectively circuitry.
The architecture we want to use this with is a TI OMAP3 with a level shifter and a Wi2Wi W2CBW003 chip connected to it. Our idea is to use a MSP430F5528IYFF controller that sits between the OMAP3 and the level shifter so that either of the MCUs can control the SDIO interface and right after reset, the firmware is injected from the MSP430 into the Wi2Wi chip. In other words, the project proposes to add another microcontroller to its board for the sole purpose of shoving the firmware blob into the Marvell WiFi controller. By so doing, they turn the blob into "effectively circuitry" and, seemingly, no longer feel quite so dirty about it. The Free Software Foundation agrees with this goal, having apparently set it as a condition for their endorsement of the device:
The current thinking is that by removing the ability for this
software to be upgraded, we can effectively treat the wireless
networking hardware as a circuit, and importantly, not a malicious
circuit that can be upgraded.
One might object that, if the firmware blob contains malicious code, that code will still exist even if it does not pass through the CPU as data first. The GTA04 is meant to be a free device; the operating software will be under the user's control. So one would expect that the firmware blob will not be spontaneously replaced by something nastier. If the firmware blob were somehow able to maliciously "upgrade" itself against the will of the Linux system running the phone, it would be able to do any of a number of other unpleasant things regardless of which processor loads it into the WiFi controller. Meanwhile, if Marvell comes out with a new blob offering better performance or fixing bugs, users will no longer have the option of installing it on their phones. It is, in other words, hard to see the benefits that are being bought through this exercise. In fact, it would seem that the GTA04 project is wanting to saddle itself with a more complex design, higher hardware costs, less flexibility in the future and increased power usage to create a system that runs the exact same binary blob on the same controller. That's a high price to pay for the comfort that comes from having swept the blob under the rug where it can't be seen. This whole thing might be humorous if it weren't for the little fact that it would really be nice to see this project succeed; more freedom in this area is sorely needed. What they are trying to do is challenging enough without the addition of artificial obstacles. It will be a sad day if the pursuit of a truly free handset is impeded by an exercise in papering over an inconvenient binary blob. (Thanks to Paul Wise for the heads-up). (Log in to post comments)
Papering over a binary blob Posted Sep 29, 2011 0:15 UTC (Thu) by geofft (subscriber, #59789) [Link]
The Free Software Foundation has been remarkably good at endorsing things that deny users' freedom. Encouraging people to make their software unmodifiable is well in line with them withdrawing support for distributions like Debian that make it easy for the user to choose to use non-free software.
On the other hand, GNU manuals with immutable rants about funding free software (such that you cannot use even a sentence or a diagram from the manual in another free work, according to the license, without copying the rant) are fully free.
I'm proud to use a distribution (Debian) that's not afraid to have its own set of free software guidelines and call out FSF's for being dumb. I think it's dangerous, as we see here with OpenMoko, for the community to passively accept the FSF's leadership role, because it means that newcomers to the community won't think critically about what the FSF tells them is freedom. (Another good example is the FSF legitimizing copyright assignment.)
The other side of the story Posted Sep 29, 2011 13:03 UTC (Thu) by coriordan (guest, #7544) [Link]
(Skip to last paragraph for my thoughts on this article.)
FSF defends the four freedoms of free software, so it's only logical that they wouldn't endorse a distro that encourages people to install software that denies those four freedoms.
On GFDL, I mostly agree with you, but I still use the GFDL. I trust FSF to fix their licence some day (or make GPL4 a real software+docs licence). There's no other body that I'd trust to get it right in the long term.
As for your third paragraph, about FSF's statements not getting enough critical review? You must live on a different internet. :-) People somehow expect all perfection, all the time from FSF. How about commenting constructively instead of complaining about it as if it's set in stone?
...of course, it doesn't help that this article gives no time to FSF's reasoning. (Does FSF have an article that explains it?) I'm not well informed about this issue, but it seems obvious that firmware that's written to be upgradeable will have more extensive functionality. Non-upgradeable firmware would focus on doing the minimal stuff. Put another way, there are three types of software: non-upgradeable blobs, upgradeable blobs, and free software. If we say that we accept the second type, why would device manufacturers ever give us the last type? There's no point in asking for certain freedoms if you permit an infinitely big loophole. More and more stuff would just be migrated into the upgradeable blobs section and we'd just get some UI code.
Well, if we accept something is a twisted way... we still accept something... Posted Sep 29, 2011 13:24 UTC (Thu) by khim (subscriber, #9252) [Link] Put another way, there are three types of software: non-upgradeable blobs, upgradeable blobs, and free software. If we say that we accept the second type, why would device manufacturers ever give us the last type? Good question. But here we have another case: firmware from second class (very firmly in second class - it includes mini-RTOS) is accepted by pretending it's firmware of the first class (this binary blob was never intended to be fixed and unupgradeable; the only reason it's not updated is the fact that it's old one and thus almost unsopported). If we accept firmware of the second class by doing the hard work of crippling our devices and pretending it's firmware of the first class, they why manufacturers should bother with the last class?>
Well, if we accept something is a twisted way... we still accept something... Posted Sep 30, 2011 13:01 UTC (Fri) by coriordan (guest, #7544) [Link]
Ok, I don't have the answer to that :-)
I've made a page on the Libreplanet wiki for discussing this:
goals of the FSF Posted Sep 29, 2011 22:45 UTC (Thu) by pjm (subscriber, #2080) [Link] Although I have never seen this stated, I would guess that the notion of freedom that RMS and the Free Software Foundation are concerned with is negative liberty. According to this uninformed guess, they are not concerned with your physical ability to fly like an eagle or modify circuitry, nor do they see any moral importance in whether you have software that enables you to do this or that (gives you the freedom to do this or that, one might say) (so don't see loss of (proprietary) software as a consideration when weighed against ethical considerations), but are only concerned in what others forbid you to do, for example by restrictive licenses. Another freedom commonly not sought by those who value freedom is the freedom to remove others' freedom. This would explain why the FSF don't object to copyleft licenses, which withold the freedom to make the code proprietary or impose any other restrictions. I've never lived in the US, but I get the impression that it's common in the US to understand words like "free(dom)" and "liberty" along these lines, and this might be why I haven't seen the FSF explain the sorts of freedom it is or isn't concerned with. If anyone has any contacts at the FSF, then it would be good if you could encourage them to be explicit about this. It's very common for people to see FSF positions as illogical, because they aren't familiar with these sorts of distinctions among freedoms. I think if the FSF were to be more explicit as to the reasoning for some of these things, then I think people would give more weight to their positions.
goals of the FSF Posted Sep 30, 2011 4:56 UTC (Fri) by njs (guest, #40338) [Link]
I've seen the FSF/RMS criticized for many reasons, but I'm not sure I've seen them criticized for failing to explain their reasoning before...
goals of the FSF Posted Sep 30, 2011 9:43 UTC (Fri) by pjm (subscriber, #2080) [Link]
If you look just a couple of comments up, you'll see geofft writing "The Free Software Foundation has been remarkably good at endorsing things that deny users' freedom" and "call out FSF's for being dumb". Like all such comments that spring to mind, he doesn't exactly criticize the FSF for failing to explain reasoning, but does criticize them for being unreasonable.
I don't see anyone saying that the FSF never gives any reasoning. However, if you could point us to where they give reasoning for the situation described in the parent article, or more generally give reasoning for why it should be preferable to have logic in ROM or circuitry compared to upgradable software, or any of the issues that geofft or the author of the parent article apparently consider unreasonable, then that would be useful.
goals of the FSF Posted Sep 30, 2011 22:58 UTC (Fri) by ldarby (subscriber, #41318) [Link]
> However, if you could point us to where they give reasoning for the
> situation described in the parent article
See http://www.fsf.org/campaigns/free-bios.html
The FSF's stance is that it's unethical for a vendor to withhold the freedom to modify software from users. If it's physically impossible to modify it, then there's no ethical problem - it's the same situation as a product that doesn't have any firmware,
My take on all this is that that state of having no ethical problems is more important to this project than anything else, so to reach that they're removing their own ability to modify the firmware. That has to deserve the Ig Nobel prize in the field of Ethics...
goals of the FSF Posted Oct 2, 2011 19:28 UTC (Sun) by jzbiciak (✭ supporter ✭, #5246) [Link]
Yeah, I have to say that it's a rather tortured exercise, adding an artificial hardware restriction so that the now-modified hardware maps onto the convenient "ROM exception."
The opaque blob is already effectively read-only. Adding this little microcontroller to do the copying so that the main CPU never sees it didn't get rid of the blob. It just papers over the problem, as the article states.
goals of the FSF Posted Oct 3, 2011 8:10 UTC (Mon) by pbonzini (subscriber, #60935) [Link]
> The opaque blob is already effectively read-only.
That would be true only if the producer had lost the source code, or something like that. Otherwise, the producer _is_ restricting you from enjoying some of the freedoms it has. If the blob is "read-only" because the producer has no interest in updating it, that's actually an even worse situation because _you_ might have good reasons to update the blob and yet cannot do that.
goals of the FSF Posted Oct 3, 2011 8:52 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] Do these technical acrobatics with the microcontroller do anything about the fact that the manufacturer still has the source code and isn't sharing it? No. Why should these antics appease anyone's notion of "software ethics," then? When I said the blob is effectively read only, I mean it's unmodifiable by the end user. That's true whether it's a firmware blob on disk, bits blown in a ROM, or this technical charade that makes a blob that was once stored on disk behave more like bits blown in a ROM. The ROM exception in general just feels like a cop-out. "Oh, it's in ROM, so it's no longer software. It's OK to ignore it." What if the device has a test mode or ROM bypass that allows it to run the equivalent code from some loadable location? Now what? That ROM had source code somewhere, and there may be a way to execute a modified version of it on your end system even if you can't replace the ROM itself.
goals of the FSF Posted Oct 1, 2011 1:23 UTC (Sat) by njs (guest, #40338) [Link]
I doubt anyone at the FSF thinks that having logic in ROM is *better* than having it in upgradable software. But they want to have an endorsement that says "this device uses only free software", and that means that they need to define "free" and "software". This is a case where the device developers have decided that rather than making the firmware free, they will make it not-software.
I can't see any way to define "free software" that would let you avoid this kind of loophole. What would you do differently? The result is ugly, but at least it's clear that actually freeing the firmware would be a better solution, so the endorsement is serving its purpose of pressuring people to work on that. The FSF certainly has been always been willing to accept short-term inconvenience in maintaining a long-term emphasis on freedom.
goals of the FSF Posted Oct 4, 2011 0:08 UTC (Tue) by xilun (subscriber, #50638) [Link]
So software on a CD-ROM would also be not-software? Nonsense.
The limits of positive and negative Posted Sep 30, 2011 12:46 UTC (Fri) by coriordan (guest, #7544) [Link] I'm not sure that the categorisation positive/negative is useful here. Does FSF campaign for your positive freedom to modify software? Or for the negative liberty to prevent others from stopping you from modifying software? Kinda the same thing really. RMS addresses this at the start of his speeches: Free Software [...] is software that respects the user's freedom. What do I mean by this? Because it's never enough just to say "I'm in favour of freedom", the crucial issue is always: what are the essential freedoms that everyone should have? From One of RMS's usual free software speeches, March 2006. So it's not so much a question of having as much positive liberty as possible, or as much negative liberty as possible. The point is to have whatever freedoms are necessary to live in a society where everyone can and be friendly and helpful to each other and can make use of their skills to improve their quality of life.
The limits of positive and negative Posted Sep 30, 2011 13:13 UTC (Fri) by pjm (subscriber, #2080) [Link]
> Kinda the same thing really.
In the situation discussed in the parent article, the FSF advocates removing the positive freedom to upgrade software, while (at least in the FSF's eyes, using the argument that circuitry can be overlooked) increasing negative liberty. So this is an example where they are not the same thing, which is why it seems like a useful distinction to make. However, I welcome your attempt to provide a different explanation, which looks promising even if incomplete (see below).
> The point is to have whatever freedoms are necessary to live in a society where everyone can and be friendly and helpful to each other and can make use of their skills to improve their quality of life.
[Was there text missing between "can and", or is the "and" spurious?]
The first of those seems connected with negative liberty. The second (improving quality of life) seems more connected with positive liberty, but might be seen as being in conflict with the recommendation to prevent people from improving their quality of life by upgrading software.
Papering over a binary blob Posted Sep 29, 2011 0:37 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Stoopid.
First, if there's a rootkit in the current firmware then you're screwed. Permanently.
Second, if there's no rootkit in the current firmware but you still can reprogram the hardware then you are just as screwed as ever.
Third, if there's a hardware vulnerability then there's no way you'll be able to fix it by updating the firmware.
Papering over a binary blob Posted Oct 3, 2011 8:16 UTC (Mon) by pbonzini (subscriber, #60935) [Link]
That's the same thing you could say 25 years ago about putting your OS in ROM: "First, if there's a rootkit in the OS then you're screwed. Permanently. Second, if there's no rootkit in the OS but you still can reprogram the hardware then you are just as screwed as ever. Third, if there's a hardware vulnerability then there's no way you'll be able to work around it by updating the OS."
The microcontroller indirection is asking the vendor to put himself on the same level as their users. If the users cannot prepare updates, neither should the vendor. If the vendor can, so should the users.
Firmware is where a lot of interesting stuff happens for many network cards. Freedom of firmware is nowadays what freedom of OSes and drivers was when Stallman wrote the GNU manifesto. He won that front, why should he resign to vendors on this one?
Papering over a binary blob Posted Oct 6, 2011 15:11 UTC (Thu) by renox (subscriber, #23785) [Link]
> The microcontroller indirection is asking the vendor to put himself on the same level as their users. If the users cannot prepare updates, neither should the vendor. If the vendor can, so should the users.
How is-it "asking the vendor"?
Note that for the firmware of a radio HW, this could even lead your products to be banned..
Papering over a binary blob Posted Sep 29, 2011 0:39 UTC (Thu) by alankila (subscriber, #47141) [Link]
I think this approach can be properly be described by one word: paranoia.
It makes no sense, but people are doing it anyway. What a world.
Papering over a binary blob Posted Sep 29, 2011 8:55 UTC (Thu) by mpr22 (subscriber, #60784) [Link] Paranoia is a very good way to describe Marvell's treatment of its manuals, yes.
Papering over a binary blob Posted Sep 29, 2011 17:37 UTC (Thu) by Fats (subscriber, #14882) [Link]
But also how FSF is worrying how I am giving up my ultimate freedom; betraying the FSF cause by not seeing a problem in having free (as in beer) non-free code; or even non-free non-free code.
Papering over a binary blob Posted Sep 29, 2011 1:24 UTC (Thu) by ikm (subscriber, #493) [Link]
Here's a recipe to create a phone running Windows Phone 7 and being 100% free software at the same time: make WP7 firmware part of the circuitry.
You're making FSF's point Posted Sep 29, 2011 13:10 UTC (Thu) by coriordan (guest, #7544) [Link]
FSF's saying: give us the four freedoms for everything except what you're willing to put into non-upgradeable firmware.
No company in their right mind would ever publish a tablet with WP7 or any other entire operating system in non-upgradeable firmware, so FSF's policy is sound.
(And in your example, it still wouldn't be acceptable, since it would be "malicious" firmware.)
You're making FSF's point Posted Sep 29, 2011 13:46 UTC (Thu) by anselm (subscriber, #2796) [Link] No company in their right mind would ever publish a tablet with WP7 or any other entire operating system in non-upgradeable firmware Mobile handset manufacturers do that (in effect) all the time. What's the point of making upgrades theoretically possible if actual upgrades are never published?
You're making FSF's point Posted Sep 29, 2011 16:34 UTC (Thu) by iabervon (subscriber, #722) [Link]
It makes sense to exclude anything that the author of the software is willing to put into a non-upgradeable firmware. If Marvell had a firmware blob that they distributed for this purpose, it would make sense to go this route. If the project were able to develop such firmware under NDA and wouldn't be able to distribute the source, that would also make sense. But to take firmware that's designed to be upgradeable and install it in a non-upgradeable way doesn't make sense. The assumption with the FSF's position is that the entity making the hardware-equivalent device has a good reason to believe that it's okay not to be able to upgrade the firmware. It doesn't seem like GTA04 actually has a good reason to think this, other than not having much reputation to stake on the quality of their devices.
For that matter, while end users can't change the firmware, GTA04 can (by flashing the microcontroller differently before putting it on the board). Users can legitimately consider the firmware equivalent to hardware, but GTA04 really can't. If anything, the FSF should endorse users getting the resulting devices, but should not endorse GTA04 making them.
You're making FSF's point Posted Sep 30, 2011 13:24 UTC (Fri) by vonbrand (subscriber, #4458) [Link] I don't know. My daughter has an HP netbook than boots very fast (from ROM?) into a mini-environment (capable enough for web browsing, Skype, simple document editing AFAIU). So placing the OS into ROM isn't too far fetched nowadays. Google's ChromeOS points into that same direction.
Papering over a binary blob Posted Sep 29, 2011 2:04 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] And what happens if and when Marvell releases enough information to program this chip, and/or releases the source code for the existing blob under a free license, and people improve it? Anyone who bought the crippled board is screwed.If the concern is that an updated version of the blob might be pushed out that subtracts freedom or contains anti-features, then as long as the free software part of the device controls the path that loads the firmware, malicious updates can be prevented. For extra paranoia there could be a physical interlock, a switch that must be thrown to allow an update, though that costs. I'm afraid that the FSF has painted themselves into a corner here. They can't get around the fact that every nontrivial chip today has many processors with proprietary code in them, so they have invented this distinction that says that programs that can't be upgraded can be treated as circuitry and thereby make it possible to claim that they only run 100% free software. In reality no one (including RMS) runs 100% free software because of the vast amounts of firmware and microcode. One can deny that reality, or instead work to continually increase the amount of free software available over time. This would mean that a device that a user can potentially program is preferable to one that cannot be altered, and is freer as well as long as there is no DRM lockout scheme.
Papering over a binary blob Posted Sep 29, 2011 5:52 UTC (Thu) by nhippi (subscriber, #34640) [Link]
Even if Marvell decides not to document/open source the firmware, someone could reverse engineer it. The gta04 would not benefit of such reverse engineered firmware of the future.
Locking up the firmware is against the spirit of free software - it does not add users freedom, it removes existing freedoms (ability to run user selected code on wifi chip).
Papering over a binary blob Posted Sep 29, 2011 6:19 UTC (Thu) by busman (subscriber, #7333) [Link]
I think I understand what they are trying to achieve. Any physical circuit can be malicius and we wouldn't know about it. However, it can't replace itself without the user noticing (You know, opening the case, getting out of the case, replacement in to the case and then closing the case - usually from the outside).
By doing it this way we at least stay where we have been most of the computing history (swapping hardware for better performance). Binary blobs lessens our ability to control the devices we own because it's "circuitry" can be changed on the fly without user noticing (of understanding what really is going on).
I for one think that this is actually clever :) One would assume that programming a free driver for this "controller" chip would be much easier than making a whole firmware blob replacement for each and every device out there. One would also assume that creating a hardware jail to contain all untrusted components would be much more plausible.
Papering over a binary blob Posted Sep 29, 2011 6:23 UTC (Thu) by rsidd (subscriber, #2582) [Link]
Jon - thanks for telling it like it is. Why is good sense so lacking in otherwise honourable and well-meaning people? I know RMS likes to say that you need to restrict freedom to enable freedom (hence GPL and not BSD/MIT or public domain). But this is almost a reductio ad absurdum of that philosophy.
Papering over a binary blob Posted Sep 29, 2011 8:12 UTC (Thu) by rvfh (subscriber, #31018) [Link]
Why not use a chip that has open-source drivers instead? I believe the TI chips have drivers in mainline kernel, and they can do WiFi/BT/FM/A-GPS. Or am I missing something? An I bet they might be cheaper than the Marvell chip + an OMAP3.
For those who don't know, the OMAP3 is the processor of the Nokia N9, so using it only to load a firmware blob is a bit like using a Core i7 as floppy disk controller...
Papering over a binary blob Posted Sep 29, 2011 8:53 UTC (Thu) by mpr22 (subscriber, #60784) [Link] They're using the OMAP3 as the main processor. The device intended to be used to shove the firmware in is an MSP430F5528IYFF.
Papering over a binary blob Posted Sep 29, 2011 10:01 UTC (Thu) by tau (subscriber, #79651) [Link]
This is what I find so remarkable about the whole thing. Even if there was a legitimate need to do this firmware shuffling exercise, the lowliest 8-bit microcontroller would be adequate for shoveling data from an EEPROM onto a simple I2C-like serial bus. Instead they want to use a monstrously powerful multimedia application processor more powerful than the entire machine that sat on my desk just ten years ago? If I didn't know the FSF any better I'd almost say this entire thing is a troll.
Papering over a binary blob Posted Oct 3, 2011 13:05 UTC (Mon) by TMM (subscriber, #79398) [Link]
Well, the MSP series of chippery is hardly a fully fledged multimedia CPU, the model they chose has 128KB of flash and 10K of RAM.
Assuming they they want to flash the the firmware on the micro itself, it's not such a bad choice, it's reasonably cheap at USD4 considering what they want to achieve.
Yes, they could've done it even cheaper with a separate flash chip, and an even cheaper micro but you have to wonder if will actually work out cheaper consider the extra board complexity.
Papering over a binary blob Posted Sep 29, 2011 9:09 UTC (Thu) by ekj (guest, #1524) [Link]
The decision clearly shows what happens when purity takes a front-seat compared to pragmatism.
It's *logical*, but it does not make sense.
If a device acts a certain way because of the physical way its transistors are arranged, we can still write software to run on that device, and claim that the software is 100% free. (the device is not, but the software is).
If a device acts a certain way because the burned-in non-modifiable firmware that is part of it is, the situation is entirely parallell from the POV of the rest of the system. "it does this because -this- pin is connected to -that- pin" isn't functionally different from "it does this because -this- address in the firmware contains -that- value".
Thus, it makes sense to say the software on this device is also free.
This merely takes it one step closer. There's no functional difference between a device with non-changeable firmware, and a device with changeable firmware, wired up to a non-changeable non-controllable second device that *always* inject the same firmware.
Thus it makes sense to claim that this too, makes the device use fully free software.
The problem is that 100% free software is not the goal. Freedom, is the goal. So sure, if you take a non-free software-component and replace it with a non-free hardware-component, your software will be "purer". But the overall situation will not have improved.
You've got more free software - but less free hardware, the sum total being a slight negative.
You can ignore that, if you've got your eyes firmly glued to a small *part* of the overall picture though. If you're the free SOFTWARE foundation, it's easy to forget that +1 to software-freedom and -2 to hardware-freedom isn't a win.
Papering over a binary blob Posted Sep 30, 2011 1:06 UTC (Fri) by vonbrand (subscriber, #4458) [Link] You've got more free software - but less free hardware, the sum total being a slight negative. Nope, you get the same free software, unfreer hardware (can't run free software on it), net loss.
Papering over a binary blob Posted Sep 30, 2011 12:03 UTC (Fri) by lab (subscriber, #51153) [Link]
> The decision clearly shows what happens when purity takes a front-seat compared to pragmatism.It's *logical*, but it does not make sense. <snip>
I agree. Let sanity rule the day, please.
Papering over a binary blob Posted Sep 29, 2011 9:29 UTC (Thu) by ortalo (subscriber, #4654) [Link]
IMO, time to go after full systems built with open cores. (Not hardware with available documentation, but available design sheets, routing, circuitry, everything.)
That will be a real challenge however.
Papering over a binary blob Posted Sep 29, 2011 10:46 UTC (Thu) by neilbrown (subscriber, #359) [Link]
A few minor corrections if I may:
1/ the GTA02 (Openmoko Freerunner) has Bluetooth, so that is not a new feature.
2/ The Debian port is not expected to make "the whole thing work". Rather it will be able to demonstrate that most of the hardware is working, and the early adopters are encouraged to help make the rest of it work.
3/ The article seems to suggest that the GTA04 developers are motivating the papering-over, and that the FSF agrees with the approach. I think it is actually the other way around. The FSF is motivating the the papering-over and the GTA04 developers (who in general have a very pragmatic approach to issues of freedom) seem to see it as an acceptable cost for a valuable gain. (I cannot easily judge the cost or the value).
This: http://lists.goldelico.com/pipermail/gta04-owner/2011-Sep... is a reasonably relevant post from the main developer - the rest of the thread is worth reading for anyone who wants to know a bit more.
Papering over a binary blob Posted Sep 29, 2011 12:18 UTC (Thu) by etienne (subscriber, #25256) [Link]
It seems that "Papering over a binary blob" with a co-processor will hopefully create a sane and documented interface to talk to this kind of peripheral device, and long term another (more Linux friendly) device provider might develop another device of that kind, with that same upper interface, for cheaper than the current solution.
People will then switch to the free solution en-masse, screwing the initial provider of closed solution.
Papering over a binary blob Posted Sep 29, 2011 12:27 UTC (Thu) by gezza (subscriber, #40700) [Link]
So the solution appears to be that as the firmware blob has to be distributed as hardware, there is no issue with it being part of the software distribution. So why not sell it as a CD with the hardware?
Increased hardware costs for the same end goal of having the same binary blob running on the same processor.
Is there any chance that a FSF endorsement will come to be considered, rather than a "valuable gain", as a reason to check what compromises were accepted in order to get it.
Imagine, that Intel's pentium calculation bug from many years ago, could be corrected at boot time by loading a binary blob. Why would anyone not want to do it?
A final question for those who know the hardware. Once this binary blob is loaded, will it still be possible for the other processor on the SDIO to load a new blob, or change the programming of the existing one, by triggering a reset or some other means?
It's not part of the software distribution. At all. Posted Sep 29, 2011 13:37 UTC (Thu) by khim (subscriber, #9252) [Link] So the solution appears to be that as the firmware blob has to be distributed as hardware, there is no issue with it being part of the software distribution. So why not sell it as a CD with the hardware? Possible. But then you'll need embed CD-readed in the GTA04 device... and this will looks strange and unwieldy. A final question for those who know the hardware. Once this binary blob is loaded, will it still be possible for the other processor on the SDIO to load a new blob, or change the programming of the existing one, by triggering a reset or some other means? Have you actually read the article? Of course not (or at least that's the stated goal). That's the whole point! FSF's position is clear: if you have some large binary blob of a firmware somewhere in the system, but there are no way to upgrade it without hardware changes then you can as well treat it as part of hardware - that's why you'll need CD reader without external access to it in your initial example. This is not as stupid as it sounds (people did similar tricks with arcade machines where LD was irreplaceable and was considered part of the hardware), but it does not make sense for mobile phone.
It's not part of the software distribution. At all. Posted Sep 29, 2011 17:24 UTC (Thu) by gezza (subscriber, #40700) [Link]
>> A final question for those who know the hardware. Once this binary blob is loaded, will it still be possible for the other processor on the SDIO to load a new blob, or ...
>Have you actually *read* the article? Of course not (or at least that's the stated goal).
Do you *actually* know *anything* about hardware?
And the stated goal is to avoid distributing binaries with the software, not necessarily to prevent any particular access between primary processors and peripherals.
Distributing a CD with the hardware allows the end user to read binaries from said CD when he builds new software to program into the device. As the binary is not distributed with the software distribution, there can be no license issue *with the software*.
Another example of the FSF/GNU/RMS myopic and short term view Posted Sep 29, 2011 13:32 UTC (Thu) by jwarnica (subscriber, #27492) [Link]
There is another comment to the effect that, despite some problems today with licenses, they can only trust the FSF and their "or later version" licenses to fix things, long term.
This "problem" is not a new one. Burned in firmware, or microcode, has been around.... forever. Ever heard of the IBM 360? microcode everywhere. Being the most successful computer of its day, and arguably the most successful architectural design ever (still being a significant player today), I'm sure that its existence and general design features managed to penetrate the hallowed halls of the MIT AI lab.
Another shocking blind-spot is the "new" existence of cloud services, SaaS, etc. Only new if you have never heard of Multics, or of Compuserve, or spent more then 5 minutes thinking about how real businesses and end users used computers in the 60's, 70's and 80's.
RMS, and by extension, FSF, have a shockingly poor view of how computers, electronics, software and networking are actually used by real people. (Of course, they don't care. The want to return to 1975 AI lab culture, not a better culture for everyone)
Unquestionably they have produced some very specific artifacts of excellence. Licenses, software packages, the occasional speech.
Lets not extrapolate that out to being the gurus of everything.
Papering over a binary blob Posted Sep 29, 2011 14:39 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] Weird. The USB version of the chip can have its complete firmware in SPI flash, which is what OLPC did for the 'Active Antennae' so it didn't need to be loaded at all; they operate as mesh repeaters when you just apply power.Can't the SDIO version of the chip do the same? And anyway, why in $DEITY's name wouldn't they just use a chip from someone who actually gives you the firmware in a sane form; aren't there Atheros chips which meet that requirement? There's OpenFWWF too but I'd be hesitant to recommend BRCM.
Papering over a binary blob Posted Sep 29, 2011 23:47 UTC (Thu) by neilbrown (subscriber, #359) [Link]
When you want a chip that is available and reasonably priced in small volumes and also does everything that you want (I believe the one chip in GTA-04 does Wifi, Bluetooth, and GPS), then your options are limited.
I am certain the GTA-04 developers only chose a chip with closed firmware because there was no other option at a comparable price/functionality/availability point.
Of course if you know of a better device and can get a competitive quote for small quantity, I'm sure the developers would be very interested.
Building a fully open device that is so expensive that only a couple of people will buy it is not good business sense.
Papering over a binary blob Posted Oct 2, 2011 7:01 UTC (Sun) by mcgrof (guest, #25917) [Link]
Yeah, the carl9170 driver uses GPLv2 firmware. This is stupid.
Papering over a binary blob Posted Oct 3, 2011 10:15 UTC (Mon) by neilbrown (subscriber, #359) [Link]
Stupid might be a hasty judgment.
I asked Dr. Nikolaus Schaller, the lead developer for the GTA04 for his recollection on why the decision was made. You can read it here:
Note in particular that if a genuine alternative is available (at reasonable price in small quantities) it could be swapped in for the next board version (after the "Early Adopter" boards are out). So if you have a concrete suggestion, and particularly if you know of availability, I'm sure your input would be warmly received.
Papering over a binary blob Posted Oct 5, 2011 16:11 UTC (Wed) by wilck (subscriber, #29844) [Link]
In the same post you quoted, Nikolaus Schaller writes
"And I think we should do something today even if it is only 99% free."
If that's his position, why does he even bother with FSF's bizarre suggestion?
Papering over a binary blob Posted Sep 30, 2011 4:44 UTC (Fri) by njs (guest, #40338) [Link]
The irony is that while this is causing bad press for the FSF, I bet no-one there actually *likes* this approach... it's more or less exploiting a loophole in their rules.
Their problem is, the result they *actually* want is for the firmware to be Free. Therefore, they definitely can't endorse a the "pragmatic" solution of just using the closed firmware -- there's a real danger that everyone will just stop there once their hardware is working, and the whole point of the FSF is to keep pushing for the full solution, even if that's not easy to achieve right now. That's a valuable role.
But in order to decide whether a device's software is sufficiently free, they feel that they need to make a bright-line ruling about what counts as "software", and it turns out that you can kluge around their definition by burning the firmware into the hardware.
I'm not saying that the FSF is actually opposed to this hack, just that it's hardly something they would support on its independent merits -- it's a corner they've gotten backed into. If anything, I think they'd actually consider it a bonus that this kind of hack is so ugly, exactly because it means that there's still incentive to solve the problem properly by freeing the firmware.
I'm surprised that the hardware developers are taking the trouble to do this to get the FSF's endorsement instead of just saying "well, we got as close as we could but there's still room to improve". But I guess that's their decision; I don't blame the FSF.
Papering over a binary blob Posted Sep 30, 2011 13:10 UTC (Fri) by vonbrand (subscriber, #4458) [Link] I'm sorry, but showing the firmware into ROM and sealing it up doesn't give any more freedom, it just takes freedom away. With such a machine I can't try out a FSF-free firmware at all. If they had taken this stand on the beginning, nobody would ever have heard of them: They explicitly targeted machines running very much closed operating systems, and the "GNU system" was just a thin random spattering of nicer-than-the-vendor's programs.
Papering over a binary blob Posted Oct 2, 2011 5:13 UTC (Sun) by njs (guest, #40338) [Link]
> I'm sorry, but showing the firmware into ROM and sealing it up doesn't give any more freedom, it just takes freedom away.
Sure. But who's saying otherwise? They haven't said that they think that burning stuff into hardware creates a net increase in user freedom (or if they have, I'd appreciate a link!). They've said that it's enough to satisfy the specific rules of the "the software in this device is free" endorsement, because it does an end-run around their definition of "software".
If you really think that the FSF likes the idea of making software unmodifiable, then how do you explain their controversial insistence on anti-Tivoization language in GPLv3?
> If they had taken this stand on the beginning, nobody would ever have heard of them
I'm not sure what stand you're attributing to them, but yes, I think we can agree that if there was no such thing as software then indeed no-one would have heard of the FSF.
Papering over a binary blob Posted Oct 4, 2011 14:04 UTC (Tue) by vonbrand (subscriber, #4458) [Link] The "no no-free software allowed anywhere" stand they are now taking was completely impossible when "the GNU system" was gcc, emacs and a spattering of nice-to-have packages which could only run under a Unix.
Papering over a binary blob Posted Oct 4, 2011 23:01 UTC (Tue) by njs (guest, #40338) [Link]
Have you, um, read the GNU manifesto? Their goal in writing that software was always to produce a complete free replacement for Unix, and producing a spattering of nice-to-have packages was a nice side-effect along the way. AFAIK RMS has always argued that using non-free software is ethically acceptable if and only if you are using it to produce a free replacement.
That's their ideal, though; I wouldn't call it their stance. If they actually had a "no non-free software allowed anywhere" stance, then surely they'd be trying to squash tools like mingw, and the GPL wouldn't continue to have a special exception for linking against anything "normally distributed with the operating system"?
Papering over a binary blob Posted Oct 2, 2011 5:06 UTC (Sun) by tytso (subscriber, #9993) [Link]
What I don't understand is why people care about the FSF's endorsement?
Personally, because of their fanaticism, I've considered the FSF to be more and more irrelevant these days....
Papering over a binary blob Posted Oct 2, 2011 5:23 UTC (Sun) by njs (guest, #40338) [Link]
Yeah, I don't know why people care either. But, I also hope people don't start thinking of the FSF as irrelevant. On the one hand, many of the specific things they do are pretty useless or cringe-worthy. On the other, I more or less agree with their principles, and am really glad that there are people willing to stand up and make "radical" claims like "moral considerations are relevant to software development" -- it keeps the Overton window open wider. That's the most important thing they do, IMHO, and it's as relevant as ever.
Papering over a binary blob Posted Oct 1, 2011 12:56 UTC (Sat) by ballombe (subscriber, #9523) [Link]
There are good reasons why circuitry is better than non-free firmware: relevant law about warranty and copyright are more favorable to the user of the circuitry.
You can disclaim warranty and use copyright to restrict user right on the product, which you cannot do with physical circuitry.
However none of that apply here, since Marvell does not build the circuitry itself, it does not have to provide warranty, and the GTA04 still need a license from Marvell to copy the firmware in the circuitry.
Of course, If Marvell had agreed to provide the circuitry itself, it would have been different.
So all in all, it is a strange decision even by FSF standard, even for a rabid anti-non-free-firmware like me.
Papering over a binary blob Posted Oct 3, 2011 15:07 UTC (Mon) by ssam (subscriber, #46587) [Link]
even with a binary blob the openmokos are by far the open phones available. I wonder what phones the people who knock it use?
its is impossible for everything in ones life to be opensource. the FSF solution to this is to create a hard line at where opensource matters, and force to its logical conclusion they would happily run windows if it was burnt into a ROM.
My view is that we should try to push opensource as far as we can and keep pushing. so given the choice of a phone with everything in ROM (or some non modifiable chip) like old nonsmart phone, or a smart phone that has 99% open software, open schematics, and an open source friendly company behind it, I would choose the latter.
Papering over a binary blob Posted Oct 6, 2011 2:34 UTC (Thu) by slashdot (guest, #22014) [Link]
I think the mistake lies in the fact that when talking about a system "using free software", one needs to say which part of the system one is talking about.
In most cases, it is a statement about software running on the normal execution mode of the main CPU (but not the main CPU itself): this allows binary firmware just fine.
If one wishes to have "free software for everything", then that should apply to hardware too (and its hardware description language sources), since it has pretty much the same properties of software, at this level.
Hence, there is then no difference between closed-source hardware, or hardware with closed-source firmware.
Once one makes this distinction, the issue in the article becomes moot.
|
|||||||||||||