Use of GPLed Python extension modules

[Patrick Maupin]

Paul Rubin wrote:

> "Rainer Deyke" <rainerd at eldwood.com> writes:
> > Either you are misinterpreting the FSF, or the FSF is wrong.  The
> > FSF has no legal right to restrict the distribution of any software
> > unless that software contains code which is copyrighted by the FSF.
> > Whether the code may be linked to GPL code at runtime or not is
> > irrelevant.  The FSF does have the legal right to restrict the use
> > of its own code, but it chooses not to exercise that right: the only
> > restrictions in the GPL are on the redistribution (not use) of GPL'd code.
> 
> The FSF does not agree with you, but as they say, it's something only a
> court can decide.

Well, the FSF certainly _acts_ like they disagree with Rainer.

Stallman himself has written that a program which dynamically links
with readline violates the GPL even if distributed without readline.
(But as others have noted elsewhere, since purely functional API
behavior cannot be copyrighted, this seems to put the FSF in the
interesting position of saying that if the only implementation of
a particular API is provided by GPLed software, then software which
uses it must also be GPLed, but that this is not a necessity if at
least one other library implements the same API.)

Eben Moglen tries very hard to toe this particular party line as well,
but being a lawyer he tries to do so in a manner which doesn't tell
any explicit lies.  For example, in a Slashdot interview he writes:

"The language or programming paradigm in use doesn't determine
the rules of compliance, nor does whether the GPL'd code has been
modified. The situation is no different than the one where your code
depends on static or dynamic linking of a GPL'd library, say GNU
readline. Your code, in order to operate, must be combined with
the GPL'd code, forming a new combined work, which under GPL
section 2(b) must be distributed under the terms of the GPL and
only the GPL. If the author of the other code had chosen to
release his JAR under the Lesser GPL, your contribution to the
combined work could be released under any license of your choosing,
but by releasing under GPL he or she chose to invoke the principle
of "share and share alike."

A casual reading of this certainly supports the idea that it is
impermissible to write code which uses readline without releasing
that code under a GPL-compatible license, but a closer reading
may lead to a different conclusion.

Moglen admits that the combination of "your code" with GPLed code
is "a new combined work" (implicitly acknowledging that "your code"
is a separate work with no GPLed code in it and thus is not covered
by the GPL until it becomes part of the "new combined work").

He (deliberately IMO) fails to address what happens when the author
of "your code" _declines_ to distribute this "new combined work",
and the rest of the paragraph assumes and reinforces the idea that
OF COURSE the "new combined work" will be distributed intact.

Obfuscatory tactics such as writing "in order to operate, must"
instead of "will not be as functional unless" are there to keep
the reader from noticing that "your code" has transmogrified into
"your contribution to the combined work", and then, to drive
his point home without resorting to any concrete statements which
could be proven false, Moglen concludes with the legally meaningless
but morally high-sounding principle of "share and share alike".

The FSF's goals of wanting to coerce _authors_ into releasing new
code under the GPL, and simultaneously wanting  _users_ to enjoy
"maximum freedom" have led them into a conundrum in this instance.
Since an author is also a user, as long as he is not actually
distributing the GPLed software, e.g. readline, he is free to
_study_ the software on his system, and he is even free to combine
it with his own software (modify it) for his own use as long as he
follows sections 2a and 2c of the license (which are not at all
restrictive).  So it would appear that the FSF has no real legal
ability under the GPL to keep someone from writing and distributing
a package which uses readline, as long as that person does not
simultaneously distribute readline itself.

IMO, disallowing a developer from distributing readline along with
his non-GPLed program which uses readline is perfectly reasonable
and provides gentle guidance to developers that it is much easier
to GPL their programs than to force their users to go out and
download all the parts themselves, but the specious posturing of
trying to claim that any program which could be used in conjunction
with readline must be released under the GPL (see Aladdin Ghostscript)
is not really all that astute.

>  They have stated their willingness to go to court over
> the question.  No one so far has taken them up on it.

So far it hasn't been worth it for anybody.  There are several
reasons for this, such as the "OS exception" in the GPL, and
the willingness of the FSF in some specific cases to negotiate
special licenses.  Basically, for it to be worth it to a company,
they would have to be in all of:

    set "a" -- companies completely dependent on the GPLed
               software in question (otherwise why waste
               time and money litigating the issue?)
    set "b" -- companies big enough to contemplate taking
               on the direct financial burden of a court
               battle with the FSF
    set "c" -- companies which won't be damaged by the bad
               publicity (or which don't care about the damage)

I respectfully submit that the statement "No one so far has taken
them up on it" can be easily explained by the fact that the number
of companies in the intersection of sets "a", "b", and "c" is
vanishingly small...

Pat