Calling GPL code from a Python application

Tom Anderson twic at
Wed Jan 4 07:17:24 EST 2006

On Wed, 4 Jan 2006, Mike Meyer wrote:

> Terry Hancock <hancock at> writes:
>> It is interesting to note that the FSF holds the position that the 
>> language that "gives you this right" *doesn't* -- it just clarifies the 
>> fact that you already hold that right, because it is provided by "fair 
>> use".  Their position is that it is not possible to restrict the *use* 
>> of software you have legally acquired, because copyright only controls 
>> copying.
> I believe there is precedent that contradicts the FSF's
> position. There are two arguments against it:
> 1) Executing software involves several copy operations. Each of those
>   potentially violate the copyright, and hence the copyright holder
>   can restrict execution of a program.
> 2) Executing a program is analogous to a performance of the software.
>   Copyright includes limits on performances, so the copyright holder
>   can place limits on the execution of the software.
> Personally, I agree with the FSF - if own a copy of a program, executing 
> it should be fair use.

I'm with you - i don't accept either of those legal arguments. The copying 
that copyright talks about is the making of copies which can be 
distributed - copies which are the equivalent of the original. It doesn't 
mean the incidental, transient copies made during use - otherwise, it 
would be illegal to read a book, since a copy of the text is transiently 
made in your visual cortex, or to listen to a record, since a copy of the 
music is transiently made in the pattern of sound waves in the air. The 
performance that the law talks about is not like execution, but is 
communication, and so a form of copying - by performing a play, you're 
essentially giving a copy of the text to the audience. Executing a program 
doesn't communicate it to any third parties.

Of course, in practice, it matters rather little whether i accept either 
of those, since i'm not a judge trying the relevant test case!

> While I'm here, I'll point out the the "address space" argument is 
> specious. What if I bundle a standalone GPL'ed application with my own 
> application, and distribute binaries for a machine that has a shared 
> address space? By that criteria, I'd have to GPL my code for the 
> distribution for the shared address space machine, but not for a Unix 
> system. I'm not buying that.

I also agree that the address space thing is bunk. What if i write a 
CORBA/RPC/COM/etc wrapper round some GPL'd library, release that under the 
GPL, then write my non-GPL'd program to access the wrapped library via a 
socket? Or if i write a wrapper application that takes a function name and 
some parameters on the command line, calls that function, and writes the 
result to stdout, then access it via popen? I get the use of the library, 
without sharing its address space!

On the flip side, we could argue that an application which uses a dynamic 
library *is* a derivative work, since we need a header file from the 
library to compile it, and that header file is covered by the GPL. What 
happpens when you compile with a non-GPL but compatible header (say, one 
you've clean-roomed) but link to a GPL library at runtime, though?


I am the best at what i do.

More information about the Python-list mailing list