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

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

Ken Arromdee wrote:
> On Mon, 25 Oct 2004, Josh Triplett wrote:
>>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?
> I would disqualify that driver from main not because it depended on a
> Windows driver, but because it depended on having Windows itself.  Unlike the

I see; so some dependencies on non-free software are to be considered
acceptable, while others are not?

> hardware/eprom and hardware/CD combinations, hardware/Windows isn't sold
> together and the user would have to get Windows separately--not because he

And in many cases, the user would need to get the firmware for a device
separately.  Not all drivers that require firmware images provide the
means to extract it from a manufacturer's CD; some choose to extract it
from updates provided on the manufacturer's website, or from Windows
drivers obtained separately, or downloaded from the Linux driver
author's site.  Some firmware images have even been sniffed off of a bus
during the reverse engineering used to create the Linux driver.

> lost a CD that he once had, but because Windows really is a separate item in
> more ways than just physically being on a different disk.

And what of my second suggested case (which you omitted in your reply),
where the Linux driver could load the necessary piece of the Windows
driver without needing Windows?  Would you permit that driver to go in
main, since it would only require the Windows driver and not Windows
itself?  Your argument seems to suggest that you would.

>>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?
> You may as well claim that a hard drive is a "piece of hardware which does
> word processing", that a word processor is a driver for this piece of hardware,
> and that without this driver you lose some functionality because the hard
> drive won't process words.
> The flaw in this reasoning is that a hard drive or a graphics card is a
> general purpose piece of equipment.  The "driver" isn't a driver.

Many hardware devices are also general-purpose pieces of equipment,
using general-purpose processors, whose "firmware" is just software
compiled for that architecture.  The point of firmware is generally to
make a piece of hardware less hard-wired and more reparable, which is to
some extent a step in the direction of general-purpose.  Yet just as the
driver requires a certain method of talking to the firmware, the game
requires a certain way of talking to the driver, which requires that
whether the low-level component has a general-purpose device to work
with or not, it must provide a certain interface to those components at
a higher level than itself.

It seems to me that your arguments for including drivers in main that
require other non-free software are extremely fuzzy and involve criteria
(like "general purpose" or "not because it depended on a Windows driver,
but because it depended on having Windows itself") that seem to have no
relation to actual Debian policy and/or the Social Contract.

On the other hand, the arguments for _not_ including such drivers in
main are trivially explainable with one simple test: can someone with
the necessary hardware, having only main in their sources.list, and
without installing any non-Debian software, build, install, and
successfully run the package?  If they can, the software should go to
main.  If not, it should go to contrib.

Finally, I'm curious: what is it that makes people so adamant that these
drivers should be in main, rather than contrib?  You and others have
mentioned various practical arguments, but none related to freedom.
Furthermore, even if practical arguments were allowed to trump freedom,
I don't see any practical arguments against putting the drivers in
contrib that could not be solved with a suitable technical solution.
What is the reason that you fight so hard to include such items in main?

- Josh Triplett

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: