在LGPL许可证中写道，我可以在商业，封闭产品中使用未经修改的链接代码，而无需将产品许可证更改为LGPL。商业产品的LGPL许可证上的Python模块（* .py）怎么样？它被视为链接代码吗？
答案 0 :(得分：11)
我认为问题（导入Python模块是否算作“链接”，为了GPL的法律目的）已经解决了。我不认为它会在法院审理案件之前得到解决（甚至可能不会解决）。 GPL（遗憾地）基本上是根据C及其相关工具编写的，因此，如果用于软件的语言和工具具有与C相关的属性，那么应用它是显而易见的。
但是，导入Python模块肯定是至少，因为它是一种动态链接到共享库的情况;您在键入import foo时链接的受版权保护的文档（源文件）在程序实际运行之前尚未确定，并且在结束后生成受版权保护的文档后可以轻易更改用户在他们的系统上移动.py文件，甚至只是改变PYTHONPATH。
就我个人而言，我发现上述论据清楚地得出结论，将import foo添加到您自己的源文件中“不会以需要版权许可的方式复制或修改[foo.py]的全部或部分内容。 “ at all ，因此如果你从不修改foo.py，那么GPL并不适用。 （引自the GNU GPL version 3，在“0.定义”下
（从技术上讲，我认为这个论点也适用于动态链接到共享的C库，除了这样做你通常不得不#include <foo.h>，这意味着你的编译程序是基于foo的工作.h即使你确实认为它不是基于共享库的工作。虽然你的源代码完全没有受到这种解释的GPL的影响，但有趣的是，如果你想推动您可以使用专有许可证和最终用户自行编译的说明来分发您的源代码。但我离题了。）
并非常识论证必然与法院决定的内容相符。如果你为了（L）GPL的目的将import foo.py视为与foo.py“动态链接”，我看不出你怎么会出错 - 没有人会因为你在技术上没有遵守许可条件而起诉你不得不。
答案 1 :(得分：6)
简单测试 - 用户可以将LGPL部件换成自己的版本吗？
答案 2 :(得分：5)
如果我正确理解您的问题，您就会问是否可以在封闭源商业产品中使用LGPL的库。虽然我找不到任何解决这种具体情况的事情，但一切都表明应该没有问题。首先，有一篇关于LGPL in Java使用的文章。这是文章的相关引用：
FSF的职位始终保持不变：LGPL与所有已知的编程语言（包括Java）一起按预期工作。链接到LGPL库的应用程序不需要在LGPL下发布。应用程序只需遵循LGPL第6节的要求：允许新版本的库与应用程序链接;并允许逆向工程来调试它。
文章中可能相关的另一个引用：
当您使用应用程序（或单独）分发库时，您需要包含库的源代码。但是，如果您的应用程序要求用户自己获取库，则不需要为库提供源代码。
最后一句话：
LGPL没有包含继承的特殊规定，因为不需要。继承以与传统链接相同的方式创建衍生作品，LGPL允许这种类型的衍生作品与允许普通函数调用的方式相同。
虽然这个特定案件确实没有在法庭审判过（至少我知道），但我不会熬夜担心它。即使LGPL在这个问题上并不十分清楚，FSF也发布了LGPL按预期用于所有编程语言的指导。一般来说，如果合同含糊不清，那么它就有利于被告（这是过于简单化，但你可以找到更多细节here）。如果你真的很紧张，我会考虑联系Free Software Foundation。
总之，如果您将LGPL的库源代码与您的应用程序一起分发（以及您的修改），或者您让最终用户安装此代码，您似乎可以将LGPL软件与Python一起使用图书馆分开。
答案 3 :(得分：0)
您的程序导入的python库当然不是静态链接的，它的编译形式（或者该形式的源表单）不包含在您创建的.py（co）文件中。因此，您至少可以安全地导入L / GPLed模块，因为Linux的nvidia设备驱动程序正在与内核动态链接。请记住，您不应该使用非自由软件捆绑免费软件，因此如果您在同一个tarball / zip文件或CD中为您的磁带库提供L / GPL，您可能会遇到问题。如果您从模块中继承类，这也适用，因为您不直接包含其他模块。 （用户可以将L / GPLed模块换成功能相同的模块，而您的代码不会注意或关注）。唯一的灰色区域是如果在运行时修改模块的内容，然后分发修改后的模块，此时您需要分发生成修改后的模块的源。 （请记住.pyc，即使它包含子模块.a = 5行或类似内容，没有更改子模块，您需要腌制或以其他方式保存子模块的执行状态然后分配保存的状态，以便计算为更改子模块。） 我认为这是看待它的唯一理智的方式，否则OpenOffice电子表格程序与OO宏相结合需要与LGPL兼容，因为OpenOffice本身就是LGPL。导入模块的Python模块是使用该模块，而不是从中创建派生的工作。