| Humberto Massa 2004-03-29, 10:35 am |
| Hamish Moffatt wrote:
> On Sat, Mar 27, 2004 at 02:24:27PM +0000, Matthew Garrett wrote:
>
I disagree with the phrase "Realistically, there's no way that the
majority of this firmware is the preferred form for modification." and
I am pasting other message below, to say why. And more, I think
legally, as the copyright owner pasted the thing in a file licensing
it under the GPL, we *must* assume its the pf4m.
[color=darkred]
> I see your point, but I'm confused by one example. Intel provides
> the e100 driver in the kernel source, clearly licensed under the
> GPL (there's a whole copy of it in the e100 directory in the kernel
> tree). Intel also provides a hex dump of new microcode for the
> hardware. Clearly the hex dump isn't the preferred form of
> modification, but clearly Intel intends us to be able to distribute
> kernel images containing that firmware.... So where does that
> leave us?
>
>
> Hamish
Here, trying to complement it:
Humberto Massa wrote:
> Nathanael Nerode wrote:
>
>
> So far, I agree 100%, but...
>
>
>
> ?! That's the part I have difficulty understanding. As I have said
> here before, there is no mistake in things unsaid... the code is
> there, the copyright in in the top of the file, the license is
> there *saying* to you it's GPL licensed, the origin of the blob is
> nowhere in sight. _The only possible conclusion_ is that it's the
> pf4m (=preferred form for modification). If asked and not
> responded, _the only possible conclusion_ is that it's the pf4m.
> It's only the opposite if the copyright holder (Qlogic, IBM,
> whoever) says "no, we have a XX assembly file around here, but we
> won't show you." /Then/ it's undistributable. Until then, if it's
> in a file, with valid copyright assignment and license, we _must_
> assume it's the pf4m IMHO.
>
> If I had not said enough, I will give you some insight of why I
> think that way. Some 15 years ago, I worked in a software shop and
> I had to write some driver to a piece of hardware (a point-of-sale
> terminal). In our software, we had to send a sequence of commands
> to the gadget, all in one package (see the resemblance with a
> firmware program?). Neither the maker of the gadget nor I came
> around to get some time to document it, it's format, and we shipped
> the program with this in the source code:
>
> unsigned char commands_to_pos[] = { 0x032, 0x034, 0x045 };
>
> :
> :
> send_to_pos(command_to_pos);
> :
> :
>
> *and nobody never ever documented* or made any effort to make some
> code-generator to it. If there was any bug in the blob, only I
> (that had spend some of my youth in trial-and-error with the thing)
> could fix it. I don't doubt some more low-profile hardware maker
> has _the very same issue_, i.e., they have some guy who made their
> flashable codes, nobody can generate it, nobody modifies it (*),
> and that was it. if you _needed_ to modify it, the 0x0... is the
> preferred form. Because of this /personal/ experience I think the
> /legal/ approach is to assume the blob is the pf4m _till proven
> wrong_.
>
> (*) and, there is more: I had a case of a specific model which, if
> you modified anything, the thing did not work at all!! For any
> modification!! I tried every single-byte, slight, no-op,
> modification you can think of and the thing did not came online
> unless I used the One and Only incantation for it to work. I would
> not rule /that/ out, either :-)
>
> HTH,
That it, the burden of proof in *on the person who doubts* the binary
blob is the pf4m. Not on the copyright holder, that, if silent, is
saying: "this is the pf4m." period. prove otherwise. Nobody can't
*assume* otherwise, *think* otherwise, or *be of opinion* that this is
not the case.
Debian can remove the blob, if it still wants to, but to justify it
with legality is *a lie*. _Until proven otherwise_, the file is GPL'd,
and it's free sofware as in DFSG-free software. And the source code
(the pf4m) is there.
--
br,M
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|