Re: firmware status for eagle-usb-*
glenn@zewt.org wrote:
>On Thu, Oct 28, 2004 at 10:05:05PM -0400, Michael Poole wrote:
>> > BIOSes are in the EPROM case that I've described--part of the hardware,
>> > already present--and go in main.
>> How does this exception follow from either the SC, DFSG or Policy?
>Hardware is not part of Debian, and the fact that Debian depends on
>non-free pieces of hardware has never been considered to violate any of
>the above. (And, as I've said a few times, stuff tucked away in an
>EPROM acts like part of the hardware.)
And every time you failed to explain why software magically is not
software anymore when stored on a flash EPROM.
> I acknowledge that this isn't
>the only possible interpretation, but I believe it's the one that Debian
>is currently acting on, I believe it follows without any stretches of
No, currently drivers for devices without permanently stored firmware
are accepted in main.
>> I understand that position, but I do not see why the distinction
>> follows from a foundation document or from policy. The "where's the
>> data?" case is avoided by pointing the driver at /dev/zero.
>At which point the program says "server closed connection: data is bogus",
>or the hardware device tries to run null data and crashes, and they do
>nothing useful.
I can't see why this should matter. The driver implements a firmware
loader, which is something useful in itself and is also the first element
needed to develop a free firmware. All other functions of the driver are
still available, but if the hardware is not willing to interact with it
I can't see why this should impact the freeness of the driver.
Which criteria are you applying to decide that this is not "useful"
enough?
>> > This is distinct from software which merely interacts with a non-free server,
>> > but--as far as that functionality is concerned--is complete and able to do
>> > so on its own.
>>
>> I do not see how this is different than the firmware case.
>
>Please be more specific; there are at least two significant categories
>of "firmware case". Software that merely interacts with a remote server,
>but is able to do so on its own, is analogous to the EPROM case (drivers
>which are able to make a device do useful things on their own). Software
>that interacts with a remote server, and has to send a block of non-free
>data to it for it to do anything, are analogous to the RAM case (hardware
>that must receive a block of firmware to do anything at all).
I can't see the rationale behind this. If you agree that the hardware
devices are beyond the dependency barrier then I do not understand why
it matters if their firmware is provided by the manufacturer on a CD or
a flash EPROM.
BTW, if everything is software I can't see how that non-free data used
for authentication is different from a password or SSL certificate used
for authentication.
>I'm not sure that this disagreement is important to the comparison: a
>client requiring a non-free piece of data to make use of a server is not
>complete without that data, and (going back to the reason for making
>this comparison) a driver requiring a non-free piece of firmware to make
>use of a piece of hardware is not complete without that piece of firmware.
>
--
ciao,
Marco
Reply to: