Michael Poole wrote: > Glenn Maynard writes: >>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. Key point: "after the device has the firmware". As you say, drivers for devices that need firmware depend on the operation of the device after the firmware is loaded. Furthermore, the drivers need to load the firmware into the device in order to reach such a state. Therefore, the driver requires (either directly or indirectly) 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. You might be interested to know that the ntfsprogs package contains a "mknfts" tool, for creating NTFS filesystems. > 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. And yet none exist. If even one Free firmware (that could actually perform the functionality required by the driver) existed, or if even one type of device worked without the firmware, then the driver could go to main. This seems no different than claiming that a package with a dependency on a non-free library could go to main because there _could_ be different libraries that implement the same interface. If there _are_ such Free replacements, then that's wonderful; until then, speculation about Free replacements does not allow a package with non-free dependencies into main. > 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. If this were still the case, and no other servers existed without this requirement, then the AIM clients would need to go to contrib. Fortunately, this is no longer the case, as described by others later in this thread. > 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. Yes, tg3 is a very interesting case. Since the driver can drive at least some devices without needing firmware, it can go to main, and the firmware would be only a Suggests. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature