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

[Henning Makholm]

Scripsit "David Schwartz" <davids@xxxxxxxxxxxxx>
[quoting me]

>> No, it is completely wrong to say that the object file is merely an
>> aggregation. The two components are being coupled much more tightly
>> than in the situation that the GPL discribes as "mere aggregation".

>         Would you maintain this position even if the firmware is identical
> across operating systems and the Linux driver is identical across different
> firmware builds for different hardware implementations?

Yes I would. Linking forms a tighter coupling than just placing the
two parts side by side on a filesystem designed for general storage of
byte streams. There is more to say about the situation than the naked
fact that that they are aggreated on the same medium; ergo the
sutiation does not constitute *only* aggregation, and the "mere
aggregation" language of the GPL does not apply.

In particular, the end of GPL #2 does not provide a blanket exception
for all forms of aggregation; it specifically speaks about aggregation
"on a volume of a storage or distribution medium".

>         Note that the issue is not whether the GPL describes this as "mere
> aggregation" because the GPL doesn't get to set its own scope.

The scope of the copyright of the original work includes situation
where part of that original work is being copied (excluding fair use
and other jurisdiction-specific exceptions). In order to do such
copying, you need permission from the copyright holder of the original
work. If all the permission you have is the GPL, the copyihg you are
doing had better fall into the class of copying that the GPL provides
a permission for.

It *is*, therefore, relevant, whether the GPL's special conditions for
works "that in whole or in part contains the Program" apply to the
linked object files.

> The issue is whether the resulting binary is a single work (that is
> derivative of the GPL'd driver) or whether it's two works with a
> license boundary between them.

A reasonable person can disagree about whether the word "work" in GPL
#2(b) is meant to exclude non-trivial aggregations that do not add
creative choice to that already expressed in the components.

However, I don't think a reasonable person can argue that even if 2(b)
had said "byte stream" instead of "work" it would not have been
legally potent to demand GPL-compatible licensing of the firmware as a
condition for the permission to copy the GPL-covered part of the byte
stream.

>         It would not be obviously unreasonable to argue that the NE2000 API
> constitutes a license boundary between the two works, each of which stays on
> its own side of that API.

No, it wouldn't be obviously unreasonable for a license to recognize
such a "license boundary". However, as I see it the GPL happens not to
do this.

>         Lacking clear court guidance, I see it as a threshold issue. One
> primary issue (I think) is to what extent that firmware and the driver have
> been customized for each other. A work that is carefully designed to mesh
> tightly with another work is analogous to a sequel, which is a derivative
> work.

I think the "derivative work" angle is a red herring. I do not think
that either of the two parts that are being linked together (i.e. the
driver and the firmware) are derivates of the other.  The relevant
point is that distribution of the linked _result_ is nevertheless
subject to the condition in GPL #2, which is in general the only
source we have for a permission to distribute a non-verbatim-source
form of the driver.

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