Re: non-free firmware: driver in main or contrib?

[Glenn Maynard <glenn@zewt.org>]

On Mon, Oct 25, 2004 at 09:50:42PM -0400, Michael Poole wrote:
> One argument that has appeared previously is that the driver depends
> on the firmware blob because if a different blob were used, the
> hardware might behave differently.  That begs for consideration of the
> obverse case: the hardware might accept a firmware download but ignore
> its contents, and work as the driver expects regardless of the image.

If the hardware ignored the firmware transfer, then there's no non-free
dependency; it can just send /dev/zero.

> I infer from your phrasing that you object to the idea that a package
> in main should fail and recommend the user download a non-free piece
> to work.  How is the firmware case different from, say, libdvdread3?

I object to it, if it doesn't work for anyone.  If there's some hardware
out there that it does work for, then it's fine--it's functional on its
own, at least some of the time.

The hardware it doesn't work for is just extra functionality: it uses non-
free firmware for some devices if present.  If that's all it did, it'd be
contrib.  Similarly, libdvdread3 would be contrib if it was useless without
libdvdcss--but it does work for some discs on its own, so it's in main.

> > Your argument, above, is in the exact other direction: that drivers
> > which function without supplying any extra data, but that use non-free
> > data already present on the hardware, should be considered contrib.
> 
> As I read it, Raul's question is why you accept a non-free component
> of the Debian system when that component is on something like a PROM
> but not when that component is on something like a hard drive.  It
> doesn't matter to the user (in terms of how he can adapt the device to
> his own purposes) if an opaque blob is burned into hardware or loaded
> as firmware.  At least in the loaded-at-runtime case, the potential
> exists for a DFSG-free version.

So you're saying that the loaded-at-runtime option allows for DFSG-free
versions to be implemented, so they should be allowed in main to encourage
that particular design option over the "static ROM" option.  (There's
also the EPROM option, which acts like hardware--the driver doesn't have
to upload anything to work--but also allows for DFSG-free versions to be
implemented.)

That doesn't really change the fact that drivers that only work after
pointing it at a non-free data block have a non-free dependency, and
belong in contrib, though.

-- 
Glenn Maynard