Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen writes:
> Michael Poole <firstname.lastname@example.org> writes:
> > Not at all. If you fill the block with random data, the driver will
> > continue to do what you expect and what you can follow by reading its
> > source code. It is the device that will not perform and that will not
> > live up to its end of the interface. That is why I referred earlier
> > to a hypothetical device that ignored the firmware you send to it.
> So if I have a program which loads a library, and replace the library
> with random data, the program will continue to do what I expect and
> what I can follow by reading its source. It is the library that will
> not perform, not living up to its end of the interface?
The driver does not call to or use the firmware. It uses the device.
This is not at all the same as the loadable library case.
In my day job, I work on a device driver that can talk to a device
programmed using several different firmwares. Other drivers I have
worked on can downloaded firmware but the boards also have EEPROMs
that hold default firmwares. Importantly, the drivers do not behave
differently based on whether the default firmware or any of several
custom firmwares are used; the differing behavior is of interest to
the application, not the driver.
> Your arguments seem to lack an internal consistency.
By demanding that some hardware components of a system be free, while
exempting other hardware from the same requirement, your arguments are
the ones that seem to lack consistency.