[EMAIL PROTECTED] 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
