Re: LCC and blobs

[Matthew Garrett <mgarrett@chiark.greenend.org.uk>]

Brian Thomas Sniffen <bts@alum.mit.edu> wrote:
> Hamish Moffatt <hamish@debian.org> 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 | mjg59-chiark.mail.debian.legal@srcf.ucam.org