Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Humberto Massa <humberto.massa@almg.gov.br>]

David Schwartz wrote:

>>Well whoever wrote that seems to have taken the stand that
>>the openfirmware package was were the firmware came from.
>>The person obviously made a lot of statements without
>>bothering checking out the real source. Well it didn't come
>>from there, I got it from Alteon under a written agreement
>>stating I could distribute the image under the GPL. Since
>>the firmware is simply data to Linux, hence keeping it under
>>the GPL should be just fine.
>
>
>You cannot distribute anything under the GPL if you cannot
>also distribute the source code (the preferred form of the
>software for the purpose of making modifications to it). How
>Linux sees it is irrelevant. For any piece of software, one
>can imagine some processor that can only see it as data.  The
>GPL doesn't distinguish between processors.

I think this is undisputed.

>Alteon's written agreement notwithstanding, you cannot
>distribute the firmware under the GPL if you cannot provide
>the preferred form of the firmware for the purpose of making
>modifications to it. The firmware does not run on Linux, so
>saying "linux sees it as data" is as absurd as saying I can
>distribute the x86 Linux kernel without the source because my
>calculator can only see it as data.
>
>You cannot distribute the firmware binary under the GPL.
>Period.

This is where you are wrong IMMHO. All that is needed for you
to distribute the hexdump blob under the GPL is a declaration
from the copyright holder saying "this, to me, is the
preferred form for modification of the firmware and hence the
source code under the GPL."

>Now, if you were trying to say that you could aggregate the
>firmware with another work and distribute the result under
>the GPL, the test would be whether the final result is "mere
>aggregation" or not.  This is a fantastically tricky question
>and I don't think anyone on this list could give you
>particularly useful guidance.

After a *lot* of discussion, it was deliberated on d-l that
this is not that tricky at all, and that the "mere
aggregation" clause applies to the combination, for various
reasons, with a great degree of safety.  (Safer than that,
only after court) :-)

>My own opinion is that it's a threshold issue based upon
>several factors.  For example -- has the firmware been
>specifically designed to work with the Linux driver or is it
>"generic" firmware? If you can't take the thing you're
>distributing (the combined binary) and extract two works from
>it (the firmware and the work whose source you are offering),
>I cannot see how you can claim it's mere aggregation.

Now, if the firmware was specifically designed to work with
the linux driver, than it *is* a derivative work on the kernel
as a whole and the source code should be provided upon
redistribution as per GPL section 3 etc.

*BUT* this does not preclude Broadcom from stating: "our
engineers generated by hand the hex codes that make our
hardware work."

>If you believe the linker "merely aggregates" the object code
>for the driver with the data for the firmware, I can't see
>how you can argue that any linking is anything but mere
>aggregation. In neither case can you separate the linked work
>into the two separate works and in both cases the linker
>provides one work direct access to the other.

No-one is saying that the linker "merely aggregates" object
code for the driver; what *is* being said is: in the case of
firmware, especially if the firmware is neither a derivative
work on the kernel (see above) nor the firmware includes part
of the kernel (duh), it is *fairly* *safe* to consider the
intermixing of firmware bytes with kernel binary image bytes
in an ELF object file as mere aggregation.

>If you only distribute the source to the driver and don't put
>a GPL notice in the files that contain the firmware data, I
>think you're okay. I think you're asking for trouble if you
>distribute a combined compiled/linked driver.

Disagreed.

>DS

HTH,

Massa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/