Re: non-free firmware: driver in main or contrib?
> Brian Thomas Sniffen writes:
> > 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?
On Tue, Oct 26, 2004 at 11:33:21AM -0400, Michael Poole wrote:
> 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 cases where the driver doesn't function without the proper action of
the firmware loader, it's pretty clear that the driver depends on the
firmware loader. If the firmware loader is in contrib, then the driver
should be in contrib, too.
> 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.
This sounds like a fairly well designed (and somewhat transparent)
That said, it sounds like the drivers do behave differently depending on
the firmware -- you've asserted that the difference is not of interest
to the driver, but that's not at all the same as asserting that there
is no difference.
> > 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.
The requirement is not that the hardware be free.
The requirement is that the software be free, and that it not have
dependencies on non-free software.
It should be clear (even if you don't think it makes sense) that currently
we make a distinction between things we deal with as if they are software
and things which we deal with as if they are not software?
If that's not clear, I suppose we could go over the basics again.
If that's clear, but you think that something else makes more sense,
maybe you could talk about what the consequences of your point of view
would be on Debian? Changes which advance our goals are good things.