[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LCC and blobs



Hamish Moffatt <hamish@debian.org> writes:

> On Thu, Dec 23, 2004 at 10:55:04PM -0500, Brian Thomas Sniffen wrote:
>> md@Linux.IT (Marco d'Itri) writes:
>> >> Great.  Then the driver operates differently depending on the presence
>> >> of additional software -- it needs a Linux kernel and the firmware.
>> > But then drivers also "depend" on "additional softwares" stored in
>> > flash EEPROMs in devices.
>> 
>> That's not software.  That's firmware, at best -- you can look at it
>> as software, but then you don't get to distribute any drivers.  It is
>> also internally consistent to think of chips as hardware and
>> distribute drivers appropriately.  It is never consistent to think of
>> files on disk as anything but software.
>
> Eh? The contents of EEPROMs are software just as much as the contents of
> CD-ROMs and hard disks. They are just different media for storing
> digital information.
>
> 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?

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.

>> >> Without either of those, it does not operate.  This is a dependency.
>> > But then ICQ clients "depend" on non-free ICQ servers...
>> 
>> Which might be software or hardware or undistributed or all sorts of
>> things.
>
> The ICQ server isn't distributed in Debian, so why aren't the clients in
> contrib?

This is an excellent parallel to the firmware situation.

The ICQ clients don't depend on the ICQ server software.  They depend
on a compliant server.  It might be a general-purpose computer running
non-free software.  It might be a specific hardware device.  It might
be a very fast monkey with a set of switches on an Ethernet cord.  It
could be anything.  This is an abstraction barrier.  It would be
*nice* to have a free ICQ server-software in Debian.

Similarly, we can treat a device with on-board firmware as an abstract
device.  It could be implemented in any way.  But we can abstract over
that and treat it as a device, and write a driver for it, and it works
fine.  It would be nice to have free firmware-software, and free HDL
specs, and free board art, and a patent-free interface spec, and a
pony.  But none of these are dependencies.

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.

Perhaps if you could challenge the ICQ situation more clearly, I
might believe a parallel challenge to on-board firmware.

-Brian

-- 
Brian Sniffen                                       bts@alum.mit.edu



Reply to: