Re: non-free firmware: driver in main or contrib?
Raul Miller <moth@debian.org> wrote:
> On Mon, Oct 25, 2004 at 12:52:19PM +0100, Matthew Garrett wrote:
>> Brian, we are talking about identical code.
>
> Are we?
In many contexts, yes.
>> Software doesn't stop being software if it's burned into a ROM instead
>> of being supplied with the OS.
>
> It does, however, cease to be a dependency issue if those who have the
> hardware also have the firmware.
In most cases, they do already have the firmware. It's on a CD that came
with the hardware.
> For practical reasons, we don't require that all users have a piece of
> hardware before we distribute software which drives that hardware.
>
> However, we don't bother including that software in main unless all the
> software it depends on is free. If they're not, the software goes in
> contrib (or non-free), assuming we distribute it at all.
The reason we don't include free software that has non-free dependencies
in main is that we want to discourage people from using non-free
software. If the user already has non-free code in ROM, then there is
the same amount of non-free software being used.
> In this context, we ignore bits which are embedded in the hardware,
> but we don't ignore bits that we distribute.
It's more complicated than that, because in several of these cases we
don't have permission to distribute the firmware anyway. Your argument
is either:
1) Code can go in main if it's dependent on code that is shipped with
the hardware. If it depends on code that we ship instead, it has to go
in contrib.
2) Code can go in main if it's dependent on code that is in an eeprom.
If it depends on code that is stored on the hard drive instead, it has
to go in contrib.
In the case of (1), we penalise drivers that use firmware that's under a
slightly more liberal (though still non-free) license. This seems wrong.
In the case of (2), we penalise drivers for hardware that the vendor has
made slightly cheaper and more flexible. This also seems wrong.
> It's really that simple.
Whichever argument you're using, it leads to the following situation. A
vendor releases a piece of hardware. It requires run-time loadable
firmware. We put the driver in contrib. A customer comes to the vendor
and asks for a version that doesn't require the firmware be loaded from
userspace. The vendor adds an eeprom and puts the firmware in that
instead. Despite there being the same amount of non-free code, we can
now put the driver in main.
Does this not strike you as mad? We make a distinction between main and
contrib because we want to discourage non-free code. The distinction
you're drawing instead merely encourages vendors to put their non-free
code on an eeprom. It doesn't advance the cause of free software, and it
doesn't help our users.
--
Matthew Garrett | mjg59-chiark.mail.debian.legal@srcf.ucam.org
Reply to: