Re: non-free firmware: driver in main or contrib?
Glenn Maynard writes:
> Marco's argument appears to be that drivers should be allowed in main
> that only function if they have access to a non-free firmware blob;
> that a driver that, lacking the file, merely bails and says "download
> this non-free piece first" should be allowed in main.
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.
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?
> 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.
A number of examples exist in consumer electronics (wireless routers,
portable media players, PVRs) where people in the free software
community have reverse engineered products and provided free (or more
free) versions of OS images. If it were not possible to download new
images to those devices, the world would be a slightly poorer place.
Michael Poole
Reply to: