<mode sarcasm="on" degree="not-so-mild-anymore" aimed-at="not-Raul-(mostly)">
Actually, Raul, I'm impressed. You have found enough ambiguities in the GPL to exhibit a way to construe limits on dynamic linking and packaging dependencies that are not far from the FSF FAQ's prescriptions and Debian's current practices -- though by a completely different logical path. Namely: 1. Ignore the meaning of "derivative work under copyright law", in fact strike out the either/or phrase in Section 0 altogether, and take instead the paraphrase "a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language". That's a gross distortion of the grammar of that sentence, and replaces language with a definite, indisputable legal meaning with an incorrect paraphrase, but that's OK -- RMS says he could have sworn that he read somewhere that that's what "derivative work" meant in the first place. And it's not like it's his counsel's job to explain otherwise to him -- this doesn't come up in law school or anything. 2. Construe "mere aggregation" in section 2, out of thin air, to mean "coexistence as separate 'files' -- no smaller (contiguous byte ranges), no larger (entire CD images) -- within the innermost object on a volume of a storage or distribution medium that can be 'mounted' as a distinct 'filesystem'". And while you're at it, make it apply to in-memory copies at run-time too, so that it's a sort of contributory infringement on the distributor's part for one file to contain annotations which cause another with a conflicting license to be loaded together with it at run-time -- but not if it's in a separate process address space. Oh, and that's also OK if one file is the Program and another the data on which it operates -- even if that data is itself program text under a different license. That should be obvious to anyone, right? 3. Read the "mere aggregation" clause, not as an afterthought to reassure people that the drafter didn't intend to stop them from using GPL works on Unix systems or putting them together on a distribution tape with other stuff (which is the actual history as I have read it), but as a limit on what subset of "works based on the Program" Section 2 is actually intended to cover. It's in the wrong place for that (at the end of the section after all of the conduct options have been prescribed), but never mind that -- standards of clarity in grammar and organization don't apply to the GPL. This isn't a contract, it's a revolution -- see the 1710 Statute of Anne for details! Implicitly rewrite each paragraph in Section 2 as if it contained the "mere aggregation" exception. 4. Extend the "mere aggregation" exception implicitly to Section 3, since it contains the parenthetical comment "(or a work based on it, under Section 2)" in place of the exact phrase "work based on the Program" that was defined in Section 0. Don't worry about Sections 5 and 6, which use the phrase "work based on the Program" unqualified, since there's at least one way to read them in which they would have the same meaning whether or not the "mere aggregation" exception applies. 5. What do you do when the implications of this construction for any particular piece of FSF software (such as gcc, flex, bison, glibc, classpath, ...) are too strict? Fudge the license for that particular piece of software until enough people put aside their reservations and start using it. The FSF of course can do that because they follow a strict copyright assignment policy -- none of this "retain copyright and use the GPL so no one else can weaken it" business for FSF contributors! Make sure to put in language allowing this fudge to be "upgraded" to the GPL so you aren't hoist on your own petard, and discourage other people from using the fudge on their own programs. Oh yeah, use different fudges on different programs so that they can only be combined under the GPL. And make sure to keep GNU readline GPL so that you have an anecdote about how you succeeded in intimidating somebody way back when into releasing something under the GPL because they were foolish enough to use your readline implementation instead of somebody else's. 6. What do you do when people start using their liberty under your existing licenses of redistributing only the bits they want out of your software and documentation, omitting your political speeches (except the one that you've bolted onto the license itself)? Reissue under a license (the GFDL) that says they can't do that! What about the rest of your contributors? Who cares, they assigned their copyright to you (see above) -- they must have trusted you to do whatever you want with their work. Oh yeah, make sure people can't get around it by "upgrading" to the GPL -- if they want to copy and paste back and forth between program and documentation, they're going to have to do so under the FSF's wing. 5. The Debian CD set contains lots of non-GPL material that can be pulled into a process's address space at run-time along with some piece of GPL material. Hmm, how do we offer all of those run-time "works" under the GPL so that we dodge that "contributory infringement" bullet? I know -- implicitly offer every "work" containing GPL material that can be constructed at run-time from Debian packages under the GPL, in addition to whatever less restrictive license the other bits are documented as having. That way the end user has the option of accepting the GPL on, say, the net-snmp libraries when they form part of a "work based on the Program (but not formed by mere aggregation)", such as when they happen to be running inside Quagga, and also of accepting their upstream license when they're running inside a net-snmp command-line tool. Don't bother identifying which components are implicitly dual-licensed this way; everyone knows which licenses can be "upgraded" to the GPL, and they must know that's what you meant because otherwise you wouldn't have been permitted to release Debian CDs at all. 8. What about the "automatic termination" clause, which has of course magically happened to Debian a zillion times over (such as when Quagga got built against net-snmp on some Debian autobuilder and thus against libssl)? Oh, don't worry about that -- we only use that to try to club people whom we don't like because they don't construe our license the same way. </mode> OK, so there's a way to construe the GPL to ban dynamic linking to non-GPL-compatible material. Completely far-fetched, in my view. But I think I'll stick to the contention that contracts are to be construed against the offeror and that it is my, perfectly reasonable, interpretation that the outermost boundary of a "work based on the Program" is the smallest identifiable self-contained work of authorship (such as a library with a published API) that is itself a derivative work of the Program. Build bigger programs based on this block any way you want, linking statically, dynamically, and Republicratically. Any other customarily observed limitation is a matter of conflict avoidance and courtesy to the FSF in homage to the role it once played in opening up the software commons. Cheers, - Michael
