python and gpl
Tim Churches
tchur at optushome.com.au
Mon Jan 31 16:15:08 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.
>
We sought formal legal advice on this issue from a lawyer with expertise
in open source licensing - in our case, our application which is
licensed under a (very slightly) modifided version of the Mozilla Public
License v1.1 imports a GPLed Python module (RPy) which wraps a GPLed
library (R).
The answer was that the GPL does not apply to combination of code at
run-time. Specifically, Section 0., Para 1 (assuming zero-based
paragraph numbering...) says:
"Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of running
the Program is not restricted,..."
Furthermore, Section 2 para 1 says:
"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program, and
can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. ..."
and Section 2 para 3 says:
"In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of a
storage or distribution medium does not bring the other work under the
scope of this License."
On the basis of these clauses, the legal advice to us was that merely
including "import rpy" and making calls to RPy-wrapped R functions does
not invoke the provisions of the GPL because these calls only relate to
run-time linking, which is not covered by the GPL. However, combining
GPLed source code or static linking would invoke the GPL provisions.
Additionally, we were advised to (re-)distribute any GPLed components
required by our application in clearly separate packages i.e as separate
tarballs or zip files, and not to bind them together in an omnibus
distribution or installation file. However, putting them on the same
CD-ROM or other media is fine.
Note that the formal advice was specific to Australian law, and did
mention some Australian case law regarding fair use under the Copyright
Act with respect to making API calls - that relates to our application
making API calls to the GPLed library which is imported at runtime. The
opinion was that we were on safe ground here, but you might want to
investigate this aspect wrt copyright laws in other countries. My
understanding is that most copyright law provides for "fair use" which
may cover use of parts of an API to a GPLed library (as distinct from
complete incorporation of the entire API into another application -
which would invoke the GPL).
IANAL, and the above constitutes mangled paraphrasing of carefully
worded formal legal advice, the scope of which was restricted to
Australian law. However, the sections of the GPL quoted above are pretty
unambiguous.
The other, informal advice, was to ignore the FAQs and other opinions on
the FSF web site regarding intepretation of the GPL - it's only the
license text which counts.
Tim C
More information about the Python-list
mailing list