GPLv3 licensed library requirement and licensing own library BSD [closed]

Question

I have been searching the web for quite some time now, but the plethora of opinions/comments/articles about licensing questions make it difficult to verify how trustworthy the various sources are. Also, they're often contradictory which left me behind confused after my search. Since it's probably a common situation an open-source developer faces, I guess there are people who are less confused.

The scenario: development of a python code library hosted on github that requires two other libraries pip installed on the user's system in order to work. One of which is BSD licensed, one of which is GPLv3 licensed. No modifications of those libraries are required, we just need their core functionality as available in certain versions.

1) Am I right, that even if I don't pack the required GPLv3 library into our codebas, i.e. don't copy it into our git repo, the fact that we call this libraries' classes/methods from within our code, renders our code "derivative work" and hence we're obliged to also release our library under the GPLv3? Or is there a difference between requiring some other package to be installed and shipping (a potentially modified) GPLv3'ed library with our library?

2) We can just state that the BSD licensed library is required, but that does not impose further constraints on how we license our library itself?

In brief: The BSD library is easy to list as a requirement -- does us requiring the GPLv3'ed library fall under derivative work and hence requires us to license our code under the GPLv3 as well or not?

Ideally, we'd like not to license our code under the GPLv3 but we might be obliged to. Is there a way to disentangle such code requirement scenarios in order to be free to license our core code under any license we want? What happens if we not even state any license, does "please install this GPLv3 lib on your computer" automatically render our code GPLv3'ed?

(Since it's all libraries, so just codebases, this frontend/backend distinction which may allow different licenses, won't apply here, I guess? Or can we view our library as a frontend, since the user is not required to anyhow interact with the two required libraries, i.e. they're somehow 'backend'.)

Answer 1

If your library A requires another library B to be present in order to provide (part of) its functionality, the library A is a derived work of library B. This is independent of how the libraries are licensed.
So, your library is a derived work of both the GPL library and the BSD library.

The main difference between the GPL and BSD licenses here is that the GPL license puts restrictions on how a derived work can be licensed whereas the BSD license does not have such restrictions.
The restrictions in the GPL license are simply that a derived work must be available under the same terms as the original, which effectively means that you have to use the same license.

For the GPL license, it does not matter how the end-user gets a copy of all required libraries. If one of the libraries is licensed with the GPL license, then all libraries and programs that depend on it for their functionality have to be licensed under the GPL as well.

---

To get out of the infectious nature of the GPL license, you have to communicate "at arms length" with the GPL code, which effectively means

• you can't depend on internal details of the GPL code
• there must be a (semi-)standardized protocol to communicate with the GPL code (calling a program with command-line arguments can already satisfy this).
• The end-user must be able to replace the GPL code with a different (compatible) version or other equivalent code.

This almost always requires the GPL code to be running in a separate program.

Answer 2

The GPL is written with the understanding that code that links to the GPL code also falls under the GPL since it is a derivative work. This understanding might not be correct, but you probably don't want to be involved in a case where that is tested in a court. From the perspective of the GPL, it does not matter how you depend on the GPL code (e.g. if you deliver the dependencies or ask users to install the libraries). In any case, you depend on the GPL library and therefore have created a derivative work.

The “usual” solution is to break this dependency. Instead of relying on the GPL library, you create your own library that does the same thing (but might not be very good). You can then distribute your software with a dependency on this helper library. However, you can be clever and structure this dependency as a plugin. While by default you depend on the non-GPL plugin, you can also create a GPL plugin that uses the GPL library. This plugin can be distributed separately, and can be installed by users if they prefer it. While the GPL plugin may provide better performance or more features, your system will still have to be usable with the default non-GPL plugin, or you'd have an indirect dependency on the GPL code. Note that the plugin interface has to be sufficiently generic, and not just a rip-off of the GPL library interface!

The specifics of this are possibly difficult to work out, so it would make sense to re-read the GPL carefully and go over this plan with a lawyer (which I am not).