John Hunter wrote:
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).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.
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
-- http://mail.python.org/mailman/listinfo/python-list
