User: Password:
|
|
Subscribe / Log in / New account

The FSF answer to Matthew Garrett's list ...

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 5:26 UTC (Thu) by rahulsundaram (subscriber, #21946)
In reply to: The FSF answer to Matthew Garrett's list ... by JoeBuck
Parent article: Searching for common ground between Debian and FSF

I think FSF's position is one of equality. If the hardware manufacturer has made it programmable, that freedom should be there for the users as well and source shouldn't be held a secret within the firmware. If it is not programmable, then the rights are the same for both parties. It is true that if it is firmware, then you have some chance of making it free and thus more flexible and cost effective but I don't think FSF's position is inherently self conflicting.

I am not sure I agree with it though. Where to draw to the line isn't as clear cut as it may seem at first glance and FSF's positions are not necessarily the community consensus. Firmware isn't the only source of such debates but apparently the most visible but GNU FDL invariant sections is another. One could consider font sources, game data and so on. FSF seems to have a less stricter view in these instances than I would have expected.

https://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF

https://www.gnu.org/philosophy/nonfree-games.html

Debian's efforts should be encouraged however since it helps with peer review of the standards involved and can bring up out the differences in a more public way. Transparency on disagreements is certainly helpful.


(Log in to post comments)

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 8:09 UTC (Thu) by dlang (subscriber, #313) [Link]

if you were talking about devices that could be updated remotely without any user intervention, then there could be a valid argument about the 'equality' of the owner with the device manufacturer.

But since almost no devices work that way, and if they have flash, frequently require specific user actions to update the system (booting into special modes for example), usually along with big nasty warnings about how dangerous the upgrade is. It seems very clear that the power to upgrade or not is already in the hands of the owner of the device. nobody forces them to upgrade.

the few devices that do have remote update processes (Sony game consoles for example) make no pretension of being free or open in any way and are not harmed by the FSF position

the fact that the FSF has actively encouraged firmware to be burned into ROM so that it could not be modified by anyone as an "improvement" over the exact same binary blob being loaded by the otherwise free OS is a clear indication of how wrongheaded they are. They would rather have a device that the owner cannot control that runs a binary blob instead of a device differing only in that the binary blob gets loaded to the device by the free OS instead of by additional hardware.

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 11:54 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

I think you didn't understand my point about having equal rights. I was not talking about remote updates or whatever of that nature but referring to the fact that hardware manufacturer have the source to the firmware and if it is non-free, the hardware manufacturer has all the control and you don't get to fix issues with it or even know what has really changed in-order to decide whether you want the update or not and yes, it is a practical problem in some cases. For instance, OLPC needed to tweak it for better power management and Fedora sometimes has to push updates without any real changelog.

https://lwn.net/Articles/459240/

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 17:58 UTC (Thu) by bosyber (guest, #84963) [Link]

Maybe a more apt way to describe it is "equal (lack of) rights".

That makes clear exactly what the problem with it is. It is an all or nothing clause: it doesn't promote openness so much as it requires the hardware reseller to choose - either go open fully, go or the easier route of no rights for anyone.

That second option is technically inferior, often worse for security and usability; but in companies that lack understanding and/or practice of open source, much easier to understand and thus sell, and thus it is the choice to make for many such companies. And they are still a big factor, or even the majority.

In theory both the software blob and the hardware ROM can be reverse-engineered and updated with free components, given enough effort. But this is much cheaper and easier to do with a software update than with hardware, which makes the 2nd option in practice worse for the FOSS community, certainly in the short run.

Theoretically then, this view is consistent, true, but in practice it doesn't clearly promote openness, nor a good path towards getting there, which is what ideally would be provided, as that would practically help improve the landscape for open software and hardware.

It is therefore not surprising that dlang, and many others, view it as going in the wrong direction, I'd think.

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 18:10 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Actually, the hardware manufacturer has *more* rights if they decide to keep the firmware proprietary. They can fix any bugs in the firmware and you don't have that right. There are three choices

* No separate firmware at all
* Free firmware
* Non-free firmware

A) and B) is acceptable for FSF but C) is not. Again, I am not arguing that FSF is absolutely right but it is a very clear position and is logically consistent with the rest of their ideals which is always in favor of end user rights.

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 18:59 UTC (Thu) by bosyber (guest, #84963) [Link]

And since C) is not acceptable, that leaves an all-or-nothing choice where in both cases they have the same rights to existing products: both can update, or neither can update, yes.

But, as I said, it might be consistent, but it also is arguably of very limited use in today’s world.

Since in many countries reverse-engineering for interacting is allowed, you might well have the right to replace the hardware as much as the software. Both are limited by legal barriers to uncertified running and warranty. If a software update blocks your phone's access to the network, so will a hardware tweak, after all.

Replacing software is in most cases a much more feasible strategy, and thus allowing for it gives much better hope of opening a closed product after sale.

Of course B) would be the preferred option, but it isn't the current majority choice, so blocking C) leaves A) as the practically poorer short-term default for much hardware.

I understand that the FSF isn't always concerned with practicality, but others may be; I repeat, it isn't surprising if those feel this is the wrong way to progress.

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 20:56 UTC (Thu) by DavidS (guest, #84675) [Link]

And since C) is not acceptable, that leaves an all-or-nothing choice where in both cases they have the same rights to existing products: both can update, or neither can update, yes. But, as I said, it might be consistent, but it also is arguably of very limited use in today’s world.
Couldn't that be the point the FSF's trying to make? "A firmware that can only be updated at the manufacturer's mercy is worse - for the user - than a firmware that can't be updated at all?" At least one could send the TV back as defect, instead of having to wait for the next "OTA". Which won't fix it anyways.

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 21:31 UTC (Thu) by bosyber (guest, #84963) [Link]

Yes, I do expect it is. And I see value in that message. Keeping that point in mind is very important as an outlook of where we want to go.

But it seems also clear that people might not like it (and thus work against it instead of heeding it) and/or think that a different approach will work better as a way to actually get there; especially as a solution until we eventually, hopefully, end up there.

The FSF answer to Matthew Garrett's list ...

Posted Jul 12, 2012 22:27 UTC (Thu) by dlang (subscriber, #313) [Link]

the issue is that the manufacturer usually doesn't have the power to update the firmware without the user doing something to approve it.

If you are talking about something like a TV where everything is fed from the manufacturer over the air, you really aren't talking 'firmware' you are talking about the complete OS of your system.

the idea that a Wifi card is somehow 'better' if you would have to send it back to the vendor to upgrade the firmware rather than moving to a new linux kernel driver version that uploads a different binary blob to the wifi card is where people get upset.

The FSF answer to Matthew Garrett's list ...

Posted Jul 16, 2012 9:17 UTC (Mon) by ballombe (subscriber, #9523) [Link]

> the fact that the FSF has actively encouraged firmware to be burned into ROM so that it could not be modified by anyone as an "improvement" over the exact same binary blob being loaded by the otherwise free OS is a clear indication of how wrongheaded they are.

It is not the FSF which is wrong-headed, but laws and regulations.
Copyright and warranty laws are much more favorable to users when the firmware is in ROM than when it is loaded from software.

In particular you can disclaim warranty on software but not on hardware, you can use software license to limit usage and resell in ways which are not possible with hardware.

The FSF answer to Matthew Garrett's list ...

Posted Jul 16, 2012 16:55 UTC (Mon) by dlang (subscriber, #313) [Link]

This is a new argument as far as I am concerned.

I've never heard of any differences is liability (or even claimed liability limits) for a NIC card depending on if the firmware is in ROM, in Flash, or loaded by the OS.

can you point me to any device that has made such claims?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds