6

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?

9

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.

Obviously, this site generally prefers if you release all of your software under and open source license, but we realize this is not always feasible. 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

0

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 ...

  • 1
    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 at 8:37
  • Well, it's just my opinion. You could make your own answer if you disagree. – Денис Колесников Jun 27 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". – Денис Колесников Jun 28 at 17:39
  • 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 at 7:00
-2

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

Another way to use GPL software in non-GPL is to make a dummy replacement for a library.

If the real library isn't found, the dummy library is used.

You can then even compile your program - it won't be linked, it will be completely separable from the library.

Then you can point your users to download the library for the extra features.

Or, if you lost your conscience completely, just include the lib. GPL software can be distributed along with anything. It's not linked, who cares then?

And that applies not only to the Python.

  • 3
    Please consider improving your first answer instead of writing multiple ones. – MadHatter Jun 27 at 8:39
  • Well, you could agree with one part but disagree with another. That was the plot. I want to know what you'll like more. – Денис Колесников Jun 27 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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