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
