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

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

Marco d'Itri wrote:
> josh.trip@verizon.net 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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: