[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: