Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: >> So if EEPROMs contain software, why "don't [you] get to distribute any >> drivers"? I don't understand. > > You can get software out of an firmware-EEPROM on a hardware device. > I don't think it's appropriate to call that software as is, or in > general. This line *could* be drawn in lots of places, but if you say > that the contents of an EEPROM are software, then how about a one-shot > PROM? How about a book with a print-out of the source code?
A PROM generally contains software (unless you're going to argue that executable code is not always software, in which case I'm going to ignore you). A book is a representation of software but not software itself, since the book exists outside the digital domain. > The only reasonable place to draw the line, for Debian, is this: can > Debian physically ship it in a useful way? For files on disk, the > answer is yes. We are constrained only by the license. For the book > or the PROM, the answer is no. For an EEPROM, in general, the answer > is no. For any such correctly operating device, the firmware is > already there. Debian can't usefully ship it. It would be > interesting to try supporting an architecture to run on those devices > instead of Wind River or whatever, but there isn't one now. Ignoring license constraints, I can find you any number of cases of eeproms where Debian could ship the contents. I can probably find you several that would run on hardware you currently own. Again, drawing the distinction at this point results in the solution that provides more practical freedom to the user being penalised. This implies very strongly that we're doing something wrong. > When the firmware has to be uploaded, it's a dependency. If it were > just a magic initialization sequence, that would be OK -- such a > sequence is presumably too short to copyright. But this is long and > non-free, clearly software, and clearly a dependency. The dependency is not on the specific firmware in question - the dependency is on code that will cause the general purpose device to behave in the way that the driver expects. In the vast majority of cases, the only code that currently satisfies that constraint is non-free, but there's no intrinsic reason why it has to be so. We can compare this to other hardware. The orinoco wireless driver depends on the hardware acting in a specific way, and does this by communicating with the firmware in the device. In doing so, it is communicating (and hence depending) upon non-free executable code - ie, software. But, again, there's no intrinsic reason why it has to be so. You could write free firmware, or you could reimplement the device in such a way that it doesn't actually have any firmware (for sufficiently simple cases, you might be able to reimplement it in a fairly large quantity of clockwork), and hence remove the dependency. But these are hypotheticals. Drivers that require loaded firmware tend to use non-free code, and drivers that require hardware to respond in certain ways tend to use non-free firmware on that hardware. In both cases, we could reimplement something in order to remove that non-free dependency (either free firmware or hardware that doesn't use firmware), but *nobody has done so*. A hypothetical implementation of something without non-free code doesn't satisfy us. You have argued that drivers don't really depend on firmware, but instead depend on the hardware expressing the correct interface. As an example, we can compare maria-vis, which depends on the graphviz package. maria-vis is in contrib, because it depends on graphviz, which is in non-free. But by your argument, it doesn't actually depend on graphviz - it merely depends on something that presents a correctly functioning graphviz interface. This could be a piece of non-free code, but it could also be a piece of free code, an interface to a remote application server, or a userspace application to drive hardware that kicks intelligent rodents until they draw the correct graph. There's no intrinsic dependency on the non-free code. But since the non-free code is currently the only solution that /does/ express the correct interface, there exists a dependency on non-free code. If you can find me a piece of hardware that can be driven by the kernel's orinoco driver and which contains no non-free executable code, I will agree that the driver does not require the use of non-free executable code. But not until then. -- Matthew Garrett | [EMAIL PROTECTED]