Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/8/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
> 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.
I belive this step is unnecessary.
The only time a collective work is not a derivative work is when the
the collective work lacks sufficient originality under copyright law
to be granted separate copyright protection.
Since the GPL is a license grant, it can be construed to only apply
where license needs to be granted.
> 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?
That's not how I construe the mere aggregation clause. Mostly
because you've added a lot of details which need not be
relevant.
> 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.
I agree that this paragraph fairly accurately conveys the intent
of that clause. It would be easier to read if you'd left out the
editorializing, and I'm not commenting on the accuracy of most
of what you've written here.
> 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.
In essence, yes.
> 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.
That's pretty much what the FSF has done -- they've granted
explicit exemptions on on the outputs of these programs. Though,
again, your editorializing detracts from stating these issues
clearly.
> 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.
I've no opinion on this issue -- I've not studied it.
> 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.
This doesn't seem to be put together logically. Appearing in VM
seems to me to fall under mere aggregation unless there's also
some specific use of non-exported functionality.
> 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.
Huh?
> 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.
This seems to be based on a concept of "derivative works" which
is at odds with that held by the U.S. Copyright office.
I highly recommend you read circular 14, and pay particular
attention to the examples which use the phrase "based on".
--
Raul
Reply to: