goals of the FSF [LWN.net]

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.