python and gpl
John Hunter
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
Jeremy Bowers
> 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.
Robert Kern
> 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
Paul Rubin
> 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.
Scott Robinson
<http://phr...@NOSPAM.invalid> wrote:
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
Steve Holden
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 g...@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
Tim Churches
>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
Paul Rubin
> >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
> 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,..."
My IANAL amateur reading is that the GPL does in fact apply, at least
in the US. Running the program is not restricted, but loading the
program from disk to memory before you can run it counts as copying
it, which invokes the license, Computer Associates v. Altai, 982 F.2d
693. I personally believe that doctrine is insane, but that's what
software companies pushed through the courts in order to make
shrink-wrap EULA's enforceable. (Otherwise they'd only be enforceable
if you agreed to the terms before the vendor got your money).
> 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. ..."
That means you can run your separate program all by itself without
needing to load the GPL module.
> 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."
That means the two programs have nothing to do with each other.
> 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.
According to the FSF, it doesn't matter whether the linking is static
or dynamic; the GPL applies to both cases.
> Note that the formal advice was specific to Australian law,
Oh ok, that might be different from US law. Do you have EULA's there
that are considered enforceable?
> 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.
Ultimately, what really counts are court decisions. The FSF enforces
the GPL against infringers all the time, and in each case so far, the
infringer has backed down voluntarily because they didn't like their
chances in court.
Tim Churches
>
> > >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 ...>
> > 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,..."
>
> My IANAL amateur reading is that the GPL does in fact apply, at least
> in the US. Running the program is not restricted, but loading the
> program from disk to memory before you can run it counts as copying
> it, which invokes the license, Computer Associates v. Altai, 982 F.2d
> 693. I personally believe that doctrine is insane, but that's what
> software companies pushed through the courts in order to make
> shrink-wrap EULA's enforceable. (Otherwise they'd only be enforceable
> if you agreed to the terms before the vendor got your money).
I can't comment on the situation in the US, but our advice made no reference to similar
case law or interpretations under Australian law. However, even if what you say is true
(that loading code from disk into memory is "copying"), it makes no difference,
because the GPL copyleft licensing provisions only apply to copies which you give or
make available to others. In other words, you can mix and match GPLed code and non-
GPLed code, in source code form, in object code form, or by runtime linking to your
heart's content, provided you do so in teh privacy of your own organisation, and you
are NOT obliged to distribute all the other code you mix together to others under the
GPL. However, if you do distribute to others, it must be under the GPL. Runtime
linking, importing or making function calls does not involve distribution to others.
The so-called "viral" properties of the GPL - that by using GPLed code somehow your
entire source code base will need to be made available to the entire world under the
GPL - is just FUD perpetuated by certain large software companies and their fellow
travellers. Sure, if you distribute your mixed GPL-and-other code to third parties then
the whole lot has to be under the GPL, but the GPL does not force you to distribute it.
So even if loading code into memory is copying (in the US), it isn't distributing to
others.
> > 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. ..."
>
> That means you can run your separate program all by itself without
> needing to load the GPL module.
That test is just one interpretation of what that paragraph means. "Reasonably
considered independent and separate works in themselves" can also be interpreted to
mean that the source code is clearly identified as belonging to a separate work, and
that the there is no mixing of sorce code between the two works.
However, in the case of our application, and in the case of Matplotlib, if I am not
mistaken, that test is satisfied anyway.
>
> > 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."
>
> That means the two programs have nothing to do with each other.
If the source code for work A does not contain a single line of the source code for
application B, then it would seem reasonable to say that work A is not based on work
B. However, work A can still call functions defined in work B at runtime, without "being
based on it".
> > 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.
>
> According to the FSF, it doesn't matter whether the linking is static
> or dynamic; the GPL applies to both cases.
That's their opinion, and they are welcome to it. However, teh GPL specifically states
that "Activities other than copying, distribution and modification are not covered by this
License; they are outside its scope." I cannot see how dynamic linking at runtime can
be construed as copying, distribution or modification. Even if in the US it is considered
copying, then the result is that you are then required to license your non-GPL code
back to yourself under the GPL. However, you are NOT obliged to make that code
available to others, if you do not wish to.
In our case, and in the Matplotlib case, we ARE making that other code available to
others anyway, just under a different free, open source license.
>
> > Note that the formal advice was specific to Australian law,
>
> Oh ok, that might be different from US law. Do you have EULA's there
> that are considered enforceable?
Yes, AFAIK, but IANAL. However, our Copyright Act says:
"47B(1) The copyright in a literary work that is a computer program is not infringed by
the making of a reproduction of the work if:
(a) the reproduction is incidentally and automatically made as part of the technical
process of running a copy of the program for the purposes for which the program was
designed; ..."
> > 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.
>
> Ultimately, what really counts are court decisions. The FSF enforces
> the GPL against infringers all the time, and in each case so far, the
> infringer has backed down voluntarily because they didn't like their
> chances in court.
OK, although in the case of the GPLed code imported by our application, the FSF is
not the copyright holder. We have discussed the situation with the copyright holder
and they are happy to accept the interpretation of the GPL provisions given to us by an
expert lawyer.
Tim C
JanC
> My IANAL amateur reading is that the GPL does in fact apply, at least
> in the US. Running the program is not restricted, but loading the
> program from disk to memory before you can run it counts as copying
> it, which invokes the license, Computer Associates v. Altai, 982 F.2d
> 693. I personally believe that doctrine is insane, but that's what
> software companies pushed through the courts in order to make
> shrink-wrap EULA's enforceable. (Otherwise they'd only be enforceable
> if you agreed to the terms before the vendor got your money).
In Belgium (and the whole EU, I think) copying a program from disk to
memory to be able to run it is covered under "fair use" (just like copying
digital data from an audio CD to a DAC to be able to listen to it is fair
use), which can't be restricted by companies.
AFAIK. IANAL. Etc. ;-)
--
JanC
"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9