Re: non-free firmware: driver in main or contrib?
Matthew Garrett <mjg59@srcf.ucam.org> writes:
> On Mon, 2004-10-25 at 07:07 -0400, Brian Thomas Sniffen wrote:
>> Matthew Garrett <mgarrett@chiark.greenend.org.uk> writes:
>
>> > On the other hand, if it's clearly software when it's on CD then it's
>> > clearly software when it's on eeprom.
>>
>> False. That's why we call it firmware, not just "software living on a device".
>> It's an implementation detail of the hardware that they happen to have
>> shipped a microprocessor and a hardwired program. If the program had
>> been burned into a circuit in an FPGA, would you still call it
>> software?
>
> Brian, we are talking about identical code. Software doesn't stop being
> software if it's burned into a ROM instead of being supplied with the
> OS. An FPGA is a more interesting issue - would you define a set of
> verilog code as software if it's supplied on disk?
Sure.
Heck, for all I know there's a device out there where the "firmware on
disk" is verilog code, and it's compiled by the driver and loaded to
an FPGA on the device.
Surely that's software. Hm. It proposes an interesting model of the
driver as a sort of processor (like a compiler or an interpreter) for
the firmware, more than the library model I've been considering.
>> If it's a single-use PROM, is it still software?
>
> If we would want the source code to it if we shipped the contents, then
> yes, it's software.
>
>> >From the point of view of the driver, the device is just a device. It
>> gets... driven. That's it. No need to consider the things inside and
>> force decisions about software or not onto them.
>
> I want a world in which all code run on a system is free, no matter
> whether that code is executed by the host processor or something on a
> card.
Why draw the line at software, then? Why not wish for open specs for
all the chips, so you can modify the CPU or GPU?
> I see no reason for us to consider non-free software more
> "legitimate" purely because it's on a chip rather than on a hard drive.
> As a result, I consider all arguments that apply to code on hard drives
> to apply equally well to code on chips.
>
>> Anything the user's being told to copy to /usr/local/something, on the
>> other hand, is clearly software.
>
> You appear to be claiming that identical code is firmware if it's on a
> chip and software if it's on a CD, and that we should apply different
> standards to each situation. I'm claiming that it's always software, and
> we should apply the same standards to it in all cases.
I think that the *dependency* doesn't exist in some reasonable models
of a device as a black box, which either does or does not depend on
user-loaded firmware.
That is, in all reasonable models the driver depends on the device,
but Debian does not reflect that dependency because the device is
hardware, not software.
In some reasonable models, the device depends on its firmware, whether
pre-loaded or user-loaded. That's the model you're using. To be
consistent, Debian must express all these dependencies -- and so most
drivers go into contrib, which we all agree is impractical and bad.
In some reasonable models, the device depends on user-loaded firmware,
and pre-loaded firmware is inside the abstraction barrier and we don't
get to see it. So we still must express all the dependencies we see,
and only *some* drivers must go to contrib; those which can drive
devices with no user-visible firmware can be considered free.
-Brian
--
Brian Sniffen bts@alum.mit.edu
Reply to: