Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Henning Makholm wrote:
>Scripsit "David Schwartz" <davids@webmaster.com> [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".
I disagree with you.
>>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.
Starting from the beginning: yes, it's true that linking forms
normally a tighter (functional) coupling between some parts
(caller/callee pairs, etc) of the things linked. But other
that that, and specifically in the case of a firmware blob
embedded in an ELF executable, it's not different from zip
and tgz archival of two different works. After all, there is
no caller/callee interface between the two of them.
>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".
And that is exactly what I argue that an ELF executable with
an embedded firmware to be uploaded is, like a zip/tgz archive
that happens to contain, among other stuff, the firmware.
Notice that I once have argued more completely about the
hermeneutics of the GPL, explaining why I think that the "mere
aggregation" clause 2, para 3 of the GPL is applicable to any
anthology works, because of the dispositions on what is a
derivative "work based on the Program" from clause 0.
>>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.
Hmmm. I still think that the phrase that the precedes what you
just cited, "either the Program or any derivative work under
copyright law", applies even more strongly.
>>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.
I think it does, when in clause 0 it defines << a "work based
on the Program" means either the Program or any derivative
work under copyright law" >>, which is an authoritative
definition, instead of the "that is to say" explanation that
comes after it.
>>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.
And what would be the consequence on this?
HTH,
Massa
Reply to: