By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,364 Members | 1,518 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,364 IT Pros & Developers. It's quick & easy.

python and gpl

P: n/a

I have a question about what it takes to trigger GPL restrictions in
python code which conditionally uses a GPL library.

Here is the context of my question. matplotlib, which I develop, is a
plotting module which is distributed under a PSF compatible license,
and hence we avoid using GPLd code so as to not trigger the GPL
requirements. matplotlib has rigid segregation between the front end
(plotting commands, figure objects, etc) and backends (gtk, wx, ps,
svg, etc). The backend is chosen dynamically at runtime -- eg the
same python script could trigger the import gtk, wx, or ps, depending
an some rc settings or command line opts.

The question is: does shipping a backend which imports a module that
links with GPL code make some or all of the library GPL. This
question is complicated, in my mind at least, by several factors.

Here are some sub-questions:

* If a backend module somebackend does

import somelib

where somelib is a python wrapper of GPL code, is somebackend
GPLd?

* Assuming the answer to the above question is yes, is matplotlib
GPLd if it distributes somebackend? I think this is a nuanced
situation because matplotlib would work just fine w/o somemodule,
and only uses somemodule's code if it is selected at runtime by
the user. Ie, no other part of the code depends on it since it is
one of many interchangeable backends.

* To further complicate the question, the backend in question is qt,
which is dual licensed, commercial and GPL. The qt backend code
just needs to 'import qt', and neither the backend writer nor the
matplotlib frontend knows whether the deployed qt on the system is
commercial or GPLd. To date, the only GPL-like backend is GTK,
which is LGPL. Since we're only linking and not using the src,
we're protected from the GPL requirements. With QT, which has a
pure (non L) GPL variant, the situation is less clear to me.

Thoughts, links, etc, appreciated...
JDH
Jul 18 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On Sun, 30 Jan 2005 22:25:10 -0600, John Hunter wrote:
The question is: does shipping a backend which imports a module that
links with GPL code make some or all of the library GPL. This
question is complicated, in my mind at least, by several factors.


I believe the best and most honest answer right now is, "Nobody knows."

In fact, a careful reading of at least the LGPL (which I recently
carefully read before putting a project under it, so I can speak to it
where I can't speak to the GPL with quite as much confidence) shows that
it is almost hopelessly based on the C way of doing things, with "linking"
and "executables", that not only doesn't apply to Python, but doesn't
apply to a lot of other modern languages as well. (I am fairly confident
that the GPL has identical shortcomings, I just haven't read it as
recently.)

Specifically, I put a Javascript project under the LGPL and felt compelled
to augment it with an appendix of just under 3K, just to make the LGPL
make sense. I had to redefine "library", clarify the "work based on the
library" and "work using the library" distinction in a context where
there is no "linking" occurring, and correctly apply my Appendix to the
clause that allows you to use future versions of the LGPL.

And my problem is much simpler than yours. (I'm in control of the license,
so I was able to simply clarify it, but there would still be the problem
of what the raw LGPL would mean to someone had I not amended it, so from a
certain point of view there is some similarity despite the difference in
our positions; it is the user dilemma that prompted my solution.)

Right now, when it comes down to it, I don't think we can even define
"program" in a legal sense that is clear and useful; without that, trying
to *deeply* understand the (L)GPL is probably a hopeless affair.
Jul 18 '05 #2

P: n/a
John Hunter wrote:
I have a question about what it takes to trigger GPL restrictions in
python code which conditionally uses a GPL library.

Here is the context of my question. matplotlib, which I develop, is a
plotting module which is distributed under a PSF compatible license,
and hence we avoid using GPLd code so as to not trigger the GPL
requirements. matplotlib has rigid segregation between the front end
(plotting commands, figure objects, etc) and backends (gtk, wx, ps,
svg, etc). The backend is chosen dynamically at runtime -- eg the
same python script could trigger the import gtk, wx, or ps, depending
an some rc settings or command line opts.

The question is: does shipping a backend which imports a module that
links with GPL code make some or all of the library GPL. This
question is complicated, in my mind at least, by several factors.

Here are some sub-questions:

* If a backend module somebackend does

import somelib

where somelib is a python wrapper of GPL code, is somebackend
GPLd?
If it is original code, then no. To distribute it, it must have a
GPL-compatible license, and when distributing it with the GPLed library,
you must observe the same restrictions with your code as well as the
GPLed code. However, the license of the wrapper code itself may be, e.g.
BSD. If someone wants to take a bit of that code out of the wrapper
(maybe it's a generally useful bit of code), and that bit of code has
nothing to do with the GPLed library, then one can take that bit of code
under the BSD license and incorporate it into a proprietary project.
* Assuming the answer to the above question is yes, is matplotlib
GPLd if it distributes somebackend? I think this is a nuanced
situation because matplotlib would work just fine w/o somemodule,
and only uses somemodule's code if it is selected at runtime by
the user. Ie, no other part of the code depends on it since it is
one of many interchangeable backends.
Think of the situation wrt readline and the standard Python interpreter.
If you distribute binaries linked to libreadline, you also have to
distribute the rest of the code and ensure that that code is under a
GPL-compatible license. If you excise the GPLed code because you aren't
using it, you aren't bound by the GPL terms.
* To further complicate the question, the backend in question is qt,
which is dual licensed, commercial and GPL. The qt backend code
just needs to 'import qt', and neither the backend writer nor the
matplotlib frontend knows whether the deployed qt on the system is
commercial or GPLd. To date, the only GPL-like backend is GTK,
which is LGPL. Since we're only linking and not using the src,
we're protected from the GPL requirements. With QT, which has a
pure (non L) GPL variant, the situation is less clear to me.


If some matplotlib-using code specifically requires the QT backend,
Trolltech may have a case for requiring you to follow the GPL terms or
pay for a license. Otherwise, they're probably SOL. If you're
distributing PyQT binaries along with your package, then you should
probably follow the GPL's terms.

IANAL. TINLA.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Jul 18 '05 #3

P: n/a
John Hunter <jd******@ace.bsd.uchicago.edu> writes:
The question is: does shipping a backend which imports a module that
links with GPL code make some or all of the library GPL.


Literally speaking, no, not automatically, any more than driving a car
makes you into a licensed driver if you weren't one already. But if
you weren't licensed, then you've broken the law by driving the car.
So your question should be: 1) is shipping that backend one of the
things you need the GPL to license you to legally do, and 2) if so,
does the GPL in fact give you that license?

If you're asking in terms of legal enforcement, the answer is 1) maybe
and 2) almost certainly not. I think it's better to ask in terms of
the GPL's spirit. I would say that it's not in the GPL's spirit and
that GPL die-hards would consider that use objectionable, though they
might make exceptions for specific cases (so it doesn't hurt to ask).
Some authors who use the GPL are less strict about how they interpret
it, so again, the friendly thing to do is ask the author.

* If a backend module somebackend does

import somelib

where somelib is a python wrapper of GPL code, is somebackend GPLd?

It's GPL'd if you GPL it. If you don't GPL it, then distributing it
it may be a GPL violation that could get you taken to court. I
believe the FSF's view is that it is fact a violation; however, the
courts have not yet established this. The law doesn't have a
black-and-white boundary. It's more like a fractal. The only way to
find out what a court will decide is to actually try a case there.

Rather than try to probe how closely you can dance around the
boundaries of the GPL, you might just ask the author of the GPL'd
library whether what you want to do is ok with him or her. If s/he
says no and you do it anyway, you're both inviting trouble over the
possible infringement, and also inviting people to try to use your
code in ways you don't like. Since the free software movement depends
on a spirit of cooperation, I think it's best to avoid trying to press
too hard against the boundaries of anyone's licenses.

http://www.gnu.org/licenses/gpl-faq.html
Jul 18 '05 #4

P: n/a
On 30 Jan 2005 21:59:25 -0800, Paul Rubin
<http://ph****@NOSPAM.invalid> wrote:
John Hunter <jd******@ace.bsd.uchicago.edu> writes:
The question is: does shipping a backend which imports a module that
links with GPL code make some or all of the library GPL.


Literally speaking, no, not automatically, any more than driving a car
makes you into a licensed driver if you weren't one already. But if
you weren't licensed, then you've broken the law by driving the car.
So your question should be: 1) is shipping that backend one of the
things you need the GPL to license you to legally do, and 2) if so,
does the GPL in fact give you that license?

If you're asking in terms of legal enforcement, the answer is 1) maybe
and 2) almost certainly not. I think it's better to ask in terms of
the GPL's spirit. I would say that it's not in the GPL's spirit and
that GPL die-hards would consider that use objectionable, though they
might make exceptions for specific cases (so it doesn't hurt to ask).
Some authors who use the GPL are less strict about how they interpret
it, so again, the friendly thing to do is ask the author.

* If a backend module somebackend does

import somelib

where somelib is a python wrapper of GPL code, is somebackend GPLd?

It's GPL'd if you GPL it. If you don't GPL it, then distributing it
it may be a GPL violation that could get you taken to court. I
believe the FSF's view is that it is fact a violation; however, the
courts have not yet established this. The law doesn't have a
black-and-white boundary. It's more like a fractal. The only way to
find out what a court will decide is to actually try a case there.

Rather than try to probe how closely you can dance around the
boundaries of the GPL, you might just ask the author of the GPL'd
library whether what you want to do is ok with him or her. If s/he
says no and you do it anyway, you're both inviting trouble over the
possible infringement, and also inviting people to try to use your
code in ways you don't like. Since the free software movement depends
on a spirit of cooperation, I think it's best to avoid trying to press
too hard against the boundaries of anyone's licenses.

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


If you read the GPL, it claims everything it can (any "work" created
using GPLed "work"). My guess is that anything that calls the code in
a way not specifically allowed by the author is going to get you into
trouble. IANAL, but from what I can remember about earlier licensing
issues, any code specific for a GPLed library (especially "import")
will get you into to trouble. Having a non-free library with an
identical API and issuing
exec("import "+sys.argv[1])
where the user can supply sys.argv as the name of the gpl'ed library
will work (I think there is a free/non-free library out there that is
never run, but exists for exactly this condition).

Scott Robinson

Jul 18 '05 #5

P: n/a
Scott Robinson wrote:
On 30 Jan 2005 21:59:25 -0800, Paul Rubin
<http://ph****@NOSPAM.invalid> wrote:

John Hunter <jd******@ace.bsd.uchicago.edu> writes:
The question is: does shipping a backend which imports a module that
links with GPL code make some or all of the library GPL.


Literally speaking, no, not automatically, any more than driving a car
makes you into a licensed driver if you weren't one already. But if
you weren't licensed, then you've broken the law by driving the car.
So your question should be: 1) is shipping that backend one of the
things you need the GPL to license you to legally do, and 2) if so,
does the GPL in fact give you that license?

If you're asking in terms of legal enforcement, the answer is 1) maybe
and 2) almost certainly not. I think it's better to ask in terms of
the GPL's spirit. I would say that it's not in the GPL's spirit and
that GPL die-hards would consider that use objectionable, though they
might make exceptions for specific cases (so it doesn't hurt to ask).
Some authors who use the GPL are less strict about how they interpret
it, so again, the friendly thing to do is ask the author.

* If a backend module somebackend does

import somelib

where somelib is a python wrapper of GPL code, is somebackend GPLd?

It's GPL'd if you GPL it. If you don't GPL it, then distributing it
it may be a GPL violation that could get you taken to court. I
believe the FSF's view is that it is fact a violation; however, the
courts have not yet established this. The law doesn't have a
black-and-white boundary. It's more like a fractal. The only way to
find out what a court will decide is to actually try a case there.

Rather than try to probe how closely you can dance around the
boundaries of the GPL, you might just ask the author of the GPL'd
library whether what you want to do is ok with him or her. If s/he
says no and you do it anyway, you're both inviting trouble over the
possible infringement, and also inviting people to try to use your
code in ways you don't like. Since the free software movement depends
on a spirit of cooperation, I think it's best to avoid trying to press
too hard against the boundaries of anyone's licenses.

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

If you read the GPL, it claims everything it can (any "work" created
using GPLed "work"). My guess is that anything that calls the code in
a way not specifically allowed by the author is going to get you into
trouble. IANAL, but from what I can remember about earlier licensing
issues, any code specific for a GPLed library (especially "import")
will get you into to trouble. Having a non-free library with an
identical API and issuing
exec("import "+sys.argv[1])
where the user can supply sys.argv as the name of the gpl'ed library
will work (I think there is a free/non-free library out there that is
never run, but exists for exactly this condition).

Scott Robinson

I presume the appropriate way to answer this question is to ask the Gnu,
since under these circumstances the Python zen would advise "refuse the
temptation to guess". So I am Cc'ing gn*@gnu.org with a request for an
answer to the (apparently relatively simple) question:

If a Python program imports a module licensed under the GPL, in your
opinion does the Python program become a derivative work of the GPL'd
software?

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
Jul 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.