Re: firmware status for eagle-usb-*

[Michael Poole <mdpoole@troilus.org>]

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