Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen <bts@alum.mit.edu> wrote:
> Matthew Garrett <mjg59@srcf.ucam.org> writes:
>> The firmware is never executed on your CPU.
>
> The driver is. Look, there are two circumstances here:
>
> * If the firmware's on an eeprom, I could build another device just
> like that one but implemented with clever rodents instead. And the
> driver would still work.
Ok...
> * If the firmware's a loaded bitstring, I can't build another device
> unless it also emulates execution of the firmware -- because
> somebody might change the firmware, and expect changed functionality.
But someone could try to change the firmware in your clever-rodent based
system, too. They'd fail miserably (and the rodents would probably not
be happy about it either. Shame on you for exposing them to such
cruelty).
> In other words, if the firmware's in a box we can treat the whole box
> as a hardware machine. If the firmware's an exposed software blob, we
> have to treat it like one and recognize the dependencies.
What extra freedoms does this buy you? How is the cause of free software
benefited from this distinction? Your entire point here seems to be that
drivers that depend on non-free code that's in ROM are preferable to
non-free code that's on disk. This is surely backwards - on-disk
firmware is easier to modify (not by a lot, but a little) than on-ROM
firmware.
If there's any sort of driver that we should prefer from a free software
perspective, it's the one that makes it easier to provide a free
reimplementation of the non-free code. I'm confused by why you think the
inverse is preferable.
--
Matthew Garrett | mjg59-chiark.mail.debian.legal@srcf.ucam.org
Reply to: