Glenn Maynard writes: > On Thu, Oct 28, 2004 at 06:50:43PM -0400, Michael Poole wrote: > > > It's true that different firmwares (or bytecodes, or pieces) might satisfy > > > this, but all that's important is whether there exist at least one of > > > them which is free and in main. If they're all free, the existance of > > > several non-free alternatives doesn't change anything. > > > > Do you therefore agree that boot loaders depend on the BIOS, and > > therefore grub, lilo, etc. must go into "contrib"? > > 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? > > Do you agree that > > packages that require a non-free server (or PDA or whatever is on the > > far end of a wire) to do anything useful must go into "contrib"? > > Requiring a non-free server on the other end of the wire is a different > case. > > What I'm describing here is client software that, in order to function > usefully, must have access to a piece of non-free stuff (bytecode, firmware, > AIM.EXE) to send to the server; without that stuff, the client and server > do nothing useful, and it exits with "where's the data?" when you try to > use it. > > (The above is a repeat of what I've already said--I'm just making sure we > stay on the same page.) 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. > 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. > 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. Michael Poole
