Calling GPL code from a Python application

[Steven D'Aprano]

On Tue, 03 Jan 2006 16:36:31 -0800, Michel Sanner wrote:

> Hello,
> 
> One of the greatest feature of Python in my opinion is the way the 
> interpreter can be used to integrate a wide variety of
> software packages by dynamically linking them.  This approach has been 
> extremely successful for us so far but now I run
> into a license nightmare.

Various other people on the newsgroup have given varying advice. I can
only say: Why are you asking us? If you want legal advice, speak to a
lawyer. 

At the very least, the best (if not only) canonical source of the GPL's
intention is gnu.org, not random googling for random thoughts by random
people, many of whom have bees in their bonnet about what they
(mis)understand the GPL to say.

In particular:

http://www.gnu.org/licenses/gpl-faq.html

[quote]

Q: If a library is released under the GPL (not the LGPL), does that mean
that any program which uses it has to be under the GPL? 

A: Yes, because the program as it is actually run includes the library. 

...

Q: Can I release a non-free program that's designed to load a GPL-covered
plug-in? 

A: It depends on how the program invokes its plug-ins. If the program uses
fork and exec to invoke plug-ins, then the plug-ins are separate programs,
so the license of the plug-in makes no requirements about the main program. 

If the program dynamically links plug-ins, and they make function calls to
each other and share data structures, we believe they form a single
program, which must be treated as an extension of both the main program
and the plug-ins. In order to use the GPL-covered plug-ins, the main
program must be released under the GPL or a GPL-compatible free software
license, and that the terms of the GPL must be followed when the main
program is distributed for use with these plug-ins.

If the program dynamically links plug-ins, but the communication between
them is limited to invoking the `main' function of the plug-in with some
options and waiting for it to return, that is a borderline case.

[end quote]


If you work must _link_ to the libraries in question (as opposed to
merely executing them), then it seems to me that your best bet would be to
ask the copyright holder(s) of the libraries you want to use for a licence
compatible with your needs. You may consider explaining why you can't use
the GPL, and if need be you might consider paying them for a non-GPL
licence. After all, if you can't use their libraries, you would have to
either licence somebody else's work, or pay somebody to develop something
for you.

(Just because programmers release work under the GPL doesn't mean they
won't do work for pay.)



> The second question I would like to get an answer for is whether doing
> an "os.system('GPLapp')" violates GPL if I ship my Python code that does
> the os.system call and the GPLapp program ?

Again, see the FAQs:

[quote]

Q: What is the difference between "mere aggregation" and "combining two
modules into one program"? 
A: Mere aggregation of two programs means putting them side by side on the
same CD-ROM or hard disk. We use this term in the case where they are
separate programs, not parts of a single program. In this case, if one of
the programs is covered by the GPL, it has no effect on the other program. 

Combining two modules means connecting them together so that they form a
single larger program. If either part is covered by the GPL, the whole
combination must also be released under the GPL--if you can't, or won't,
do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes,
rpc, function calls within a shared address space, etc.) and the semantics
of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run linked
together in a shared address space, that almost surely means combining
them into one program.

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.

[end quote]


-- 
Steven.