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('GPL app')" 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 sa****@scripps. edu

--

-----------------------------------------------------------------------
o
/ Michel F. Sanner Ph.D. The Scripps Research Institute
o Associate Professor Department of Molecular Biology
\ 10550 North Torrey Pines Road
o Tel. [phone] La Jolla, CA 92037
/ Fax. [phone]
o sa****@scripps. edu http://www.scripps.edu/~sanner
-----------------------------------------------------------------------

[Heiko Wundram]

Michel Sanner wrote:

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]

Michel Sanner <sa****@scripps .edu> writes:

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]

Michel Sanner <sa****@scripps .edu> writes:

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('GPL app')" 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 <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Heiko Wundram <mo*******@bi t-bukket.org> writes:

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
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Peter Hansen]

Mike Meyer wrote:

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 "applicatio n", 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]

Peter Hansen <pe***@engcorp. com> writes:

Mike Meyer wrote:

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?

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 "applicatio n", 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 "applicatio n" is used in the GPL, and I don't
think it has any bearing on IP laws.

But IANAL.

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[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('GPL app')" 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.

[Terry Hancock]

On Tue, 03 Jan 2006 20:48:12 -0500
Mike Meyer <mw*@mired.or g> wrote:

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

--
Terry Hancock (ha*****@Anansi Spaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Mike Meyer]

Terry Hancock <ha*****@anansi spaceworks.com> writes:

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
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.