The distinction between fork/exec and dynamic linking, besides being kind of artificial, doesn't carry over to interpreted languages: what about a Python/Perl/Ruby plugin, which gets loaded via import or execfile?
I'm not sure that the distinction is artificial. After a dynamic load the plugin code shares an execution context with the GPLed code. After a fork/exec it does not.
In anycase I would guess that importing causes the new code to run in the same execution context as the GPLed bit, and you should treat it like the dynamic link case. No?
he distinction between fork/exec and dynamic linking, besides being kind of artificial,
I don't think its artificial at all. Basically they are just making the division based upon the level of integration. If the program has "plugins" which are essentially fire and forget with no API level integration, then the resulting work is unlikely to be considered a derived work. Generally speaking a plugin which is merely forked/exec'ed would fit this criteria, though there may be cases where it does not. This case especially applies if the "plugin" code would work independently of your code as well.
If, on the other hand, the code is deeply dependent upon the GPL'ed work, such as extensively calling APIs, or tight data structure integration, then things are more likely to be considered a derived work. Ie, the "plugin" cannot exist on its own without the GPL product, and a product with this plugin installed is essentially a derived work of the GPLed product.
So to make it a little more clear, the same principles could apply to your interpreted code. If the interpreted code relies heavily upon your APIs (or vice-versa) then it would be considered a derived work. If it is just a script that executes on its own with extremely little integration, then it may not.
您在插件和主程序之间共享多少信息？ 如果您所做的不仅仅是执行它们并等待结果（在此过程中程序和插件之间不共享数据），那么您很可能会摆脱它们的专有性，否则它们可能需要是 GPL' d.
How much info are you sharing between the Plugins and the main program? If you are doing anything more than just executing them and waiting for the results (sharing no data between the program and the plugin in the process) then you could most likely get away with them being proprietary, otherwise they would probably need to be GPL'd.
发布评论
评论（3）
@Daniel
我不确定这种区别是人为的。 动态加载后，插件代码与 GPL 代码共享执行上下文。 在 fork/exec 之后，它不会。
无论如何，我猜测导入会导致新代码在与 GPL 位相同的执行上下文中运行，您应该将其视为动态链接情况。 不？
@Daniel
I'm not sure that the distinction is artificial. After a dynamic load the plugin code shares an execution context with the GPLed code. After a fork/exec it does not.
In anycase I would guess that
importing causes the new code to run in the same execution context as the GPLed bit, and you should treat it like the dynamic link case. No?我认为它根本不是人为的。 基本上他们只是根据集成程度进行划分。 如果程序具有本质上是即发即忘且没有 API 级别集成的“插件”，那么最终的工作不太可能被视为派生工作。 一般来说，仅分叉/执行的插件将符合此标准，尽管可能存在不符合此标准的情况。 如果“插件”代码也可以独立于您的代码工作，这种情况尤其适用。
另一方面，如果代码深度依赖于 GPL 的工作，例如广泛调用 API，或紧密的数据结构集成，那么事情更有可能被视为派生工作。 即，如果没有 GPL 产品，“插件”就不能单独存在，并且安装了该插件的产品本质上是 GPL 产品的派生作品。
因此，为了更清楚一点，相同的原则可以适用于您的解释代码。 如果解释的代码严重依赖于您的 API（反之亦然），那么它将被视为派生作品。 如果它只是一个单独执行且集成极少的脚本，那么它可能不会。
这更有意义吗？
I don't think its artificial at all. Basically they are just making the division based upon the level of integration. If the program has "plugins" which are essentially fire and forget with no API level integration, then the resulting work is unlikely to be considered a derived work. Generally speaking a plugin which is merely forked/exec'ed would fit this criteria, though there may be cases where it does not. This case especially applies if the "plugin" code would work independently of your code as well.
If, on the other hand, the code is deeply dependent upon the GPL'ed work, such as extensively calling APIs, or tight data structure integration, then things are more likely to be considered a derived work. Ie, the "plugin" cannot exist on its own without the GPL product, and a product with this plugin installed is essentially a derived work of the GPLed product.
So to make it a little more clear, the same principles could apply to your interpreted code. If the interpreted code relies heavily upon your APIs (or vice-versa) then it would be considered a derived work. If it is just a script that executes on its own with extremely little integration, then it may not.
Does that make more sense?
您在插件和主程序之间共享多少信息？ 如果您所做的不仅仅是执行它们并等待结果（在此过程中程序和插件之间不共享数据），那么您很可能会摆脱它们的专有性，否则它们可能需要是 GPL' d.
How much info are you sharing between the Plugins and the main program? If you are doing anything more than just executing them and waiting for the results (sharing no data between the program and the plugin in the process) then you could most likely get away with them being proprietary, otherwise they would probably need to be GPL'd.