python and gpl

[Tim Churches]

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