Marco d'Itri wrote: > [EMAIL PROTECTED] wrote: >>If you want to argue that a package in contrib should be included on CDs >>or in the installer, feel free to argue that. Please do not conflate >>that issue with the entirely non-technical decision of whether a package >>goes in main or contrib; otherwise, you are doing a disservice to >>another important class of users, namely those who count on Debian to be >>true to its stated values and keep the clear distinction between main, >>contrib, and non-free. > > I consider doing a disservice to our users (and an insult to the > developers of such drivers) keeping free software out of debian because > of, at best, unclear and not consistent criteria.
I find the criteria extremely clear and consistent: if it depends on stuff that is either non-free, or that is too non-free to even ship, it goes to contrib. If a user can install and run it (and be able to compile it as well if they so desire) without ever having to go fetch and install a single piece of non-free software to do so, it goes to main. The rules are only unclear when someone is trying to weasel out of them. The easiest way to apply these rules to a given driver is to consider what a user would need to do to use the driver. The debian-installer scenarios you have suggested are quite reasonable, so I'll use those. In one case, suppose the user just needs to load the driver in order for their network card to work. The driver includes no non-free firmware, and they do not need to supply any. It is possible that firmware is already installed on their card, but that's a detail of the hardware; in the ideal case, the specs of the hardware would be completely open, including the firmware, but that's another battle separate from Free Software. The driver should go to main. In the other case, the user must go get the firmware from somewhere, such as by using a tool to dig it out of a Windows driver on the manufacturer's CD or website, or by extracting it from a firmware update supplied by the manufacturer. They must then install the firmware on their system somewhere (such as the hotplug firmware directory), or supply it to the installation procedure. Their network card will then run, now that the necessary non-free software is supplied. The driver should go to contrib. I think there's a clear distinction between these two scenarios. Until the day when we all run LinuxBIOS or similar on our Open86 or FreePPC (or F-CPU if that ever takes off) systems, there will be non-free firmware and non-free hardware in user's systems, and various pieces of the Linux kernel will require some of those pieces of firmware and hardware. This is highly unfortunate, but it is the current scenario. Just as the GNU project had to live with the use of non-free software for quite some time in order to have a functional system, so too we will have to live with the use of non-free firmware and hardware for some time in order to have a functional system. However, let's suppose for the sake of argument that you are exactly right: the two scenarios of firmware-on-device and user-supplies-firmware are equivalent, and that since it would be ridiculous to move all hardware-dependent software to contrib, it should be in main, which implies that software which requires user-supplied non-free firmware also goes to main. Now, what differentiates the case of requiring non-free firmware from the case of requiring non-free NDIS drivers? Especially given that many people are likely to already have the necessary driver on their system? And even if they don't, by your argument, that's equivalent to the scenario where they have to fetch it separately. Why not let ndiswrapper go to main? And if you think that's acceptable, why is anything in contrib? After all, why differentiate between NDIS drivers and any other form of non-free software dependency? - Josh Triplett
signature.asc
Description: OpenPGP digital signature
