Re: non-free firmware: driver in main or contrib?
Matthew Garrett <firstname.lastname@example.org> writes:
> Brian Thomas Sniffen <email@example.com> wrote:
>> I think that requiring a hardware upgrade to support behavior is
>> irrelevant to free software. Firmware that's part of the hardware is
>> part of the hardware. Firmware that looks like software is software.
>> If Debian *could* ship it, it's software. Stuff requiring
>> 3d-acceleration, or the -686 kernels, are all free.
> A vendor produces a piece of hardware with a GPLed driver. In order to
> save a few pennies on manufacturing cost, the firmware is provided on
> the driver CD rather than on an eeprom. You would then argue that we
> should ship the driver in contrib.
That or ask the vendor to free the firmware, yes.
> The vendor then produces a second revision of the hardware. It uses the
> same driver, but this time the firmware is on an eeprom. By your
> argument, we are then free to move the driver to main.
I disbelieve. It's not the same driver. This one doesn't have the
loadable firmware support, and does support operation without first
And yes, once someone's demonstrated that reimplementation -- or a
free loadable firmware -- I'd say the Dependency on the loadable
firmware becomes a Suggests, and we can move the driver from contrib
> In both cases, the quantity of non-free software used has remained the
> same. The purpose of contrib is to discourage free software with
> non-free dependencies. Deciding whether software falls into it or not
> purely based on another vendor's choice of media seems mad. Either we
> disapprove of hardware that requires non-free firmware, or we don't -
> whether it has to be on the user's hard drive is a hardware
> implementation issue, not a philosophical difference.
It is a philosophical difference, as is clear from the fact that we're
having a philosophical argument about it. It's not about another
vendor's choice of media. It's about whether we have to tell a user
"Well, you'll have to go get more software from X, and we're not
Brian Sniffen firstname.lastname@example.org