Using Python module on LGPL license in commercial product [closed]

Question

There is written in LGPL license that I can use not modified, linked code in commercial, closed product without changing license of product to LGPL. What about Python module (*.py) on LGPL license in commercial product? Is it treated as linked code?

Answer 1

I don't think the issue (whether importing a Python module counts as "linking" with it, for the legal purposes of the GPL) has been settled yet. I don't think it will be resolved until a court case turns on it (and possibly not even then). The GPL is (sadly) written basically in terms of C and its associated tools, so it's only obvious how to apply it if the language and tools used for software have similar properties to those associated with C.

However, importing a Python module is surely at least as permissive a situation as dynamically linking to a shared library; which copyrighted document (source file) you link with when you type import foo isn't determined until the program is actually run, and can be trivially changed after your copyrighted document is produced by the end user moving .py files around on their system, or even just changing PYTHONPATH.

Personally, I find the above arguments lead clearly to the conclusion that adding import foo to your own source file doesn't "copy from or adapt all or part of [foo.py] in a fashion requiring copyright permission" at all, and thus the GPL doesn't really apply if you never modify foo.py. (Quote from the GNU GPL version 3, under "0. Definitions")

(Technically I think this argument would apply to dynamically linking to a shared C library as well, except that to do so you've normally had to #include <foo.h>, which means your compiled program is a work based on foo.h even if you do argue that it's not a work based on the shared library. Although your source code would be completely unencumbered by the GPL with this interpretation, interestingly enough, so if you wanted to push the point you could distribute your source code with a proprietary license and instructions for the end user to compile themselves. But I digress.)

Not that common sense arguments necessarily match up with what a court would decide. If you treat import foo.py as "dynamically linking" with foo.py for the purposes of the (L)GPL, I do not see how you could go wrong - no one will sue you for adhering to license conditions you technically didn't have to.

Answer 2

Simple test - can the user swap the LGPL part for their own version?

Answer 3

If I understand your question correctly, you are asking if you can use a LGPL’ed library within a closed source commercial product. While I couldn’t find anything that addressed this specific situation, everything suggests there should be no issues. First, there is an article on use of LGPL in Java. This is the relevant quote from the article:

FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.

One other additional quote from the article that may be relevant:

When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library.

And one last quote:

The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

While it is true that this particular case has not been tried in a court of law (at least that I know of), I wouldn’t stay up at night worrying about it. Even if the LGPL isn’t exactly clear on this issue, the FSF has published guidance that the LGPL works as expected for all programming languages. In general, if a contract is ambiguous, then it is resolved in favor of the defendant (this is an oversimplification, but you can find more details here). If you are really nervous, I would consider contacting the Free Software Foundation.

In summary, it looks like you can use LGPL software with Python if you either distribute the LGPL'ed library's source code with your application (along with your modifications) or you make the end user install this library separately.