On Tue, May 27, 2003 at 05:11:21PM -0400, Nathanael Nerode wrote: > Steve Langasek wrote: > >This assumes that the FSF's interpretation depends on the claim that > >dynamic linking creates a derived work. While varies parties have > >claimed this at one point or another, I have argued that the > >dynamically linked work is under the purview of the GPL by virtue of > >the license terms alone, *if* you are distributing the GPL library in > >question, which is always the case for Debian. > Well, this statement is simply wrong, and I'll devote the rest of this > email to explaining why. > If the dynamic linking does *not* create a derived work, you are > distributing two works: > A. The new program which links to the GPL'ed library > B. The GPL'ed library which is linked to > Not one work. A "mere aggregaton" of two works. It is not "mere aggregation", for the same reason that a bug in a library that makes it unusable by applications is a grave, not a critical, bug: one piece of software is not "unrelated" to another if the former depends on the latter. This may or may not make the one work a derived work of the other, but it does mean we're dealing with something more than mere aggregation, because the application references the library at several levels: in the ELF header, in the form of undefined symbol references, and in the Depends: line of the package itself. If removal of foo makes bar unusable, the combination of the two cannot be considered mere aggregation. > Under the GPL, the library B is distributable under section 3, using > either the written offer (b) or the distribution of source code (a), and > the source code for the library can be distributed under section 1. > There is no restriction on the distribution of B with other works. In > fact, there's an explicit statement that there's no such restriction > (Section 2, final paragraph). So the GPL imposes no restriction on the > distribution of A and B together. Note carefully that *all* the > restrictions in the GPL (except for the very mild section 1 > restrictions) are stated in terms of "incorporating parts of the > Program", "as part of a whole which is a work based on the Program", > etc., all of which are terms refering to the creation of a derived work. Not all: the terms of section 3 talk about covered source code in very broad terms of "all modules [the work] contains". Can you expand on your understanding of this phrase? One possibility that I had not thoroughly considered is that in the case of an application, "all modules" includes any libraries referenced by the application; but that in the case of a library, "all modules" does not include any applications which use that library, because the *library* which is GPLed does not encode any information pointing to the applications. I'm not sure I like this asymmetry (I'm pretty sure it isn't the FSF's intention), but I'm also not sure I can make a convincing argument against this interpretation. The best I can muster is that it conflicts with the FSF's public interpretation of the GPL, which *could* be seen as significant in a court case. > Furthermore, it is not within the rights of the copyright holder to > decide unilaterally what constitutes a derived work. I believe that is > considered to be a matter of facts, to be established by court cases and > precedents. Certainly. > Respecting the FSF's *opinion* that dynamic linking creates a derived > work is perfectly sensible and wise. (Hey, they could be legally > correct!) Claiming that the GPL somehow imposes itself on works linked > with even if linking *doesn't* legally create a derived work is just > plain wrong. Noted. I've come to believe that the basis for claiming the application is a derived work in these cases is very weak, but it still seems prudent to treat dynamically-linked works as covered by the GPL's source code requirements for the time being. -- Steve Langasek postmodern programmer
Attachment:
pgphB4oZVaQ_6.pgp
Description: PGP signature