On Tue, Dec 28, 2004 at 11:46:19PM +0000, Matthew Garrett wrote: > It may be helpful to think of your hard drive as a computer. At that > point, the firmware is clearly software for the hard drive - it's a > string of bytes that is executed. The rest of the hard drive is > hardware. If something is software in one situation, I believe that it's > reasonable to treat it as software in other situations. > > This leaves a distinction between the code executed by processors and > the processor itself.
That's not the only distinction. The relevant distinction is whether whether or not we consider there to be an adequate abstraction barrier between the two pieces of code. Other distinctions don't really matter. For example systems running opengl with hardware support are going to have a different processor running the graphics commands. But "has a different processor" doesn't really matter in the context of the DFSG, as long as we can legally port software to it. In general, the question of "does this piece of software require that piece of software" is a sticky one, because there are so many different kinds of cases. For example, if A requires some B where B has a non-free implementation and a free implementation, we consider A's requirement to be satisfied by the free implementation even though there's also a non-free implementation. And yet with an identical A and a B which only has non-free implementations, we consider A to depend on non-free software. In some sense, this has nothing to do with A. Likewise, no software can run without hardware, and with current technology there's no freely redistributable hardware. So we also ignore dependencies on hardware, out of simple pragmatism. This is in some senses a weakness, and I can imagine cases where we really would need to consider a dependency on hardware as a software freedom issue. But mostly, this isn't an issue for us. Drivers for firmware, where Debian doesn't have to treat the firmware as software we've been treating with the same pragmatism as hardware. So far, it hasn't really mattered to us how the hardware is implemented. Drivers for firmware, where the driver would typically be non-functional if we didn't ship some non-free software image, we've been treating as depending on non-free software. Here, our pragmatism is overridden by our need to ship something which isn't free. Anyways, none of this depends on the kind of processor which is executing the code. If some bit hardware has firmware which uses a pentium instruction set, why should that make any difference? To my knowledge, our primary interest in different kinds of processors has to do with porting. If we run across some software where the copyright doesn't allow us to port it, we consider that software non-free. > representation provides. On the other hand, the nature of firmware > doesn't change between the point where it's stored and the point where > it's used. You speak as if there were One True Firmware Nature. But "firmware's nature" depends on the context in which you're speaking. For example, for some people firmware which they can use has a very different nature from firmware they can't use. This is the case even if the underlying hardware is identical for these two cases and thus, from a hardware point of view, has the same "nature". -- Raul
