9

我正在用 Python 开发一个 GPL 许可的应用程序，需要知道 GPL 是否允许我的程序使用专有插件。这是FSF在这个问题上必须说的：

如果在 GPL 下发布的程序使用插件，插件的许可证有什么要求？

这取决于程序如何调用其插件。如果程序使用fork和exec调用插件，那么插件是独立的程序，所以主程序的license对它们没有要求。

如果程序动态链接插件，它们之间进行函数调用并共享数据结构，我们认为它们形成了一个单独的程序，必须将其视为主程序和插件的扩展。这意味着插件必须在 GPL 或与 GPL 兼容的自由软件许可下发布，并且在分发这些插件时必须遵守 GPL 的条款。

如果程序动态链接插件，但它们之间的通信仅限于通过一些选项调用插件的'main'函数并等待它返回，这是一种边缘情况。

fork/exec 和动态链接之间的区别，除了有点人为之外，并没有延续到解释语言：Python/Perl/Ruby 插件怎么样，它通过importor加载execfile？

（编辑：我理解为什么 fork/exec 和动态链接之间的区别，但似乎有人想要遵守 GPL 但违背“精神”——我不——可以只使用 fork/exec 和进程间通信几乎可以做任何事情）。

最好的解决方案是在我的许可证中添加一个例外，以明确允许使用专有插件，但我无法这样做，因为我使用的是 GPL 的Qt / PyQt 。

4

3 回答 3

7

他区分 fork/exec 和动态链接，除了有点人为，

我不认为它是人造的。基本上，他们只是根据集成水平进行划分。如果该程序具有“插件”，这些插件本质上是即兴即忘的，没有 API 级别的集成，那么生成的工作不太可能被视为派生工作。一般而言，仅分叉/执行的插件将符合此标准，尽管可能存在不符合此标准的情况。如果“插件”代码也可以独立于您的代码工作，这种情况尤其适用。

另一方面，如果代码严重依赖于 GPL 的工作，例如广泛调用 API 或紧密的数据结构集成，那么事情更有可能被视为派生工作。即，“插件”不能在没有 GPL 产品的情况下单独存在，安装了该插件的产品本质上是 GPL 产品的衍生作品。

因此，为了更清楚一点，相同的原则可以适用于您的解释代码。如果解释的代码严重依赖您的 API（反之亦然），那么它将被视为派生作品。如果它只是一个自行执行且集成极少的脚本，那么它可能不会。

这更有意义吗？

于 2008-08-28T00:33:04.157 回答
1

@丹尼尔

fork/exec 和动态链接之间的区别，除了有点人为之外，并没有延续到解释语言：Python/Perl/Ruby 插件怎么样，它通过 import 或 execfile 加载？

我不确定这种区别是人为的。动态加载后，插件代码与 GPL 代码共享一个执行上下文。在 fork/exec 之后它不会。

无论如何，我猜测importing 会导致新代码在与 GPL 位相同的执行上下文中运行，您应该将其视为动态链接案例。不？

于 2008-08-28T00:32:59.693 回答
0

您在插件和主程序之间共享了多少信息？如果您所做的不仅仅是执行它们并等待结果（在程序和过程中的插件之间不共享任何数据），那么您很可能会摆脱它们是专有的，否则它们可能需要是 GPL' d。

于 2008-08-28T00:33:40.737 回答