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