Papering over a binary blob
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 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:
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).
Posted Sep 29, 2011 0:15 UTC (Thu)
by geofft (subscriber, #59789)
[Link] (14 responses)
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.)
Posted Sep 29, 2011 13:03 UTC (Thu)
by coriordan (guest, #7544)
[Link] (2 responses)
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.
Posted Sep 29, 2011 13:24 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
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?>
Posted Sep 30, 2011 13:01 UTC (Fri)
by coriordan (guest, #7544)
[Link]
I've made a page on the Libreplanet wiki for discussing this:
Posted Sep 29, 2011 22:45 UTC (Thu)
by pjm (guest, #2080)
[Link] (10 responses)
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.
Posted Sep 30, 2011 4:56 UTC (Fri)
by njs (subscriber, #40338)
[Link] (7 responses)
Posted Sep 30, 2011 9:43 UTC (Fri)
by pjm (guest, #2080)
[Link] (6 responses)
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.
Posted Sep 30, 2011 22:58 UTC (Fri)
by ldarby (guest, #41318)
[Link] (3 responses)
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...
Posted Oct 2, 2011 19:28 UTC (Sun)
by jzbiciak (guest, #5246)
[Link] (2 responses)
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.
Posted Oct 3, 2011 8:10 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
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.
Posted Oct 3, 2011 8:52 UTC (Mon)
by jzbiciak (guest, #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.
Posted Oct 1, 2011 1:23 UTC (Sat)
by njs (subscriber, #40338)
[Link] (1 responses)
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.
Posted Oct 4, 2011 0:08 UTC (Tue)
by xilun (guest, #50638)
[Link]
Posted Sep 30, 2011 12:46 UTC (Fri)
by coriordan (guest, #7544)
[Link] (1 responses)
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: 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.
Posted Sep 30, 2011 13:13 UTC (Fri)
by pjm (guest, #2080)
[Link]
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.
Posted Sep 29, 2011 0:37 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
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.
Posted Oct 3, 2011 8:16 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
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?
Posted Oct 6, 2011 15:11 UTC (Thu)
by renox (guest, #23785)
[Link]
How is-it "asking the vendor"?
Note that for the firmware of a radio HW, this could even lead your products to be banned..
Posted Sep 29, 2011 0:39 UTC (Thu)
by alankila (guest, #47141)
[Link] (2 responses)
It makes no sense, but people are doing it anyway. What a world.
Posted Sep 29, 2011 8:55 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Sep 29, 2011 17:37 UTC (Thu)
by Fats (guest, #14882)
[Link]
Posted Sep 29, 2011 1:24 UTC (Thu)
by ikm (guest, #493)
[Link] (4 responses)
Posted Sep 29, 2011 13:10 UTC (Thu)
by coriordan (guest, #7544)
[Link] (3 responses)
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.)
Posted Sep 29, 2011 13:46 UTC (Thu)
by anselm (subscriber, #2796)
[Link]
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?
Posted Sep 29, 2011 16:34 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
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.
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.
Posted Sep 29, 2011 2:04 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
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.
Posted Sep 29, 2011 5:52 UTC (Thu)
by nhippi (subscriber, #34640)
[Link]
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).
Posted Sep 29, 2011 6:19 UTC (Thu)
by busman (subscriber, #7333)
[Link]
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.
Posted Sep 29, 2011 6:23 UTC (Thu)
by rsidd (subscriber, #2582)
[Link]
Posted Sep 29, 2011 8:12 UTC (Thu)
by rvfh (guest, #31018)
[Link] (3 responses)
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...
Posted Sep 29, 2011 8:53 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link]
Posted Sep 29, 2011 10:01 UTC (Thu)
by tau (subscriber, #79651)
[Link] (1 responses)
Posted Oct 3, 2011 13:05 UTC (Mon)
by TMM (subscriber, #79398)
[Link]
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.
Posted Sep 29, 2011 9:09 UTC (Thu)
by ekj (guest, #1524)
[Link] (2 responses)
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.
Posted Sep 30, 2011 1:06 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link]
Nope, you get the same free software, unfreer hardware (can't run free software on it), net loss.
Posted Sep 30, 2011 12:03 UTC (Fri)
by lab (guest, #51153)
[Link]
I agree. Let sanity rule the day, please.
Posted Sep 29, 2011 9:29 UTC (Thu)
by ortalo (guest, #4654)
[Link]
That will be a real challenge however.
Posted Sep 29, 2011 10:46 UTC (Thu)
by neilbrown (subscriber, #359)
[Link]
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.
Posted Sep 29, 2011 12:18 UTC (Thu)
by etienne (guest, #25256)
[Link]
Posted Sep 29, 2011 12:27 UTC (Thu)
by gezza (subscriber, #40700)
[Link] (2 responses)
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?
Posted Sep 29, 2011 13:37 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
Possible. But then you'll need embed CD-readed in the GTA04 device... and this will looks strange and unwieldy. 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.
Posted Sep 29, 2011 17:24 UTC (Thu)
by gezza (subscriber, #40700)
[Link]
>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*.
Posted Sep 29, 2011 13:32 UTC (Thu)
by jwarnica (subscriber, #27492)
[Link]
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.
Posted Sep 29, 2011 14:39 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link] (4 responses)
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.
Posted Sep 29, 2011 23:47 UTC (Thu)
by neilbrown (subscriber, #359)
[Link]
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.
Posted Oct 2, 2011 7:01 UTC (Sun)
by mcgrof (subscriber, #25917)
[Link] (2 responses)
Posted Oct 3, 2011 10:15 UTC (Mon)
by neilbrown (subscriber, #359)
[Link] (1 responses)
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.
Posted Oct 5, 2011 16:11 UTC (Wed)
by wilck (guest, #29844)
[Link]
"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?
Posted Sep 30, 2011 4:44 UTC (Fri)
by njs (subscriber, #40338)
[Link] (6 responses)
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.
Posted Sep 30, 2011 13:10 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
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.
Posted Oct 2, 2011 5:13 UTC (Sun)
by njs (subscriber, #40338)
[Link] (2 responses)
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.
Posted Oct 4, 2011 14:04 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
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.
Posted Oct 4, 2011 23:01 UTC (Tue)
by njs (subscriber, #40338)
[Link]
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"?
Posted Oct 2, 2011 5:06 UTC (Sun)
by tytso (subscriber, #9993)
[Link] (1 responses)
Personally, because of their fanaticism, I've considered the FSF to be more and more irrelevant these days....
Posted Oct 2, 2011 5:23 UTC (Sun)
by njs (subscriber, #40338)
[Link]
Posted Oct 1, 2011 12:56 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
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.
Posted Oct 3, 2011 15:07 UTC (Mon)
by ssam (guest, #46587)
[Link]
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.
Posted Oct 6, 2011 2:34 UTC (Thu)
by slashdot (guest, #22014)
[Link]
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.
Papering over a binary blob
The other side of the story
Well, if we accept something is a twisted way... we still accept something...
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?
Well, if we accept something is a twisted way... we still accept something...
goals of the FSF
goals of the FSF
goals of the FSF
goals of the FSF
> situation described in the parent article
goals of the FSF
goals of the FSF
goals of the FSF
goals of the FSF
goals of the FSF
The limits of positive and negative
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?
The limits of positive and negative
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
If the vendor find an issue in their current firmware and release an upgrade, and the users cannot upgrade the firmware due to the "microcontroller indirection", the vendor will just say "you chose to remove the possibility to update the firmware, that's your problem now".
Papering over a binary blob
Paranoia is a very good way to describe Marvell's treatment of its manuals, yes.
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
You're making FSF's point
You're making FSF's point
No company in their right mind would ever publish a tablet with WP7 or any other entire operating system in non-upgradeable firmware
You're making FSF's point
You're making FSF's point
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.
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
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
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
You've got more free software - but less free hardware, the sum total being a slight negative.
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
People will then switch to the free solution en-masse, screwing the initial provider of closed solution.
Papering over a binary blob
It's not part of the software distribution. At all.
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?
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.
Two processors which share a bus means that either can perform the same commands on it. Therefore the question is not unreasonable.
Another example of the FSF/GNU/RMS myopic and short term view
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.
Papering over a binary blob
Papering over a binary blob
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.
Papering over a binary blob
Papering over a binary blob
http://lists.goldelico.com/pipermail/gta04-owner/2011-Oct...
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob
Papering over a binary blob