请考虑以下步骤：
0）发布开源Mock Program和Mock Plugin，它通过某些接口（I）进行通信，交换复杂的数据结构，共享内存并相互调用。对其应用所有许可许可。
1）Release Plugin，用于以接口（I）定义的方式处理任何程序。这个插件使用第三方GPL覆盖的代码，GPL本身也是如此。它最初是使用Mock Program开发和测试的。它作为任何GPL程序分发，并提供源代码。
2）发布闭源专有程序，旨在以接口（I）定义的方式与任何插件进行通信。它最初是用Mock插件开发，测试和发货的。
3.1）向程序添加安装脚本，下载GPL插件并将其附加到已安装的程序。
3.2）而不是安装脚本添加说明如何手动下载和附加GPL插件。
因此，最终用户获得专有程序，该程序受益于插件中的GPL覆盖代码。
问题：
0）如果它是合法的，那么通过开发人员的努力，在任何专有程序中获得任何GPL涵盖代码的利益是不是合法的方式？
1）如果它不合法，那么GPLv *或其他任何部分会阻止谁做哪一步？
2）3.1和3.2之间是否存在法律差异？
3）如果Mock Program and Plugin，专有程序和GPL插件是由单个人或不同的人开发的，是否存在法律上的差异;故意与否？
4）您的意见是什么 - 是否足够道德？
5）是否存在此类策略的现有样本？
6）是否有任何更简单的法律途径来实现相同的结果 - 发布可能并且很可能从GPL代码中受益的专有程序？
更新
从字面上看，这意味着为封闭源程序编写插件并在GPL下发布它会导致组合成为插件的扩展，因此属于GPL，涵盖了整个闭源计划也是
但是这种组合不是分布式的，而是在最终用户机器上组合。就像我自己对Linux的修改一样，在我发货之前我不需要开源。在这种情况下，最终用户设法在不访问程序源的情况下进行修改 - 对他有好处，但到目前为止我看不到任何违法行为。
为了使用GPL覆盖的插件，主程序必须在GPL下发布
我看到了GPL常见问题的那一部分。但插件可以独立开发，并随MockProram一起提供。它发生了，以便最终用户可以从MockProgram获取插件并将其放入专有程序。直到最后一步GPL和封闭源被分开。而这一步是由最终用户完成的，他没有义务，因为他没有分发组合产品。
更新2
此
如果法院认定某人专门设计要求另一方，那么您可能会遇到麻烦。 Mock Program和Mock Plugin的性质也可能发挥作用，关于它们是“真正的”程序还是傀儡。咨询律师。
看起来像问题3的答案。谢谢。
答案 0 :(得分：8)
这绝对不符合道德标准。当我选择GPL而不是BSD时，我的意图很明确 - 如果你从我的代码中受益，那么你应该回馈。我非常清楚我希望您回馈 - 通过提供对使用我的代码的COMPLETE系统的完全访问权限。 GPL的核心是，其他人应该能够对这样的系统进行修改并从中构建其他东西。
步骤3.1 / 3.2存在社会问题。当用户系统停止工作时，用户会问谁？特别是当问题出现在GPL插件中时，GPL插件作者会支持这样的用户吗？ GPL插件开发者是否会接受不道德的闭源应用程序开发人员？
鉴于上述情况，没有人会尝试你的问题4,5和＆amp; 6以足够大的规模来引起注意。此外，如果您正在撰写从中赚取大量金钱的商业应用程序，那么您通常可以从版权所有者那里获得GPL代码许可，以便以某种价格在您的项目中使用。
要回答问题3，如果您是GPL代码的唯一作者，那么您拥有该代码的完全版权。你可以用它做任何你想做的事情，包括在非GPL项目中使用它，即使你已经在GPL下发布它供其他人使用。
答案 1 :(得分：7)
这不是技术问题，而是一个法律问题。请律师授权在您所在地区执业。
答案 2 :(得分：6)
如果程序动态链接 插件，他们进行函数调用 相互之间共享数据 结构，我们相信它们形成了一个 单个程序，必须予以处理 作为主要的延伸 程序和插件。为了 使用GPL覆盖的插件，主要 程序必须根据GPL发布 或与GPL兼容的免费软件 许可证，以及GPL的条款 主程序必须遵循 分发用于这些 插件。
答案 3 :(得分：4)
目标代码形式的工作的“对应源”意味着生成，安装和（对于可执行工作）运行目标代码和修改工作所需的所有源代码，包括用于控制这些活动的脚本。但是，它不包括工作的系统库，或通用工具或通常可用的免费程序，这些程序在执行这些活动时未经修改地使用但不属于工作的一部分。例如，Corresponding Source包括与工作源文件关联的接口定义文件，以及共享库的源代码和动态链接的子程序，这些子程序专门设计为需要，例如通过私密数据通信或控制这些子程序与工作的其他部分之间的流程。
如果法院认定某人专门设计要求另一方，那么您可能会遇到麻烦。 Mock Program和Mock Plugin的性质也可能发挥作用，关于它们是“真正的”程序还是傀儡。咨询律师。
答案 4 :(得分：1)
如果您实际上没有链接程序，我认为您可以这样做。让它们成为单独的进程，并通过套接字或命名管道或类似方式进行通信。
但实际上，我同意第一张海报。如果您计划在非GPL项目中使用GPL代码，那么有一些不错的选择：
答案 5 :(得分：1)
我在here上提出了一个非常类似的问题，但是从一开始我就是从一开始就把原始产品开源，这仍然让我有能力在以后卖掉它。
我不是说GPL是对的 - 有些领域我真的不同意（有些我真的不明白！），但至少它是朝着正确方向迈出的一步。
我认为这真的归结为一个问题： -
如果答案是肯定的，那么接受它并继续前进。如果答案是否定的（如我的情况），那么到目前为止的共识是我不必担心GPL。