Import a library that imports a GPL library? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 7 years ago.

开发者_运维技巧 Improve this question

So I am importing a library (reportlab), which is licensed BSD, but itself uses some libraries that are licensed GPL.

My question is, if I import reportlab into python - do I have to abide by BSD or GPL license?

---

IANAL. You have to abide by the licenses of all the packages you're using.

However, most would say if you only use the public API of those libraries, and they could theoretically be swapped out for other libraries implementing the same API, your code does not fall under the GPL, only any modifications you make to those libraries.

This is the point of view taken by the Linux kernel development community, for example.

Edit: After looking at the site of reportlab, it is clear that if you don't use the PyXML parser then you're only bound by the BSD license, as you're not using any GPL'd code.

Also, the question was raised in the comments whether your code is affected by the GPL if you don't distribute any GPL'd packages because the GPL primarily deals with modification of the code under the license and redistribution of that code. The answer is that if your code is a derivative work of the GPL'd code, you have to license your code under the GPL whether or not you're redistributing the original GPL'd code.

---

IANAL. From section 1.3 of the reportlab page here:reportlab licensing you can see they want you to talk to them about a commercial license.

GPL code when linked to BSD code requires you to license the BSD code under GPL - I'm talking static linking here. Dynamic linking to GPLed code is not allowed by non-GPL software - in fact, this is the reason for the existence of the LGPL license which allows dynamic linking from non-(L)GPL code. There is also an exception in the glibc license because they want you to be able to build commercial software with it.

The Linux Kernel developers do not all agree on all aspects of linking issues. If you're building against a standard API (POSIX) then it seems obvious you don't need to be GPL. But their arguments go deeper than that, so I don't think there is a direct comparison.

From the link above: "yRXP, our XML parser, is under the GNU General Public License. This is because the RXP parser underneath it is under this license. If you want to use pyRXP in a closed source project, you have to negotiate with us." This suggests they own pyRPX and can give or sell you a different license for it.

That's similar to the pyQT issue. You can make GPLed software with it, but for commercial stuff you need to pay up. Unless you want to make a commercial product that is GPLed of course.

---

IANAL either, but I think it doesn't even come into play as long as you are not going to distribute the other software as well. For example, if you just tell your users "you have to install pyRXP in order to use this" (maybe easier if you make that "reportlab"), I think the GPL does not apply to your own code.

EDIT: While there is no problem with using the reportlab toolkit in this particular case, the above interpretation does not seem to be correct (see agf's comments on this answer below, as well as his own answer)

Note that the reportlab toolkit (although it's by the same company "ReportLab") doesn't necessarily use pyRXP. They are two different things, each with it's own license.

Looking at reportlab's source code, in reportlab.lib.rparsexml, it seems that pyRXP is only imported if it is installed (separately, because it is not included), and it uses another xml parser if pyRXP is not available. (I guess this is their way of allowing pyRXP to be used, and still keeping reportlab under BSD license)

But maybe you'd best ask on the reportlab mailing list...