GPL程序的专有插件：解释型语言如何处理？
我正在用Python开发一个GPL许可证的应用程序，想知道GPL是否允许我的程序使用专有插件。以下是自由软件基金会（FSF）对此问题的看法：
如果一个程序是GPL发布的，它使用了插件，那么插件的许可证有什么要求？
这要看程序是如何调用插件的。如果程序是通过“fork”和“exec”来调用插件，那么这些插件就是独立的程序，所以主程序的许可证对它们没有要求。
如果程序是动态链接插件，并且它们之间可以互相调用函数和共享数据结构，我们认为它们就形成了一个整体程序，这样就必须把它们视为主程序和插件的扩展。这意味着这些插件必须在GPL或与GPL兼容的自由软件许可证下发布，并且在分发这些插件时必须遵循GPL的条款。
如果程序动态链接插件，但它们之间的通信仅限于调用插件的“主”函数并等待返回，这种情况就有点模糊了。
在“fork/exec”和动态链接之间的区别，除了有点人为外，对于解释型语言来说并不适用：比如一个通过import或execfile加载的Python/Perl/Ruby插件呢？
（补充：我理解“fork/exec”和动态链接之间的区别，但似乎有些人想遵循GPL却又想违背其“精神”——我不是——可以通过“fork/exec”和进程间通信来实现几乎任何事情）。
最好的解决办法是给我的许可证添加一个例外，明确允许使用专有插件，但我无法做到这一点，因为我使用的是Qt/PyQt，它们是GPL的。
3 个回答
你在插件和主程序之间分享了多少信息呢？如果你只是简单地运行插件，然后等着结果，没有在这个过程中分享任何数据，那么这些插件可能可以保持私有，不用公开。不过，如果你们之间有数据交流，那可能就需要按照GPL许可证来处理了。
@Daniel
在fork/exec和动态链接之间的区别，除了有点人为的感觉外，对于解释型语言来说并不适用：比如Python/Perl/Ruby的插件，通过import或execfile加载时又如何呢？
我不太确定这个区别是否真的是人为的。在动态加载后，插件代码和GPL许可的代码共享同一个执行环境。而在fork/exec之后，它们就没有这个共享了。
无论如何，我猜想import会让新代码在和GPL许可的代码相同的执行环境中运行，所以你应该把它当作动态链接的情况来看待。对吧？
关于fork/exec和动态链接之间的区别，除了有点人为的感觉，
我觉得这并不是人为的。其实他们只是根据整合的程度来划分。 如果一个程序有“插件”，这些插件基本上是可以直接使用的，没有API层面的整合，那么最终的作品不太可能被认为是衍生作品。一般来说，一个仅仅是被fork/exec的插件会符合这个标准，尽管也可能有例外。尤其是当“插件”代码可以独立于你的代码工作时，这种情况更明显。
另一方面，如果代码深度依赖于GPL授权的作品，比如大量调用API，或者数据结构紧密集成，那么更有可能被认为是衍生作品。也就是说，这个“插件”不能独立存在，必须依赖于GPL产品，而安装了这个插件的产品本质上就是GPL产品的衍生作品。
为了让这个更清楚一些，同样的原则也适用于你的解释性代码。如果解释性代码严重依赖于你的API（或者反过来），那么它会被认为是衍生作品。如果它只是一个可以独立执行的脚本，整合非常少，那么可能就不算。
这样说清楚了吗？