Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit "David Schwartz" <[EMAIL PROTECTED]> >> However, then you cannot legally copy it at all, because it contains >> part of the original author's copyrighted work and therefore can only >> legally be copied with the permission of the author. > The way you stop someone from distributing part of your work > is by arguing that the work they are distributing is a derivative > work of your work and they had no right to *make* it in the first > place. See, for example, Mulcahy v. Cheetah Learning. You don't need to argue that the thing being distributed is a derivative work. It is enough that it _contains_ your copyrighted work. > My point is that the reason the derivative work issue is so > important is because it's the only way (in U.S. law anyway) that the > GPL can apply to anything other than the exact thing the author > chose to apply it to. The taske of the GPL is to _give permission_ when certain conditions hold. Therefore, if the GPL does not apply yet you still need permission from the author (beacuse what you're distributing contains his work), then you do not have that permission and cannot distribute _at all_. I'm not sure whether meant instead that the original _copyright_ only influences things that are derivative works, but that would have even more bizarre consequences. > The GPL applies to distributing a Linux binary I just made even > though nobody ever chose to apply the GPL to the binary I just made > only because the binary I just made is a derivative work of the > Linux kernel, and the authors of that work chose to apply the GPL to > it. How can the binary be a derivative work when it does *not* contain firmware, but suddenly cease to be a derivative work if one *does* add firmware into it? -- Henning Makholm"Vi skal nok ikke begynde at undervise hinanden i den store regnekunst her, men jeg vil foreslå, at vi fra Kulturministeriets side sørger for at fremsende tallene og også give en beskrivelse af, hvordan man læser tallene. Tak for i dag!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit David Schwartz [EMAIL PROTECTED] However, then you cannot legally copy it at all, because it contains part of the original author's copyrighted work and therefore can only legally be copied with the permission of the author. The way you stop someone from distributing part of your work is by arguing that the work they are distributing is a derivative work of your work and they had no right to *make* it in the first place. See, for example, Mulcahy v. Cheetah Learning. You don't need to argue that the thing being distributed is a derivative work. It is enough that it _contains_ your copyrighted work. My point is that the reason the derivative work issue is so important is because it's the only way (in U.S. law anyway) that the GPL can apply to anything other than the exact thing the author chose to apply it to. The taske of the GPL is to _give permission_ when certain conditions hold. Therefore, if the GPL does not apply yet you still need permission from the author (beacuse what you're distributing contains his work), then you do not have that permission and cannot distribute _at all_. I'm not sure whether meant instead that the original _copyright_ only influences things that are derivative works, but that would have even more bizarre consequences. The GPL applies to distributing a Linux binary I just made even though nobody ever chose to apply the GPL to the binary I just made only because the binary I just made is a derivative work of the Linux kernel, and the authors of that work chose to apply the GPL to it. How can the binary be a derivative work when it does *not* contain firmware, but suddenly cease to be a derivative work if one *does* add firmware into it? -- Henning MakholmVi skal nok ikke begynde at undervise hinanden i den store regnekunst her, men jeg vil foreslå, at vi fra Kulturministeriets side sørger for at fremsende tallene og også give en beskrivelse af, hvordan man læser tallene. Tak for i dag! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit "David Schwartz" <[EMAIL PROTECTED]> >> 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. > If the thing distributed is not the covered work and not a > derivative work, why does the GPL apply to it at all? You are free to not apply the GPL to it. However, then you cannot legally copy it at all, because it contains part of the original author's copyrightedwork and therefore can only legally be copied with the permission of the author. -- Henning Makholm "The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit David Schwartz [EMAIL PROTECTED] 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. If the thing distributed is not the covered work and not a derivative work, why does the GPL apply to it at all? You are free to not apply the GPL to it. However, then you cannot legally copy it at all, because it contains part of the original author's copyrightedwork and therefore can only legally be copied with the permission of the author. -- Henning Makholm The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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". > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Humberto Massa <[EMAIL PROTECTED]> > 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. When was this alleged conclusion reached? I remember nothing like that. > 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. 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". -- Henning Makholm "Hør, hvad er det egentlig der ikke kan blive ved med at gå?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Humberto Massa [EMAIL PROTECTED] 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. When was this alleged conclusion reached? I remember nothing like that. 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. 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. -- Henning Makholm Hør, hvad er det egentlig der ikke kan blive ved med at gå? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
