考虑以下步骤:
0) 发布开源的Mock Program和Mock Plugin,通过一定的接口(一)进行通信,交换复杂的数据结构,共享内存,相互调用。对其应用全许可许可证。
1) 发布插件,设计用于以接口 (I) 定义的方式与任何程序一起工作。该插件使用第三方 GPL 覆盖的代码,GPL 本身也是如此。它最初是使用模拟程序开发和测试的。它作为任何 GPL 程序分发,并提供源代码。
2) 发布闭源专有程序,旨在以接口 (I) 定义的方式与任何插件进行通信。它最初是与 Mock Plugin 一起开发、测试和交付的。
3.1) 将安装脚本添加到下载 GPL 插件并将其附加到已安装程序的程序中。
3.2) 代替安装脚本添加说明如何手动下载和附加 GPL 插件。
因此最终用户获得了专有程序,该程序受益于插件中的 GPL 覆盖代码。
问题:
0)如果它是合法的,那么在开发人员相当小的努力下,在任何专有程序中获得任何 GPL 涵盖的代码,这难道不是一种合法的方式吗?
1)如果它不合法,那么 GPLv* 的哪一部分或任何东西阻止谁执行哪一步?
2) 3.1 和 3.2 之间有什么法律区别吗?
3)Mock Program和Plugin、专有程序和GPL Plugin是由一个人开发还是不同人开发,是否有法律上的区别?有意还是无意?
4)你的意见是什么——它是否足够合乎道德?
5) 有没有这种策略的现有样本?
6) 是否有任何更简单的合法方法来实现相同的结果 - 发布可能并且最有可能从 GPL 代码中受益的专有程序?
更新:
从字面上看,这意味着为闭源程序编写插件并在 GPL 下发布会导致该组合成为插件的扩展,因此属于 GPL,涵盖了整个闭源程序也
但是这种组合不是分布式的,它是在最终用户机器上组合的。就像我自己对 Linux 的修改一样,在我发布它之前我不必开源。在这种情况下,最终用户设法在没有访问程序源的情况下进行了修改——对他有好处,但到目前为止我没有看到任何非法行为。
为了使用 GPL 覆盖的插件,主程序必须在 GPL 下发布
我看到了 GPL 常见问题的那部分。但是插件可以独立开发并与 MockProram 一起提供。最终用户可以从 MockProgram 中获取插件并将其放入专有程序中。在最后一步之前,GPL 和封闭源代码是分开的。该步骤由最终用户完成,他没有义务,因为他不分发组合产品。
更新 2
这
如果法院发现其中一个是专门为要求另一个而设计的,那么您可能会遇到麻烦。模拟程序和模拟插件的性质也可能发挥作用,至于它们是“真正的”程序还是傀儡。咨询律师。
看起来像是问题 3 的答案。谢谢。