Re: firmware status for eagle-usb-*
On Wed, Oct 27, 2004 at 09:45:29AM -0400, Michael Poole wrote:
> Even granting that, it does not establish a very clear dependency
> chain from the firmware to the driver. Is the driver case different
> from the various network clients (AIM, Exchange, etc.) in Debian with
> no server implementations in main? If so, why?
The physical hardware has the nature of a remote server: software in
Debian interacts with it, but it's not part of Debian and isn't counted
as a "dependency" or "requirement" for the SC. We probably agree on
this[1].
The firmware has the nature of data being sent to the remote server.
It's being acted on by the hardware, but it's also being manipulated
and transferred by the driver. If you don't have the firmware to send
to the server (hardware), neither the server (hardware) nor the client
(driver) do anything useful. I believe this is a clear dependency from
the driver to the firmware.
As a client/server parallel to the "RAM" case (firmware must be sent
or the device does nothing useful): if the AIM server required that it
be sent a nontrivial block of compiled Java bytecode when establishing a
connection, instructing it in how to do some critical piece of its
functionality, and the only implementation of that code is non-free, then
I believe the client would belong in contrib. If that bytecode block was
optional (if the server fell back to a default implementation if not
supplied), the client would go in main.
I wonder if there are any real examples we can compare to, instead of this
contrived one.
[1] Michael might assert that the SC doesn't actually allow this. I
don't agree with that claim in the case of hardware, but it might have
some merit applied to remote servers. That's tangental, though.
--
Glenn Maynard
Reply to: