On Mon, 25 Oct 2004, Josh Triplett wrote: > > I would disqualify that driver from main not because it depended on a > > Windows driver, but because it depended on having Windows itself. > I see; so some dependencies on non-free software are to be considered > acceptable, while others are not?
I meant dependency in the same sense that a driver might "depend" on there being something in an eprom or other replaceable part. If you agree that that's dependency, then yes some dependencies on non-free software are acceptable. > > 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. I think that this is a good place to stick to the spirit of the rules. If anyone with the hardware can get the firmware under restrictions no worse than if it was physically part of the hardware, then treat it as if it was physically part of the hardware. > 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. It would only suggest this if hardware+Windows driver gives the user the same rights as hardware+eprom would. I think this is unlikely to be the case. > 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. In other words, whether or not the device is general-purpose enough that something uploaded to it should be treated as part of the device is a judgment call. Yes, that is true. > 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? Those requirements are assuming the conclusion. The question is about how to treat software in comparison to hardware. That list of requirements specifies that hardware and software should be treated differently and thus assumes a particular answer to the question. > 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. The argument "it's as free as this other thing, which you consider free enough" *is* about freedom.
