GPL程序的专有插件:解释语言怎么样？

我正在用Python开发一个GPL许可的应用程序,需要知道GPL是否允许我的程序使用专有的插件.这就是FSF在这个问题上所说的话:

如果根据GPL发布的程序使用插件,那么插件的许可证有哪些要求？

这取决于程序如何调用其插件.如果程序使用fork和exec来调用插件,那么插件是单独的程序,因此主程序的许可证对它们没有要求.

如果程序动态链接插件,并且它们相互进行函数调用并共享数据结构,我们认为它们构成了一个程序,必须将其视为主程序和插件的扩展.这意味着插件必须在GPL或兼容GPL的免费软件许可下发布,并且在分发这些插件时必须遵循GPL的条款.

如果程序动态链接插件,但它们之间的通信仅限于使用某些选项调用插件的"main"函数并等待它返回,这是一个临界情况.

fork/exec和动态链接之间的区别,除了是一种人为的,也不会延续到解释语言:Python/Perl/Ruby插件如何通过import或者加载execfile？

(编辑:我理解为什么fork/exec和动态链接之间的区别,但似乎有人想要遵守GPL但反对"精神" - 我不能 - 只能使用fork/exec和进程间通信几乎可以做任何事情).

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

他区分fork/exec和动态链接,除了是人为的,

我认为它根本不是人造的.基本上他们只是根据整合水平进行划分.如果程序具有"插件",这些"插件"本质上是火灾而忘记没有API级别集成,那么结果工作不太可能被视为派生工作.一般来说,只是分叉/执行的插件符合此标准,尽管可能存在不符合此标准的情况.如果"插件"代码也可以独立于您的代码工作,则此情况尤其适用.

另一方面,如果代码严重依赖于GPL的工作,例如广泛调用API,或者紧密的数据结构集成,则事情更有可能被视为派生工作.即,如果没有GPL产品,"插件"本身就不能存在,并且安装了此插件的产品本质上是GPLed产品的衍生作品.

因此,为了使其更清晰,相同的原则可以应用于您的解释代码.如果解释的代码在很大程度上依赖于您的API(反之亦然),那么它将被视为派生的工作.如果它只是一个脚本,只需极少的集成即可自行执行,那么它可能不会.

那更有意义吗？