我正在用Python开发一个GPL许可的应用程序，需要知道GPL是否允许我的程序使用专有的插件。这个问题是what the FSF has to say：
如果根据GPL发布的程序使用插件，插件的许可证有哪些要求？
这取决于程序如何调用其插件。如果程序使用fork和exec来调用插件，那么插件就是单独的程序，因此主程序的许可证对它们没有要求。
如果程序动态链接插件，并且它们相互进行函数调用并共享数据结构，我们认为它们构成了一个程序，必须将其视为主程序和插件的扩展。 。这意味着插件必须在GPL或兼容GPL的免费软件许可下发布，并且在分发这些插件时必须遵循GPL的条款。
如果程序动态链接插件，但它们之间的通信仅限于使用某些选项调用插件的“main”函数并等待它返回，这是一个临界情况。
fork / exec和动态链接之间的区别，除了是一种人为的，也不会延续到解释语言：Python / Perl / Ruby插件如何通过import或{{ 1}}？
（编辑：我理解为什么fork / exec和动态链接之间的区别，但似乎有人想要遵守GPL但反对“精神” - 我不能 - 只能使用fork / exec和进程间通信几乎可以做任何事情。）
答案 0 :(得分：6)
他区分fork / exec和动态链接，除了是一种人为的，
我认为它根本不是人为的。基本上他们只是根据整合水平进行划分。如果程序具有“插件”，这些“插件”本质上是火灾而忘记没有API级别集成，那么结果工作不太可能被视为派生工作。一般来说，只是分叉/执行的插件符合此标准，尽管可能存在不符合此标准的情况。如果“插件”代码也可以独立于您的代码工作，则此情况尤其适用。
另一方面，如果代码严重依赖于GPL的工作，例如广泛调用API，或者紧密的数据结构集成，则事情更有可能被视为派生工作。即，如果没有GPL产品，“插件”本身就不能存在，并且安装了此插件的产品本质上是GPLed产品的衍生作品。
因此，为了使其更清晰，相同的原则可能适用于您的解释代码。如果解释的代码在很大程度上依赖于您的API（反之亦然），那么它将被视为派生的工作。如果它只是一个脚本，只需很少的集成就能自行执行，那么它可能不会。
这更有意义吗？
答案 1 :(得分：1)
@Daniel
fork / exec和动态链接之间的区别，除了是一种人为的，不会延续到解释语言：如何加载Python / Perl / Ruby插件通过import或execfile？
我不确定区别 是否是人为的。动态加载后，插件代码与GPLed代码共享执行上下文。在fork / exec之后它没有。
在任何情况下，我都会猜测import导致新代码在与GPLed位相同的执行上下文中运行，您应该将其视为动态链接案例。否？
答案 2 :(得分：1)
您在插件和主程序之间共享了多少信息？如果你正在做的不仅仅是执行它们并等待结果（在程序和插件之间不共享数据）那么你很可能会让它们成为专有的，否则它们可能需要成为GPL' d。