"Jeff Carr" <[EMAIL PROTECTED]> writes: > On Mon, Oct 27, 2008 at 18:41, Ben Finney <[EMAIL PROTECTED]> wrote: > > > Whoever the copyright holder of that work is (I read your remark > > above to mean that the hardware manufacturer is that copyright > > holder), there must be a "preferred form of the work for making > > modifications to it". What form is that? *Someone* must have it, > > in order to make modifications that become new releases of the > > work to run on the same hardware. > > I guess it's really hard to explain because there is a massive gap; > I can't teach you to be an electrical engineer or logician here :) I > think if you had the time to go through and synthesize "firmware > blobs" for some chips then you would see why this doesn't make > sense.
Nevertheless I really appreciate the effort you're taking to explain this. Not just for myself either: If bunches of bits are to be redistributed in Debian, that needs to be done in a manner compatible with the explicit promises of the Social Contract, regardless of whether those who package those bits for redistribution are themselves trained electrical engineers. So, it's important for the freedom issues to be understood by we mere mortals who don't deal with logic boards; and that involves bridging gaps in understanding, without requiring all of us learning everything about each others's field :-) > It's that these "binary only blobs" only make sense to the chip. I'm not disputing that. The reason these programmatic bit streams are an issue is that if they're to be redistributed by Debian, the recipient needs to have the guarantees of freedom as per the Social Contract. So, it is irrelevant (for the purpose of satisfying the contract of freedom) which particular hardware they are intended to be loaded into, be it a CPU or a daughterboard processor. > For example, lets say you have a pci device. If you don't load the > firmware blob, the pins will just remain in an uninitialized state. > That is; the chip default. Programming in the firmware blob will > tell the chip how to work as a pci bus. Now you are good to go. It's > now possible to write a pci device & there are registers, etc. So, it sounds like we're talking about exactly the same freedom issues, just with a different processor involved: the PCI board's processor instead of the motherboard's CPU. > Still, the firmware blob that you load into the chip isn't x86 code > for the host -- it's raw junk for the chip. That “raw junk” is, if I understand you correctly, instructions and data for controlling the behaviour of the processor on the PCI chip. How is this different from saying that the machine-code form of a program is “raw junk for the motherboard's CPU”? I get the impression you're saying it's different in some way other than which processor the bit stream is destined for, but I'm trying without success to see what difference exists that eliminates the right of the recipient to have freedom in that work. > It's a totally different issue than distributing a binary only > nvidia driver. That's not what I'm talking about here. Understood; I'm fairly sure the distinction between which processor these bits are intended for is clear to readers of this thread. What I don't see is a justification for denying the right of freedom in that bit stream for the recipient of the Debian operating system where these bits are redistributed. Note that “only a tiny fraction of the recipients could ever make practical use of the source form of the work” is no justification for denying any recipient the freedom to get that source form; we don't accept that argument for processor code destined for a motherboard CPU, after all. > I'm only trying to explain there are binary only firmware blobs for > most chips, you have them for most of the chips on your motherboard > and in many cases, there is no human readable form. Even the chip > manufacturers don't know what they are. It's totally machine > generated chip garbage as far as they are concerned. What, then, does the chip manufacturer — who, if I understand you correctly, is the copyright holder and vendor of the firmware — have as the means of generating *new* processor firmware targeted to the *same*, already-sold, hardware? I would argue that that form of the work meets the definition of “source code for the firmware”. Yes? -- \ “The best mind-altering drug is truth.” —Jane Wagner, via Lily | `\ Tomlin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
