Re: firmware status for eagle-usb-*
glenn@zewt.org wrote:
>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!
Yes, sure! If some stream of bits is considered software when stored in
RAM then I can't see why it should not be software anymore when stored
in some other media. I have not seen any convincing argument about why
software should lose its nature if stored in ROM.
If the conseguences of this are that some interpretations of the policy
or social contract are inconsistent then maybe you should start
considering that they may really be, after all.
>Looks like hardware, acts like hardware.
To me, it looks like software stored in hardware.
>Of course, it's a boundary case--it's neither strictly hardware nor software.
Really? I think it's quite clear.
>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'm sorry, but the policy revisionists forced Debian to think that there
is only software and they have been very clear about this.
>> 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.
Yes, this is what I was talking about.
>> 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
>at all.
The driver could upload /dev/zero as well, I don't think this is
important. The firmware modifies the capabilities of the hardware
device, not of the driver.
I don't believe the theory about "indirect dependencies" has any
foundament in the policy or the SC, or it would have to be applied to
any kind of software interacting over any communication channel.
>> 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.
Why?
--
ciao,
Marco
Reply to: