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