Re: non-free firmware: driver in main or contrib?
Raul Miller writes:
> > 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)
> interface.
>
> 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.
The drivers really do nothing differently based on the firmware[1].
The difference in behavior are things like being able to send only
even numbers of bits of data versus not caring whether the number of
bits in a data packet are odd. The driver does not care, but the
application does, and it knows what to expect from the firmware.
[1]- There is one exception that is essentially a kludge to avoid
assigning a new PCI device ID; the board is physically different in
that case.
> > > 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?
I think that the two are clearly treated differently, although having
a clear definition for "the Debian system" (as in the SC) would be
helpful to resolve the questions of "Why?" and "Where?"
> 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.
Drivers that talk to firmware-requiring devices would be allowed in
main, rather than in kernel modules or patches kept outside Debian
proper. The firmware files themselves would have to be provided by
the user or in non-free, unless they qualify under the DFSG[2]. I
believe this is the direction being taken for the Linux kernel in
general (to not contain opaque blobs, but to provide a facility to
load them when needed).
[2]- Firmware that is DFSG-free and provides source, but which
requires a non-free HDL toolchain to build, might qualify for contrib.
Michael Poole
Reply to: