通过插件在封闭源应用程序中使用GPL代码是否合法?
考虑以下步骤:
0)释放开源的Mock程序和Mock插件,它们通过某些接口(I)进行通信,交换复杂的数据结构,共享内存并相互调用。套用所有许可的许可证。
1)Release Plugin,设计用于以接口(I)定义的方式处理任何程序。该插件使用第三方GPL涵盖的代码,GPL本身也是如此。它最初是使用Mock程序开发和测试的。它以任何GPL程序的形式分发,并提供源代码。
2)发布封闭源代码专有程序,该程序旨在通过接口(I)定义的方式与任何插件进行通信。它最初是由Mock Plugin开发,测试和交付的。
3.1)将安装脚本添加到程序中,该程序将下载GPL插件并将其添加到已安装的程序。
3.2)代替安装脚本,添加有关如何手动下载和添加GPL插件的说明。
因此最终用户将获得专有程序,该程序将从插件中GPL涵盖的代码中受益。
问题:
0)如果这是合法的,那么这是不是一种合法的方法,而开发人员只需花费很少的精力就能在任何专有程序中获得GPL涵盖的代码的好处?
1)如果不合法,那么GPLv *的哪一部分或者任何内容会阻止谁执行哪个步骤?
2)3.1和3.2之间有法律上的区别吗?
3)如果Mock程序和插件,专有程序和GPL插件是由一个人或者不同的人开发的,在法律上有什么区别;有意还是无意?
4)我们认为这足够合乎道德吗?
5)是否有这种策略的现有样本?
6)是否有更简单的法律方法来实现相同的结果发布专有程序,该程序可能并且很可能会从GPL代码中受益?
更新:
Taken literally, this would imply that writing a plug-in for a closed-source program and releasing it under GPL would cause the combination to be an extension of the plug-in and thus fall under GPL, covering the entirety of the closed source program too
但是该组合不是分布式的,而是在最终用户计算机上组合的。就像我自己对Linux的修改一样,在发布之前,我不必开源。在这种情况下,最终用户设法进行了修改,而没有访问程序源的机会,这对他有好处,但是到目前为止,我没有看到任何非法的东西。
In order to use the GPL-covered plug-ins, the main program must be released under the GPL
我看到了GPL常见问题。但是插件可以独立开发并随MockProram一起提供。事情发生了,最终用户可以从MockProgram中获取插件并将其放入专有程序中。在最后一步之前,GPL和封闭源代码是分开的。而这一步骤是由最终用户完成的,由于他不分配组合产品,因此他没有义务。
更新2
这
If a court finds that one is specifically designed to require the other, then you can expect trouble. The nature of Mock Program and Mock Plugin might play a role too, as to whether they are "real" programs or stooges. Consult an attorney.
看起来像对问题3的答案。谢谢。
解决方案
这不是技术问题,而是法律问题。要求有执照的律师在我们所在地区执业。
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
来源
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
如果法院发现一个法院是专门为要求另一个法院而设计的,那么我们可能会遇到麻烦。无论是"真实"程序还是小偷,Mock程序和Mock插件的性质也可能起作用。咨询律师。
我认为,如果我们实际上没有链接程序,那么我们也许可以做到。使它们成为单独的进程,并通过套接字或者命名管道或者类似的对象进行通信。
但实际上,我同意第一张海报。如果我们计划在非GPL项目中使用GPL代码,则有一些不错的选择:
- 咨询精通此类问题的律师
- 将代码作为GPL发布到整个项目
- 不要在地方使用GPL代码
- 与GPL代码的作者联系,向他们提供补偿,以换取许可,而我们对使用其代码的自由的限制较少。
这绝对是不道德的。当我选择GPL而不是BSD时,如果我们从我的代码中受益,我的意图很明确,那么我们应该回馈。很清楚,我希望我们通过提供对使用我的代码的COMPLETE系统的完全访问权限来回馈社会。 GPL的核心意图是,其他人应该能够对这样的系统进行修改并从中构建其他东西。
在步骤3.1 / 3.2中,存在社会学问题。用户将在系统停止工作时询问谁?尤其是当GPL插件出现问题时,GPL插件作者会支持这样的用户吗? GPL插件开发人员会招待不道德的封闭源应用程序开发人员吗?
鉴于以上所述,没有人会尝试以足够大的规模来尝试回答问题4、5和6. 另外,如果我们正在编写可从中赚钱的商业应用程序,则通常可以以一定价格从版权所有者那里获得GPL代码的许可,以用于项目。
要回答问题3,如果我们是GPL代码的唯一作者,则我们拥有该代码的完整版权。我们可以使用它做任何想做的事情,包括在非GPL项目中使用它,即使我们已经在GPL下发布了它供其他人使用。
我在这里问了一个非常类似的问题,但是从一开始我就希望从一开始就将原始产品开源,这仍然使我可以在以后出售它。
我并不是说GPL是正确的,有些地方我确实不同意(有些我真的不理解!),但是至少这是朝着正确方向迈出的一步。
我认为这实际上归结为一个问题:
- 软件是否需要GPL代码才能运行。
如果答案是肯定的,则接受并继续。如果答案是否定的(如我的情况),那么到目前为止的共识是,我不必担心GPL。