Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
<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
Reply to: