Use of GPLed Python extension modules

[Patrick Maupin]

Tim Churches wrote:

> If a compiled Python extension module B includes code from some
> other software A which is licensed only under the GPL, do other
> Python programmes, C,  which import module B also need to be
> licensed under a GPL-compatible license (assuming C is/are to
> be distributed to third parties)? 
> 
> I think the answer is yes, both from a lay (IANAL) legal and
> moral point-of-view, but I am interested in hearing any arguments
> to the contrary. Note that I am talking about the GPL, not the
> LGPL, and the aim is to honour both the copyleft spirit and
> the copyleft legal force of the GPL, not to find clever methods
> of circumventing it.

Even though I am also not a lawyer, it appears to me that the legal
issues are fairly cut and dried, AS LONG AS module B is not included
in the actual distribution of program C.  In this instance,  as I
discuss in another message in this thread, case law (e.g. Sega vs.
Accolade) seems to allow this separate distribution under any license.

As far as I can tell, this is the real legal distinction between the
GPL and the LGPL -- an LGPLed module D could be included with the actual
program C distribution, but module B cannot be included in the distribution.

Ville Vainio questions elsewhere in the thread whether this makes the
GPL useless for libraries.  I think that, from the FSF's point of view,
the GPL is extremely useful for some sorts of libraries, especially
libraries with a lot of functionality which are continuously evolving.
If module B is such a library, the authors of program C would have to
warn their users to retrieve a particular version of module B, to
use the correct compilers on it, etc., while the competing authors of
program E can release their program under the GPL, and include the
correct precompiled version of module B in their distribution.  This
makes the out-of-the-box experience for program E much more pleasant
than for program C, and gently nudges program C's authors in the
"right" direction (again, from the FSF's viewpoint).

As for the moral issue, IMO the distinction the FSF makes between
loosely-coupled and tightly-coupled programs is false.  (Legally,
also, this distinction is false except when the programs are coupled
so tightly they MUST be provided in the same distribution.  In other
words, it is the distribution of GPLed code which offends, not any
technical aspects of how non-GPLed code interacts with GPLed code.)

Since I personally believe that the "closeness" issue is a non-starter
(if C is inoperable unless B is in the system, what does it really matter
how they communicate?) then morally, IMO, coding program C in such a way
that it requires module B is no different than coding it in such a way
that it only runs on Linux.  So if you believe (as some do and as has
been argued in the past) that anything which only runs in conjunction
with Linux must be GPLed, you should feel the same way about program C
using module B, but if you don't believe this, you should release
program C under any license you care to and tell your users to go
download their own copy of module B.

Pat