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
