Ken Arromdee wrote: > 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. That's an interesting way of evading the question; you never actually said why you thought it was OK to depend on a Windows driver, but not to depend on Windows. Both are non-free, and neither is in our archive. Yes, a driver does "depend" on something in an eprom on a hardware device, but as that something is part of the hardware, and Debian doesn't consider dependencies on hardware, then we don't express it; it isn't a dependency on non-free software, it's a dependency on hardware. On the other hand, a dependency on a software item, such as Windows, a Windows driver, or a firmware image, must be taken into account. >>>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. If we were following the spirit of the rules, I don't think we'd be having this discussion. It is well-known that we don't express dependencies on hardware. It is also well-known that some pieces of hardware are internally implemented using firmware. However, this does not mean that it is acceptable to >>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. It seems to me that you have created a criteria to compare to that is specifically designed to support the one case you are interested in, that of dependencies on non-free firmware images that must be supplied by the user. >>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. Or you could just say that things which are actually *part of the device* should be considered part of the device, and things which are not part of the device, such as separate firmware images supplied by the user, should not be considered part of the device. >>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. It is already generally accepted that Debian does not express dependencies on hardware, and that we do express dependencies on software. If you wish to change that, then you are arguing against the status quo, so the burden of proof for why we should do that is on you. I don't think you will find anyone in this discussion seriously advocating the position that we should treat hardware and software identically; that position would imply that since almost all hardware is non-free, all hardware-dependent pieces of Debian would need to be in contrib. Instead, the two positions I have seen with actual, serious backers are: * The status quo, which is that software is to be treated as software and hardware as hardware, and only dependencies on the former are to be considered. * The advocated change, which is that some software, which is loaded onto a hardware device at runtime by a driver, should be excepted from the dependency list of the driver, and consequently that the driver should go to main. If I have missed a position that someone actually holds, my apologies. >>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. I never said I consider it Free. :) What I said was that it is the accepted practice, for various reasons, to ignore depencies on hardware. That's quite a different matter, and it does not support your argument, since both cases are non-free but one is ignored. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature