Re: LCC and blobs
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
Reply to: