Calling GPL code from a Python application
Tom Anderson
twic at urchin.earth.li
Wed Jan 4 07:17:24 EST 2006
On Wed, 4 Jan 2006, Mike Meyer wrote:
> Terry Hancock <hancock at anansispaceworks.com> 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?
tom
--
I am the best at what i do.
More information about the Python-list
mailing list