Re: Dealing with drivers that need firmware on the filesystem
On Sun, Jan 09, 2005 at 02:36:03AM +0000, Matthew Garrett wrote:
> In the firmware case, the choice is rather different. At present, the
> choice is not between free firmware or non-free firmware. The choice is
> between non-free firmware on disk or non-free firmware in ROM. Putting
> drivers in contrib penalises the former, and as a result implicitly
> encourages the latter.
it's worse than just putting them in contrib. there's a whole bunch of
drivers with firmware blobs that have just been deleted from the kernel
sources. they're not in contrib, they're not in non-free, they're just gone.
this affects even DFSG-free drivers with DFSG-free patches. you often can't
apply the patches to the debianised kernel sources because the context that
the patch needs is missing.
e.g. try downloading the patch[1] for DVICO Fusion DVB-T card's DFSG-free
driver and applying it to the kernel source from any kernel-source-x.x.x
package. it won't apply to the debian kernel, yet it applies without a
problem to pristine sources downloaded from kernel.org.
[1] http://www.itee.uq.edu.au/~chrisp/Linux-DVB/DVICO/
is this driver non-free? no.
does this driver contain firmware blobs? no.
what heinous crime has it commited then, so that debian users are either
unable to or have to jump through silly hoops to use it?
it is related to (shares some common files with) and/or adjacent to some
*OTHER* drivers for other cards that do have firmware blobs. that's it.
nothing more than that.
debian has forked the kernel (and not for any sensible or useful reason - just
to satisfy some extremist ideologues), and it is already causing problems for
us and our users. it is also making debian an object of scorn and ridicule by
kernel hackers (and deservedly so).
> b) If not, what's the correct approach?
>
> We /could/ put non-free firmware in main, on the grounds that while it
> is in many cases executable code, it does not execute on any processor
> that is under the direct control of the operating system. This would
> possibly require a small alteration to the social contract. A result
> of this would be that not everything in main would be DFSG free.
IMO, this is the correct approach at least for stuff in the standard kernel
source tree. from the kernel's POV, it is not code, it is just data that gets
uploaded to a peripheral device[1]. the firmware blob is included in
GPL-licensed code and is also GPL. it's no more "non-free" than
pre-calculated lookup tables in programs like gzip and bzip, or the CSS data
in decss and related programs.
[1] in many cases, it's also data from the peripheral's POV, after it has been
uploaded - it's not executable code, it's configuration, setup or state data.
> An alternative would be to leave non-free firmware in non-free, but
> not to enforce the requirement that drivers depending on it end up in
> contrib. This is possibly the most straight forward, and by squinting
> funny we could possibly even argue that the social contract already
> allows this.
>
> A third possibility would be to create a new section for material that
> is non-free but whose freeness we don't really care about. Drivers in
> main would be allowed to depend on this, and we'd include it on the
> install media. This would require changing the social contract.
either of these might be appropriate for third-party drivers, not included
with the standard kernel source.
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: