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

Re: firmware status for eagle-usb-*



> > Another premise which would work better is that firmware is somewhere
> > between hardware and software and that there are circumstances where it
> > makes sense to treat firmware as hardware and other circumstances where
> > it makes sense to treat firmware as software.  I feel that this premise
> > is closer to Brian's point of view than the one you just now expressed.

On Wed, Oct 27, 2004 at 05:44:00PM -0400, Michael Poole wrote:
> I think his follow-up post makes it clear that he considers the
> firmware to be software, with no ifs, ands or buts.

I disagree.

Contrast
http://lists.debian.org/debian-legal/2004/10/msg00588.html
"software uploaded to control it, from a file on disk, is software"

with
http://lists.debian.org/debian-legal/2004/10/msg00579.html
"From the point of view of userspace, a driver, device, and any
 firmware on it are one abstract entity."

It seems clear to me that the distinction here is whether we
treat the firmware in question as software or hardware.

> My opinion is that if someone wants Debian to distribute the firmware,
> treat it as software, and apply the DFSG to it; otherwise, treat it as
> outside the Debian system in the respect that the driver should not be
> considered to depend on the firmware.  I think this is consistent with
> our practice for other things on the far side of a low-level interface.

Note that we do treat dependencies on software we do not distribute as
real dependencies.

I think it is reasonable to that if we treat firmware as software in one
context (that is, if we distribute the loader which loads it from disk
into the device) that we should treat it as software in other contexts.

So far, I've seen you raise one practical objection to that treatment
(that there's a lot of firmware out there and we might not be aware of
all the relevant cases).

Do you have any other objections?

It seems to me that having consistency as a goal, and fixing bugs as we
find them, will make more sense in the long run than trying to open up a
firmware loophole in the social contract.  [And it would be a loophole:
either one tied to certain technologies, which means that it will become
obsolete rather quickly -- or one tied to some very general concepts,
which means that it will come to be used in some new and innovative ways
rather quickly.]

Thanks,

-- 
Raul



Reply to: