Calling GPL code from a Python application

[Michel Sanner]

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.

Some the libraries we wrapped using SWIG are under GPL but the
applications we are distributing are not (mainly because
we are asked by funding agencies to keep track of users and hence ask
people to download the source from our site).

A google search about GPL and dynamic linking came up with an equal
number of pages saying that dynamic linking of GPL
code into non GPL applications is allowed as it is the end user who
cretes the derived work, as pages saying the opposite !
So does anyone know what to do about this ?

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 ?

Thanks for any input.

Please reply to (e-mail address removed)

--

-----------------------------------------------------------------------
o
/ Michel F. Sanner Ph.D. The Scripps Research Institute
o Associate Professor Department of Molecular Biology
\ 10550 North Torrey Pines Road
o Tel. (858) 784-2341 La Jolla, CA 92037
/ Fax. (858) 784-2860
o (e-mail address removed) http://www.scripps.edu/~sanner
-----------------------------------------------------------------------

 

[Heiko Wundram]

A google search about GPL and dynamic linking came up with an equal
number of pages saying that dynamic linking of GPL
code into non GPL applications is allowed as it is the end user who
cretes the derived work, as pages saying the opposite !
So does anyone know what to do about this ?

The stance the FSF (and it's lawyers) take on this is that it is illegal to
dynamically link applications that are not under a GPL-compatible license
to GPL works, as you are creating a derived work of the GPL-led library by
using it directly in your runtime environment (that is in the same
process). That's what the LGPL (the lesser or library GPL) is for, which
explicitly permits closed source (amongst other) packages to link to
LGPL-led libraries.

If you call the extension program by os.system(), you are not creating a
derived work, though, as the resulting program might have a runtime
dependency on the GPL-led program, but both never share a runtime
environment (they are seperate processes, and as such you have not created
a derived work of the GPL-led library).

Note that I did never used the term "you must GPL your application" above,
but rather said that it is paramount that your application is under a
GPL-compatible license. See the FSF for more details on what licenses are
compatible (most modern BSD-derived are, e.g.).

--- Heiko.

 

[Paul Rubin]

A google search about GPL and dynamic linking came up with an equal
number of pages saying that dynamic linking of GPL
code into non GPL applications is allowed as it is the end user who
cretes the derived work, as pages saying the opposite ! So does anyone
know what to do about this ?

According to the FSF, it is not permitted under the GPL. Some other
users have a differing opinion. The actual legality may eventually
have to be decided by a court; right now no such decision exists.

Of course, in the case where the GPL'd code's author is ok with what's
being done, it's fine either way (i.e. at worst, the author's
permission exists separately from the permissions granted by the GPL).
In the other case, you're asking to what extent it's legal for the
non-GPL author (typically a proprietary code developer) to thwart the
wishes of the GPL'd code's author and do things not in the GPL spirit.
Since proprietary code developers generally use the copyright system
to avoid having their own wishes thwarted, they're not entitled to
very much sympathy in their desires to construe the GPL to thwart the
wishes of other authors. It's preferable to ask what the GPL spirit
is and act that way, than to aggressively probe its exact legal
boundaries.

 

[Mike Meyer]

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.

Which is a good argument against IP in general, but that's another
issue.

A google search about GPL and dynamic linking came up with an equal
number of pages saying that dynamic linking of GPL
code into non GPL applications is allowed as it is the end user who
cretes the derived work, as pages saying the opposite ! So does anyone
know what to do about this ?

Yes. Ask the holders of the copyright.

The only way to find out *for sure* whether or not a license allows
something is to do that something, get sued about it, and get a judge
to tell you whether or not you violated the license. Different judges
may well give you different answers.

A critical step in that process is getting sued. The copyright holders
have to do that, so you'll need their cooperation for this. Of course,
if they don't think what you're going to do is a violation of the
license, they may not be willing to sue you, in which case you're out
of luck.

If you want an opinion about whether or not you would win such a
lawsuit, ask a lawyer you trust.

If you want to know the intent of the authors, that is that libraries
covered by the GPL would infect programs they are linked with, whether
it's dynamically or statically. The Library (now Lesser) GPL was
created to to allow programs to be linked with LGPL'ed libraries
without infecting the program. If the library in question was released
under the LGPL, the authors of the GPL say you can use it. Otherwise,
they say not. But see the above paragraphs about judges, copyright
holders and lawyers.

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 ?

I'm pretty sure that doesn't violate the GPL. But IANAL, so...

<mike

 

[Mike Meyer]

The stance the FSF (and it's lawyers) take on this is that it is illegal to
dynamically link applications that are not under a GPL-compatible license
to GPL works

I doubt that, because it's simply not true. I can use GPL'ed code any
way I want to - that's part of the point of the GPL. I can change it
however I want, print it in whatever font I want on whatever material
I want, hang the result on the wall, and - most importantly - link it
with whatever other code I want.

What I *can't* do is distribute it (or work derived from it, etc.)
unless the entire work being distributed is under the GPL (unless the
license has changed recently, *not* a GPL-compatible license, but the
GPL itself), and meets the requirements of the that license. In
particular, if I distribute an application that has to be dynamically
linked with a GPL'ed library to run, I need to distribute my
application under the terms of the GPL.

<mike

 

[Peter Hansen]

What I *can't* do is distribute it (or work derived from it, etc.)
unless the entire work being distributed is under the GPL (unless the
license has changed recently, *not* a GPL-compatible license, but the
GPL itself), and meets the requirements of the that license. In
particular, if I distribute an application that has to be dynamically
linked with a GPL'ed library to run, I need to distribute my
application under the terms of the GPL.

Is that really true, precisely as written?

It should be possible to distribute code which does have to be
dynamically linked with a GPL'ed library in order to run *without*
having to distribute under the GPL, provided your distribution *does not
include* the GPL'ed library.

Am I totally misremembering that the terms of the GPL talk only about
*distributing* GPLed code, not about using it, and certainly not about
writing other applications which might require it but which might have
entirely non-compatible licenses.

(Depending on one's definition of "application", you could still be
right because what I describe -- a program that can't run without adding
something else to it first -- might not be considered an application by
some people. I wonder what they'd call it though.)

-Peter

 

[Mike Meyer]

Is that really true, precisely as written?

Well, see my earlier post about how to *really* found out if you're
violating a license. But that is the intent of the GPL.

It should be possible to distribute code which does have to be
dynamically linked with a GPL'ed library in order to run *without*
having to distribute under the GPL, provided your distribution *does
not include* the GPL'ed library.

One would think so. The FSF disagrees. In particular, while they
explicitly state that putting GPL'ed code in a distribution doesn't
require that you distribute the entire distribution under the GPL, if
you then provide instructions on how to create a work derived from the
GPL'ed code from the contents of the distribution, they'll sue you
about it. At least, they sued NeXT when NeXT tried it. Failing to
include the GPL'ed code would seem to be no more a violation of the
letter, and no less a violate of the spirit.

Am I totally misremembering that the terms of the GPL talk only about
*distributing* GPLed code, not about using it, and certainly not about
writing other applications which might require it but which might have
entirely non-compatible licenses.

Correct. Which is why the first sentence of the above paragraph is
"What I *can't* do is distribute it ...". If I statically link a
GPL'ed library with my application, if I distribute it, it clearly has
to be under the terms of the GPL. If I dynamically link the library,
then it's not so clear, but the FSF clearly intends that this be the
same situation. If I fail to provide a library, and the only thing
that could be used is GPLed, it's the same situation. On the other
hand, if I provide a list of acceptable libraries, some GPL'ed, and
some not, then the situation is different, because you're not
depending on GPL'ed code, but allowing your clients to use it. Or
something like that.

(Depending on one's definition of "application", you could still be
right because what I describe -- a program that can't run without
adding something else to it first -- might not be considered an
application by some people. I wonder what they'd call it though.)

I don't think the term "application" is used in the GPL, and I don't
think it has any bearing on IP laws.

But IANAL.

<mike

 

[Steven D'Aprano]

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

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:

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]

 

[Terry Hancock]

If you want to know the intent of the authors, that is
that libraries covered by the GPL would infect programs
they are linked with, whether it's dynamically or
statically. The Library (now Lesser) GPL was created to to
allow programs to be linked with LGPL'ed libraries without
infecting the program. If the library in question was
released under the LGPL, the authors of the GPL say you
can use it. Otherwise, they say not. But see the above
paragraphs about judges, copyright holders and lawyers.

I have to say that in my conversations with developers, the
choice of the LGPL for Python libraries is only a matter of
signalling intent to library-users. All the ones
I've talked to seemed to think that the GPL allows dynamic
linking anyway, but they wanted to avoid any question about
it. Some other authors go ahead and use the GPL but provide
a notice of their interpretation along with the package.

As I read the GPL itself (but I am not a lawyer), it cannot
possibly restrict you from doing this (because your code
does not include a copy of the GPL'd work), and it
explicitly allows you to distribute the GPL'd library with
your application (provided you provide source code and keep
it separated in obvious ways from your own code -- such as
putting it in a separate archive file, etc). That's the
"mere aggregation" clause that allows that.

However, it is true that the FSF is unhappy with this
loophole and would like to pretend it isn't there, so those
warning you that you could get sued are probably right. I
just think that you would be in the right in such a case and
should win.

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.

In order to take away that right (according to the FSF
theory expressed in the preamble of the GPL), you must have
a *contract*, not merely a *license*. Generally if no
consideration was paid (it was zero-cost), and nothing was
signed, there can be no such contract. This is in conflict
with the "click-through" EULA theory, which the FSF denies
is legally binding. Thus their own arguments contradict
their desire to control your use of the software.

Mind you, I'm not necessarily rooting for either side of
this -- I'm just interpreting what I've read. The GPL is
a fascinating read, BTW, and it isn't particularly long. ;-)

Cheers,
Terry

 

[Mike Meyer]

On Tue, 03 Jan 2006 20:48:12 -0500
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. Without that, then there's no point
in obtaining software - you have to get the copyright holders
permission to execute the stuff anyway.

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.

<mike

 

[Steven D'Aprano]

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. Without that, then there's no point
in obtaining software - you have to get the copyright holders
permission to execute the stuff anyway.

Unfortunately, what *we* think isn't worth a plastic nickel. The only
thing that counts is what the relevant copyright laws say.

As far as I know, US copyright law does not give an exemption for
temporary copies in working memory (although I could be wrong about that).
Here in Australia, our government (for once getting it right!)
*explicitly* gives such an exemption to our copyright law. If I recall
correctly, it is worded in such a way that it doesn't matter whether the
temporary copies are in RAM, in a cache, in virtual memory on disk, or
some yet unthought of technology.

This is significant because most proprietary licences that I've read (and
yes, I've actually sat down and struggled through a few of the damn
things) do NOT give you the right to make temporary copies in working
memory, which means that on a strictly legal basis, it is virtually
impossible to run the software without infringing the licence.

(We also have the explicit right to make backup copies of legal software,
although Australian copyright law is firm that this is for backup ONLY,
and not a "backup *nudge nudge wink wink*".

Unfortunately, we've also signed an extremely one-sided pro-USA so-called
"Free Trade Agreement" which forces onto us a whole slew of really bad
Intellectual Property Laws, as well as hamstringing our nation's ability
to govern ourselves. With copyright law being used more and more as an
excuse for enforcing *usage* limitations instead of *copying* limitations,
I can easily see the good parts of our Copyright Act being over-ridden in
de facto (if not de jure).

And for those who don't speak Latin, I mean that having the legal right to
make legal backup copies doesn't help you one bit if the Digital
Restrictions Management software prevents those backup copies from
working when you need them.

 

[Heiko Wundram]

I doubt that, because it's simply not true. I can use GPL'ed code any
way I want to - that's part of the point of the GPL. I can change it
however I want, print it in whatever font I want on whatever material
I want, hang the result on the wall, and - most importantly - link it
with whatever other code I want.

You're nitpicking here, if I may say so. Of course, if you create the
derivative work inside your head, you're not going to distribute it and as
such the GPL distribution clauses don't apply. But: as soon as you write a
program, even for inhouse use (and not distributing it externally), which
will be the norm for a programmer like the OP, you're bound to the
distribution laws of the GPL.

(I guess pretty much nobody programs seriously just to jerk off to how good
he is, everybody wants others to use what he has created)

Anyway, it's not true either that if you link to a GPL-led library, your
work must automatically be GPL. The FSF has specifically endorsed
applications under several other OS-licenses which are basically more
liberal than the GPL to link against GPL libraries. These licenses have to
meet certain criteria, and I'm not exactly sure which, please go and see
the FSF for more info. In case you create an immediate derivative work of
the library (by changing it's sources directly), you have to put the
resulting code under the GPL, of course, if you're going to distribute it.

IANAL. But I've created so many works under a BSD-license that I've made
sure I'm not betting my but on being sued by a GPL-led project. ;-)

--- Heiko.

 

[Karl A. Krueger]

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.

#include <disclaimer.h>

In the U.S. at least, there's a specific statute *exempting* the running
of software (and the making of backups) from copyright protection. That
is, copyright does *not* grant the holder the right to restrain users
from executing a copy of software that they have legally obtained.

http://www.copyright.gov/title17/92chap1.html#117

 

[Karl A. Krueger]

As far as I know, US copyright law does not give an exemption for
temporary copies in working memory (although I could be wrong about that).
Here in Australia, our government (for once getting it right!)
*explicitly* gives such an exemption to our copyright law.

Actually, the U.S. does as well:

http://www.copyright.gov/title17/92chap1.html#117

(We also have the explicit right to make backup copies of legal software,
although Australian copyright law is firm that this is for backup ONLY,
and not a "backup *nudge nudge wink wink*".

An analogous provision exists in U.S. law, indeed in the same chapter
cited above. It also covers copies made in the course of repairing a
computer.

 

[Terry Hancock]

You're nitpicking here, if I may say so. Of course, if you
create the derivative work inside your head, you're not
going to distribute it and as such the GPL distribution
clauses don't apply. But: as soon as you write a program,
even for inhouse use (and not distributing it externally),
which will be the norm for a programmer like the OP,
you're bound to the distribution laws of the GPL.

This is basically bunk. Internally "distributing" the
software (as in making copies within the organization that
created it, or between your disk and RAM, or whatever) is
NOT "distribution" under the law. That's all pretty much
"fair use", and the FSF says as much.

There *has* been a suggestion to add language to GPL 3 to
attempt to restrict such in-house "distribution", but not in
the existing GPL 2.

It is because of this detail that Google has not been
required to release a large amount of their software (which
is based in many cases on GPL'd software, IIRC). A number
of ideas for attacking this kind of use of the GPL in future
versions. And of course, opinion is somewhat divided on
whether that's an "abuse" or just a natural exercise of
"freedom 0".

Given that Google has been using this fact extensively, and
they have not been sued over it, I think it's a fairly
clearly established interpretation, whether it is popular or
not (but of course it's not a legal precedent until somebody
does sue and loses).

 

[Heiko Wundram]

Given that Google has been using this fact extensively, and
they have not been sued over it, I think it's a fairly
clearly established interpretation, whether it is popular or
not (but of course it's not a legal precedent until somebody
does sue and loses).

This is not what the general interpretation of the GPL seems to be with
TrollTech and several other companies. They specifically state that even
when you develop inhouse software with GPL-libraries (Qt in the former
case), you are required to release the code of the application under the
GPL. If this weren't so (and you're the first I hear of that takes this
stance), the GPL would basically be meaningless as a business model to
them, and AFAICT this is also what the FSF tells people.

I'd love to hear Phil Thompson's stance on this as the GPL licensing of Qt
and PyQt has deterred me from creating software using Qt for university
distribution (such as the new interactive testing framework I'm currently
writing). In case in house use is fine with him and them, there's nothing
keeping me from dumping wxPython for PyQt, is there? ;-)

--- Heiko.

 

[Heiko Wundram]

This is not what the general interpretation of the GPL seems to be with
TrollTech and several other companies. They specifically state that even
when you develop inhouse software with GPL-libraries (Qt in the former
case), you are required to release the code of the application under the
GPL. If this weren't so (and you're the first I hear of that takes this
stance), the GPL would basically be meaningless as a business model to
them, and AFAICT this is also what the FSF tells people.

By the way, this is (one of the reasons) why the MySQL client libraries were
licensed under the LGPL and now under a different licensing model with
explicitly permits linking to GPL-incompatible licenses, at least if you
take MySQL AB's word.

See here:

http://www.mysql.com/company/legal/licensing/foss-exception.html

and here (german)

http://www.sunflyer.ch/2004/01/18/MySQL-und-die-Lizenzen.php

And maybe nobody has sued Google so far because they are considered to be
the good guys, generally...?

--- Heiko.

 

[Phil Thompson]

This is not what the general interpretation of the GPL seems to be with
TrollTech and several other companies. They specifically state that even
when you develop inhouse software with GPL-libraries (Qt in the former
case), you are required to release the code of the application under the
GPL. If this weren't so (and you're the first I hear of that takes this
stance), the GPL would basically be meaningless as a business model to
them, and AFAICT this is also what the FSF tells people.

I'd love to hear Phil Thompson's stance on this as the GPL licensing of Qt
and PyQt has deterred me from creating software using Qt for university
distribution (such as the new interactive testing framework I'm currently
writing). In case in house use is fine with him and them, there's nothing
keeping me from dumping wxPython for PyQt, is there? ;-)

My stance is (unsurprisingly) the same as TrollTech's - whatever it happens to
be. When people ask me a specific licensing question, my response is: get
TrollTech's agreement and you'll have my agreement.

Phil

 

[Ernst Noch]

This is not what the general interpretation of the GPL seems to be with
TrollTech and several other companies. They specifically state that even
when you develop inhouse software with GPL-libraries (Qt in the former
case), you are required to release the code of the application under the
GPL.

This is not true, and a often misunderstood issue w.r.t. to Trolltech/QT.

From the FAQ:

Entry number: 123 - I want to dual license my software too! That means I
can use the Open Source edition for development, right?

"""
No. In order to write software that will be sold or licensed
commercially, in addition to open source, all of your programmers will
need a commercial license from the outset of the development phase.

If you use the Open Source edition of Qt, you can only publish the
software under the GPL. Trolltech's commercial license terms do not
allow you to develop any proprietary software using the Open Source edition.
"""

What happens is that the Commercial License prohibits that it is
"transfered" to software developed with the GPL Version.

 

[Heiko Wundram]

This is not true, and a often misunderstood issue w.r.t. to Trolltech/QT.

From the FAQ:

<snip>

I can't see how that FAQ entry is relevant to the discussion here, actually.

I've asked TrollTech more than once for their stance on this, and each time
they have told me that it's illegal for me to develop an inhouse
application (such as a frontend to some webapp I've written that's only
used by us and will never ever be given away commercially) using the Open
Source edition of Qt (which I have not commercially licensed, of course,
which is way to expensive for me and Uni won't pay), unless I convince the
people at my univ to _release_ the code I've written under a GPL-compatible
open source license itself.

From what Phil Thompson has written (basically go ask TrollTech), I can't
see that this licensing restriction has become milder in any way. And QT is
licensed under a vanilla GPL (amongst the TrollTech public license), which
I guess makes my point in saying that this is a general property of the
GPL. From what I've read by Mr. Moglen, he's just taking the same stance.

--- Heiko.