Henning Makholm wrote:
>Scripsit "David Schwartz" <[EMAIL PROTECTED]> [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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
