Re: firmware status for eagle-usb-*
Please try to space out your quoting like everyone else does, so your mails
On Fri, Oct 29, 2004 at 11:07:14AM +0200, Marco d'Itri wrote:
> >Hardware is not part of Debian, and the fact that Debian depends on
> >non-free pieces of hardware has never been considered to violate any of
> >the above. (And, as I've said a few times, stuff tucked away in an
> >EPROM acts like part of the hardware.)
> And every time you failed to explain why software magically is not
> software anymore when stored on a flash EPROM.
By that logic, the same piece of data stored on an involatile ROM (that
the driver can't upload at all) is also to be considered software. It's
non-free and we require it--I guess we should just give up!
Looks like hardware, acts like hardware.
Of course, it's a boundary case--it's neither strictly hardware nor software.
That's where the word "firmware" comes from in the first place, and that's
why there's disagreement on it--for things which are unambiguously hardware
(my printer) and things which are unambiguously software (/bin/ls), we
have clear boundaries, but for things which are neither hardware nor
software and yet both at the same time, things aren't so clear.
> I can't see why this should matter. The driver implements a firmware
> loader, which is something useful in itself and is also the first element
> needed to develop a free firmware. All other functions of the driver are
> still available, but if the hardware is not willing to interact with it
> I can't see why this should impact the freeness of the driver.
This isn't a question of whether the driver is free or not, it's a question
of whether it goes in main or contrib.
> Which criteria are you applying to decide that this is not "useful"
If the driver was packaged as a firmware loader, useful for the obscure,
rare case of people developing firmware, maybe--but it's being packaged
as a driver, and it clearly isn't useful for that purpose on its own.
"Uh, well, it doesn't drive the device, but I guess it could be used for
this other uncommon purpose" is an evasion; that could be used to move
everything in contrib into main that's in contrib due to a data
dependency, and to move all installer packages from contrib to main.
> I can't see the rationale behind this. If you agree that the hardware
> devices are beyond the dependency barrier then I do not understand why
> it matters if their firmware is provided by the manufacturer on a CD or
> a flash EPROM.
I've already explained this. If it's on a CD, the driver depends on it
to give to the device; the driver doesn't work unless you have the CD to
get the firmware. In fact, if you don't have the CD, you might not be
able to get the firmware at all, and you won't be able to use your device
> BTW, if everything is software I can't see how that non-free data used
> for authentication is different from a password or SSL certificate used
> for authentication.
This is irrelevant.