GPL and Python modules.

[Cliff Wells]

On Tue, 2004-10-26 at 08:37 +1000, Tim Churches wrote:
> On Tue, 2004-10-26 at 01:16, Grant Edwards wrote:
> > Let's say I use a GPL'd python module (e.g. something installed
> > in site-packages) in an application.
> > 
> > Let's also say I use py2exe to package and distribute said
> > application.
> > 
> > Is what I'm distributing a "derived work" of the GPL'd python?
> > Or is py2exe's packaging of the module's .pyc file and my
> > application code's .pyc files a "mere aggregation" so that I
> > only have to provide source code for the GPL'ed module and not
> > for my application code?
> 
> See the GPL FAQ at
> http://www.fsf.org/licenses/gpl-faq.html#MereAggregation :

If this interpretation is true, then I suppose I'm going to have to
reassess my position on the GPL and agree with Microsoft <gasp> that the
GPL is "viral".  I had always dismissed this claim as pure FUD, but the
following gives pause:

'''                
By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are
used for communication, the modules normally are separate programs. But
if the semantics of the communication are intimate enough, exchanging
complex internal data structures, that too could be a basis to consider
the two parts as combined into a larger program.
'''

If this is true, I can't think of any way for a program to run on a
GPL'd system (such as Linux) without becoming GPL'd itself (Unless it
doesn't do any I/O or malloc any memory <wink>).  While it's true that
the LGPL is far more lenient in this regard (and is used by many system
libraries, along with the BSD license), the LGPL is also now disdained
by the FSF and *might* not be used universally by the long chain of
libraries/system calls any non-trivial application might inadvertently
use.  The bottom line is that any developer of GPL'd software on that
platform is going to need to review every single library that the
program might use.  It also raises questions about what the GPL means
when calls are made into the (GPL'd) kernel.  If I malloc some memory
(via libc) and libc calls into the kernel, how does that affect me?
Clearly the linkage is "intimate" as I doubt the memory will be passed
to my program via a pipe or command line argument <wink>.  Does libc
(which I believe to be LGPL or at least provides a clause for linking)
somehow "launder" the licensing of the kernel call before it gets to my
program?

Now, I know that in practical day-to-day terms, this means little.
Linus clearly has no intention of preventing closed-source apps from
running on Linux.  Nevertheless, to a corporate attorney reviewing this
sort of thing, it would seem clear that non-GPL apps cannot easily exist
on Linux.

Suddenly thinking that BSD-style licenses might be better after all...

Regards,
Cliff

-- 
Cliff Wells <clifford.wells at comcast.net>