Adam Bolte <abo...@systemsaviour.com> writes: > On Sat, Aug 25, 2012 at 04:32:36PM +1000, Ben Sturmfels wrote: > > Choosing an AMD card means I'm giving some profits to AMD, who offer > > dramatically better support for free software. On the other hand > > though, I'd be required to use proprietary firmware. > > True. Even basic embedded proprietary firmware that users are not > expected to interact with directly can still be a problem, as most > people who have purchased a SSD recently would be able to tell you. […]
> If my above assumptions are correct, why treat graphics driver > firmware specially? First you'd need to show that we're treating graphics firmware specially. I think the same criticisms are applied to vendors who act against freedom in network interface firmware, graphics firmware, radio firmware, etc. > I'm certainly not saying it's wrong to demand free firmware, however > I'm curious why some firmware is treated differently. Is it because > one lives in your filesystem on your HDD, but the other is stored in > an EEPROM (and if so, why does this matter)? Almost. The important matter is: who has effective freedom in the device once it's in the hands of the customer, to determine what it does and modify its behaviour and share those modifications with others? With some devices, such as the keyboard controller chip, the answer is something close to “no-one”. These are devices whose behaviour is entirely determined at the time the customer buys them, and are not under the influence of anyone to change that behaviour. Such devices are effectively unchanging machines, and don't present much of an imbalance of freedom between the vendor and customer: neither is in a privileged position. With other devices, such as the CPU, the answer is close to “the customer”. The whole point of the CPU is to be endlessly reprogrammable, and the customer has close to infinite freedom to determine that programming. Such devices are effectively under the control of the customer, not the vendor. So those aren't much of a problem for the customer's freedom either. The border that is contentious is where we find devices designed to have their behaviour modified, but in a rather limited way and through tightly restricted channels – such as upgrading the firmware at boot time or run time from a binary blob. For these difficult-to-update devices, the question then turns on who has effective freedom to deploy updates to the device's behaviour. If the customer is effectively restricted from deploying their choice of update, while the vendor has a privileged channel to get updates to the device, then that's a problem for the customer's freedom. If the customer has no less freedom than the vendor to deploy their choice of update to the device's behaviour, then there's no disparity between the vendor's freedom in that device and the customer's. This is why a keyboard chip which no-one can modify isn't a significant problem for freedom, and the CPU which the customer can easily modify isn't a significant problem for freedom, while a graphics chip commonly is a problem and we pay close attention to which vendors act to preserve or restrict the customer's freedom in the device. The border is ever shifting, too. Whereas persistent storage devices (such as HDDs) used to have behaviour that neither the vendor nor the customer could update, many SSDs now have the expectation of updates to their behaviour – and the vendor has the same kind of privileged path to choose those updates which the customer doesn't have. So vigilance is required: the tendency is for newer devices to place freedom to choose the device's behaviour in the vendor's hands while denying it to the customer. -- \ “We jealously reserve the right to be mistaken in our view of | `\ what exists, given that theories often change under pressure | _o__) from further investigation.” —Thomas W. Clark, 2009 | Ben Finney
pgpLTzks94r28.pgp
Description: PGP signature
_______________________________________________ Free-software-melb mailing list Free-software-melb@lists.softwarefreedom.com.au http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb
