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

Re: firmware status for eagle-usb-*



Glenn Maynard writes:

> 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].

Yes.

> 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.

In every case I know of, the driver does not care what the firmware
looks like, and does not manipulate it any more than sz/rz or scp
manipulate things they transfer.  It cares what the device does,
usually after the device has the firmware.

Somewhat analogously, software like libntfs (to pick one of almost as
many examples as in my "mass bug filing" email) is not forced into
contrib because it reads partitions that are created by non-Debian
software without being able to write them.

In both the network protocol cases and the unwritable format cases, if
you do not have appropriate non-Debian software, neither the hardware
nor the client (software) do anything useful.  I am not convinced that
the data being transferred is relevant to the dependency relationship,
in part because different firmwares -- or even different hardware --
may implement the necessary interface.

> 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.

One IM protocol (AIM, if memory serves) asked the client to send a
randomly selected region of the official AIM client, and if the
response did not match, rejected the client.  I suspect this was so
the provider could file copyright infringement claims against people
who made compatible clients.  I am not sure whether they still do
this, but AOL has apparently done other things[1] that resemble that.
The big "non-free" IM providers each put significant effort into
blocking unauthorized or all third-party clients.

I am not aware of any cases that more closely resemble the
driver/firmware case.  The tg3 driver case is somewhat interesting,
since the firmware is only needed to do TCP segment offload.  The
driver acts differently based on whether the firmware was sent or not,
but different firmware blobs are used for different boards.

Michael Poole

[1]- http://members.ozemail.com.au/~geoffch/security/aim/



Reply to: