GPL中是否存在允许专有软件与GPL库链接的漏洞？

让我们研究一个假设的场景：

X公司编写一个专有程序（A），该程序与专有库（B）动态链接。Y公司希望使用GPL许可的替代库（C），因此编写了一个包装器库（D），该包装器动态链接到A和C，并将A使用的API调用转换为C使用的API调用。

由于D打算与C一起使用，并且使用C的API调用，因此D是C的派生作品，因此必须根据GPL *的条款进行分发。结果，A和D的合并工作也必须按照GPL的条款进行分配，鉴于Y公司不拥有A的源代码，这是不可能的。也就是说，只要Y公司自己分配D ， 没有问题。但是，无论公司Y采取什么行动，公司X都不会通过分配A来违反GPL，即使没有B。D的存在也并不意味着A突然是C的衍生作品（通过D），必须根据C获得许可。 GPL也是如此。

现在，这是漏洞：没有什么东西是从编写自己的d的版本，从单独发布它，并告诉最终用户使用的，而不是乙d停止X公司在运行A.看来，一个公司能够设计专有程序以使用GPL库而不会违反GPL，只要使用包装程序模块将专有程序与GPL库隔离开，并且该模块是单独分发的。

我的推理正确吗？这是GPL中的真正漏洞吗？

* D也是A的派生作品，但出于本场景的目的，X公司已明确授权创建D并允许其根据GPL进行许可。

IANAL，但这是我对GPL范围内允许的内容的看法：

• 公开分发合并的作品“ A-B”：很好，可以在任何专有许可下完成

• 为Y创建C的包装函式库D：好的，这并不意味着A必须放在GPL下

• Y在内部使用组合产品“ A-D-C”：也可以，只要未向公众分发该组合，GPL就不需要开源A

• 公开分发组合的作品“ A-D-C”：这将要求A开源并接受GPL（而且X或Y是否分发此组合都没有关系；此外，Y是否愿意因此，他们需要从X获得A的发行许可证）

现在有趣的问题是：D＆C可以作为GPL下的开源单独分发吗，A＆B（或者只是A而没有B）可以在专有许可下分发，并且最终用户可以自己用D＆C代替B？

在此，最终用户对“ AB”的最终修改（使A依赖于库D＆C）由分发后的最终用户完成。因此，有人可能会说最终的修改仅由最终用户在内部完成。在不违反GPL的情况下，这似乎确实是可能的-您所获得的是“ AC＆D”的有效组合，其中A获得了专有许可，而C＆D获得了GPL。

当然，律师或法官对此可能有不同的看法。要获得最终答案，我认为您必须等到有人尝试它，然后再有人起诉他。

我想对于大多数系统而言，如果不从一开始就设计某种方式来设计“ A”，那么很难创建这样的星座图，这样它就可以与B或C无缝地工作。在这种情况下，人们可能会怀疑A是从C衍生而来的。

编辑：对此进行了思考，我想到了类似的情况：为封闭源应用程序编写和分发GPL许可的插件。让我们以Photoshop为例。我认为没有人会因为存在第三方供应商提供的GPL插件而认真尝试强制Adobe开源Photoshop。在这里，由于存在定义明确的接口，因此甚至不需要“包装器库”。但是，如果Photoshop从GPL第三方插件中合并其某些主要功能，是否会改变这种情况？我认为，在这种情况下，可能很难决定在哪里划界线，此时，封闭源产品是“基于” GPL库的作品。

编辑2：有双重许可库，非商业用途的GPL许可证和商业用途的专有许可证像这样。因此，您的“漏洞”将意味着基于此类库开发产品（使用商业版本，因此GPL不适用于您的产品），将您的产品作为无库的闭源发布给公众，并最终用户自己获取并安装GPLed版本。对于这种情况，我想该库的供应商将很有可能成功起诉您违反许可证（当然，如果您不为他的库付款）。这值得麻烦吗？可能不会。尤其是在我链接的示例中，您要么必须购买库，因为定价并不取决于您销售产品的频率，而是取决于在开发过程中有多少开发人员在使用库。

最后，由于这些法律风险，如果我打算在封闭源代码产品中使用开放源代码库，则我将尽可能避免使用GPL库，而不尝试利用此“漏洞”。带有链接例外的LGPL或GPL更加安全，或者具有任何类型的非病毒OS许可证。

一个实际的例子是最终用户必须自行安装的Linux专有图形驱动程序。重要的是，对于专有驱动程序的创建者，如果最终用户分发组合的作品，则将为最终用户（不是他们可能履行的）而非驱动程序的创建者创建法律义务。

另一个答案声称“由于程序依赖于库，因此它仍然是派生的工作”-但是，如果由于库不存在而导致程序无法实际工作，则它不是派生的。

但是最后，如果您依靠“漏洞”，那么您应该考虑的是，最初的方法可能不是正确的方法。

链接定义了GPL的派生词。LGPL旨在处理这种特定情况：您要以GPL形式发布库，但将链接定义为所应用许可证的显式限制，或者要链接到某些GPL代码，但需要您自己的许可证作品是根据非GPL许可本身发布的。

如果最终用户要进行链接（从可能链接到GPL库的非GPL源中构建自己的代码），则最终用户实际上并没有有效地创建最终产品的GPL版本，因为他不是该项目的所有者，因此不得更改该项目的非GPL部分的许可。这通常会阻止最终用户以任何形式进行分发，但不会禁止使用。

也就是说，如果项目要求从源代码构建项目并且仅以这种方式进行分发，则与链接库所获得的许可无关，因为这完全是由非GPL开发人员控制的。也就是说，除非您根据自己的许可条款进行指定，否则您如何才能知道将仅在gcc上针对glibc构建纯源代码发布，而对IBM编译器针对其libc构建VS？这很快就成为合理使用和禁止不可执行的法律条件的限制（不是说幻想在最近的很多场合都没有被写入法律）。

我不是律师，但据我所知您是不正确的，因为该程序依赖于库-它仍然是衍生产品。等式是一种衍生工作。至少它基于库中定义的API。