Re: firmware status for eagle-usb-*
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
Reply to: