Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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.
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
>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.