[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Marco d'Itri wrote:
> glenn@zewt.org wrote:
>>Huh?  If a driver requires a firmware blob be copied from a driver CD,
> Please repeat after me: "drivers do not require firmwares, hardware
> devices require firmwares".

First of all, no: *both* require the firmware in order to perform their
function.  See my reply <417D32C4.2000902@verizon.net> in the thread
"Re: firmware status for eagle-usb-*" for a full explanation of why,
including actual code from such a driver.

However, suppose that your statement were true.  Why stop there?
Consider the case of a piece of hardware which could not be initialized
correctly except by the Windows driver.  In order for the device to
work, a user would need to boot up Windows, allow the driver to
initialize the device, and soft-boot into GNU/Linux, at which point the
driver could control the device.  Also suppose that the Windows driver
was shipped on the manufacturer's CD, so the user already has it (which
is almost always the case).  Repeat after me: "Drivers don't require
initialization, hardware devices require initialization". :)  So why
can't this driver go in main too?

For that matter, the Linux driver could even be coded to load the
relevant piece of the Windows driver at runtime, and use it to
initialize the hardware; that's obviously more convenient for end-users.
 The user still has the Windows driver already, and the amount of
non-free code has actually decreased (since they don't need Windows
anymore); why not put the Linux driver in main?  What if more and more
new drivers started to work this way (something similar was speculated
at one point, when there were discussions about a uniform driver
interface for different OSes)?  Would you begin to change your arguments
based on convenience, just to try to get more people running Free
Software (on a non-free base), as you are for drivers that require
firmware?  Quoting from your message
> bts@alum.mit.edu wrote:
>>So rather than ship the driver in contrib and the firmware in
>>non-free, you're suggesting that the driver go in main and the
>>firmware not be shipped at all, even though that reduces the
>>functionality of the driver to "Error: no firmware found."
> Yes. I believe that this better serves our users. I can think about at
> least two common situations in which an hard dependency would not be
> appropriate or even possible:
> - when distribution is restricted by copyright, so we cannot distribute
>   it even in non-free (usually when the driver has been developed from
>   scratch by a third party)
> - when the firmware is used by a device needed to install the system,
>   like a network card or a modem (if the user has got the Debian system
>   on a CD it may be easier for him to get the firmware from the vendor
>   CD than downloading it and the transfering it to the target system
>   using some removable media)
>>>That seems as clear a dependence as any other foo and foo-data package
>>>in the repository.
> Probably because you did not think much about real-life issues...

So it certainly sounds like your reasoning is based primarily on
practicalities; if a large number of drivers started to be based on
proprietary hardware initialization code provided by the manufacturer,
it would certainly be more practically convenient to permit drivers
requiring this code to go in main.

For another example, suppose there were a new, proprietary 3D graphics
interface, ClosedGL, only implemented by ATI's and nVidia's proprietary
driver.  Suppose someone wanted to package a game that used ClosedGL.
Repeat after me: "Programs don't require drivers, hardware devices
require drivers (to provide APIs)". :)  So by your arguments, why can't
this game go in main?

- Josh Triplett

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: