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.) 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 logic from the SC, and I believe it's a useful, functional interpretation (from the perspective of Debian's goals). If you don't like this, and think it's inconsistent, or that Debian's goals would be better served with a different interpretation or a different SC, you're free to lobby for change, of course. > 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. > > 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). > > In practice, the distinction manifests itself in an obvious way: if I can > > say "apt-get install fooclient" and then say "fooclient server.com" and > > have it work, it's functional on its own. If I get a notice saying > > "before you even bother trying to use this, grab this data and install > > it", or if I try to run it and it says "AIM.EXE not found, put it > > somewhere", > > it's not functional on its own. This is clearly a case where--if we > > were allowed to redistribute it at all--we'd say "Depends: > > aim-binary-package" > > and stick aim-binary-package in non-free. (The firmware case is identical.) > > I disagree that pointing fooclient at server.com makes it functional > on its own. The essential function is not complete without the other > end, and for the cases I described the other end cannot be satisfied > within Debian. 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. -- Glenn Maynard
