[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#239952: kernel-source-2.6.4: qla2xxx contains non-free fi rmware



Hamish Moffatt wrote:
On Sat, Mar 27, 2004 at 02:24:27PM +0000, Matthew Garrett wrote:

Hamish Moffatt wrote:

Perhaps we need a set of complete kernel packages in non-free then.

The problem is that the GPL requires us to be able to provide the
preferred form for modifications for the entirity of the code. Realistically, there's no way that the majority of this firmware is the preferred form for modification. As a consequence, unless
we receive exemption from every copyright holder in the kernel,
we have no legal right to distribute kernel images with this
firmware linked in.

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.

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:
>
>> I'm assuming that the opinion of the copyright holder, being the
>> licensor, is governing here.  If the copyright holder comes out
>> and says explicitly, "Yes, it really *is* the preferred form for
>> modification," then we have no problem.  If they say, "no, it
>> isn't," then we can't distribute it (the GPL is the only license
>> to distribute, and we don't have the preferred form for
>> modification).
>
> So far, I agree 100%, but...
>
>> Otherwise, we have a sort of burden-of-proof issue.  I think if
>> most people, looking at, go "that's not the preferred form for
>> modification", then we should assume that it isn't, until we get
>> clarification.  You're assuming that by distributing it, the
>> copyright holder is *implying* that it's the preferred form for
>> modification.  I think my interpretation is safer. :-)
>
>
> ?! 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



Reply to: