python and gpl
rkern at ucsd.edu
Mon Jan 31 00:42:45 EST 2005
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
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.
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Python-list