Kyle -
On Thu, Aug 17, 2006 at 02:41:52PM -0400, Kyle McMartin wrote:
> No wonder you're so ******* enthusiastic about removing support for
> hardware. You don't own any of it. How ******* convenient.
Can I deduce from this that _you_ own some of the affected hardware?
If I patch in request_firmware() support for that driver, would you
be willing to test it?
> Since we seem to be pissing all over the spirit of the Social Contract
> in the name of some holy quest for the unattainable goal of cooperative
> vendors,
Fully cooperative vendors would be nice, but I agree in most cases
that's unattainable. Until that miraculous day arrives, the firmware
that they supply needs to be removed from the free Linux kernel, have
its license checked, and put into the firmware-nonfree package set up
for that purpose. If you disagree with that process, say so.
> Now, I don't think you understand what "preferred form of modification" is.
Trust me, as someone who has written and maintained firmware,
I know what the "preferred form of modification" is.
> In all likelihood, the engineer who wrote, for example, the QLogic driver,
> never even touched the firmware, never once questioned it, another engineer
> simply gave him an array to copy to the card. The engineer who wrote the
> driver didn't know, or care, about what should have just been on an EEPROM,
> all he cared about was properly writing a Linux driver to talk to the
> hardware.
You're probably right, since the Linux driver was probably written after
the Windows driver. In a small company there is usually good communication
and shared debugging sessions between the firmware author(s) and their first
"client", that is, the author of the first driver.
> This is the difference between a piece of firmware, and an actual
> binary blob that something calls into.
I'm sorry if I used the word "blob" for something unusual.
Binary blobs that get linked to by the kernel and executed are not
firmware, and from a practical perspective are worse. Linus doesn't
let those into the kernel, and taints kernels if they are loaded
as modules. Legally, library blobs (executed by the Linux processor)
and firmware blobs (executed by outboard controllers) are not all that
different.
> Now, don't you have something better to do than hurt our users?
I can think of a few snide replies to this. Can we instead
please keep emotion out of this discussion? Can we agree that
etch must have a DFSG-free Linux kernel, and we need to work
together to make that kernel work as well as possible for as
many users as possible?
> PS: I feel it again worth mentioning, that even if there were no firmware
> in the driver, you would just get the exact same data if you pulled the
> EEPROM and stuck it in a reader.
The origin of our problem is that manufacturers have taken to
saving themselves a little money by leaving the EEPROM off their
boards, and putting the firmware on the MS-Windows[TM] driver CD
instead. While they are presumably happy to let Linux users use
that same firmware, the legal and practical mechanism to have
that happen is (in the cases I flagged) broken.
If you take an EEPROM and stick it in a reader, you (the owner
of the hardware) probably have fair use rights to put it on a
disk and boot your hardware from it. Since that firmware is
copyrighted, and you don't own the copyright, you do not have
the right to post it to the web or submit it to the mainline
Linux kernel tree.
- Larry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
