Matthew Garrett <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> 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 loading firmware. 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 to main. > 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 shipping it." -Brian -- Brian Sniffen [EMAIL PROTECTED]
