Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
goals of the FSF
Posted Sep 30, 2011 9:43 UTC (Fri) by pjm (subscriber, #2080)
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 (subscriber, #41318)
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 (✭ supporter ✭, #5246)
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)
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 (✭ supporter ✭, #5246)
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 (guest, #40338)
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 (subscriber, #50638)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds