19

Suppose I have a Python library which is distributed under the GPL license. I would like to use that library in my program, that I may eventually want to distribute under non-GPL terms.

The library itself is not pure-Python: parts of it core functionality is written in C/C++. The Python interpreter calls those C parts an "Extension", compiles as dynamically-linked library (.so or .dll), and loads during the runtime when I'm importing the library.

My concern arises from reading the GPL FAQ, where they state the following:

If a programming language interpreter has a license that is incompatible with the GPL, can I run GPL-covered programs on it?

When the interpreter just interprets a language, the answer is yes. The interpreted program, to the interpreter, is just data; the GPL doesn't restrict what tools you process the program with.

However, when the interpreter is extended to provide “bindings” to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. The JNI or Java Native Interface is an example of such a facility; libraries that are accessed in this way are linked dynamically with the Java programs that call them.

So if these facilities are released under a GPL-incompatible license, the situation is like linking in any other way with a GPL-incompatible library.

I find these remarks not exactly, but quite similar to the situation that I am in. So my question is: am I safe to use this GPL library or not?

Improve this question

2 Answers 2

Reset to default
15

I am not a lawyer, and this is not legal advice.

I'm importing the library.

Importing the library essentially means you are linking to the GPL library. Hence, your program must also be GPL.

Depending on your use case, there may be a way to use the library without licensing your entire project under the GPL. For example, you could create a wrapper for this library and then have your main program execute the wrapper via a python os.system() or subprocess.Popen() call. In this case, you would be required to release the wrapper under the GPL, but the main program could be released under a license of your choice (assuming no other licensing restrictions by the software stack you are using). Remember not to import your wrapper or the third party library in your main executable if you go this route.

https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation

Improve this answer
2
  • Calling via executables also counts as "linking"? TIL.
    – iBug
    Oct 7, 2021 at 6:08
  • The context of the subject in question appears to be far too ambiguous to assert that importing is equivalent to linking. Even the FAQ section quoted in the original question is ambiguous enough to allow for, "If bindings linked to GPL, then GPL; if importing, then non-GPL allowed." Even the section on mere aggregation states things like, "ultimately judges will decide." Indeed, ambiguity is as much subject to the word "interpreter" as it is to "linking."
    – truefusion
    Aug 31, 2022 at 9:12
-2

I'm not a lawyer, and it's not a legal advice.

GPL prohibits "linking". There's two kinds of linking, static and dynamic.

Static linking means you put the whole library into your program. It is impossible with Python.

Dynamic linking means you put symbols into your program, and then, they are resolved with a dynamic linker. Python acts as a dynamic linker, I suppose.

The dynamic linking happens after you compile your program. You don't have to compile Python program! Your users will compile the program when they run it.

The only thing you actually use is the program's API. Which is not covered by the copyright.

And GPL software can be distributed along with proprietary products. It's called "aggregate".

So yes, you can, as long as you are not including .pyc, .pyo and pycache ...

Improve this answer
5
  • 5
    The argument that dynamic linking doesn't create a derivative work for copyright purposes (and therefore doesn't engage a copyleft licence) is not as settled as you suggest. We have summaries of the arguments both ways (pro, con), but the issue is very much an open one. To presume that it has been settled is to argue from very shaky ground.
    – MadHatter ♦
    Jun 27, 2019 at 8:37
  • Well, it's just my opinion. You could make your own answer if you disagree.
    – user15357
    Jun 27, 2019 at 16:42
  • And I'm not exactly about dynamic linking. I say "distribute your proprietary project in the source form, move the responsibility to the user".
    – user15357
    Jun 28, 2019 at 17:39
  • 1
    It makes no difference. If dynamically-linked code is a derivative work for the purposes of copyright law, then the moment you write that code it's a derivative work of the original, and therefore whether you distribute it in binary or source form, you must do so under the GPL.
    – MadHatter ♦
    Jun 29, 2019 at 7:00
  • at first GPL does not prohibit linking. It just has rules that need to be followed, which some people might not want to agree on, thus a GPL library might be unusable for them. At second, when considering possible license problems, a programmer should not just consider if a delivery is legally ok, but also if it's ok for the user to execute. So even with your strange arguments to not ship pyo files, latest the user starting the program would have a legal problem. So the program is not usable...
    – Paebbels
    Jan 21 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.