我可以从封闭源应用程序链接到GPL库吗？

好的，在所有人大声疾呼重复问题之前，是的，我已经在这里看到过类似的几个问题。但是没有人回答这个问题。

如果我链接到GPL版本的库而不修改该库，是否需要发布源代码？

根据这个问题，答案是肯定的！

但是这个答案对我来说并不令人满意。答案基本上是说，如果不使代码开源，就无法以任何方式使用GPL代码。

但是，如果先前的说法是正确的，那么这将表明没有任何人或组织可以在Linux上发布任何专有软件。哪一定是错的。仅仅是因为为了使任何应用程序执行任何有用的操作，请打开文件，写入控制台，创建TCP连接，因此必须将应用程序链接到libcGPL版本。

所以我的问题是：如果GPL声明，如网站上所有先前的回答所述，链接到另一个GPL程序的程序必须是GPL本身，那么如何创建/发行/出售任何专有应用程序完全可以在Linux上运行？由于如上所述，该应用程序必须像GPL代码一样，才能在Linux上运行。

一个更实际的示例说，我链接到在非GPL应用程序中使用GPL编写的共享库，这会迫使非GPL应用程序成为GPL编写吗？更具体地说，如果我使用GPL库而不进行修改，然后将该库作为.so或分发.dll，这是否要求我的应用程序是开源的？

如果您链接到GPL库，那么您已经创建了派生作品，并且您的代码必须是GPL-这与L GPL代码不同，后者专门允许动态链接不同许可的代码。包括libc在内的系统库都是LGPL。

Linux内核标头和libgcc（编译器隐式调用的库）也有一个特殊的豁免。

在一般情况下，您是正确的，因为您无法链接到GPL库，分发您的代码，然后不以GPL形式发布您的代码。

但是，存在“ 系统库例外”，这是人们如何链接Linux库并仍然在非GPL许可下发布其产品的方式。

另一个例外是两个许可证彼此兼容。查看FSF 兼容许可证页面以进一步阅读。

最后，GPL库的作者可以创建特定的例外，例如用于非商业或业余爱好者。

不幸的是，有太多的潜力无法制定严格的规则。如果您的问题中没有更多细节，您的答案是“可能不会，但也许可以。”

简短的答案是没有人真正知道。（此讨论是关于GPL而不是LGPL的。）

GPL对“衍生作品”的用语含糊，不同的人用不同的方式解释。共识似乎是违反了静态链接，但是没有通过系统中断（例如，调用Linux内核）进行调用。后者主要基于这样的事实，即像Oracle这样的公司都在Linux上发行，并且没有被起诉-许可证中尚不清楚。

动态链接尚不清楚，可能是70/30表示违反。使用管道或远程过程调用来调用程序，即使这基本上是相同的，也可能不会违反30/70。完全不清楚是通过COM调用还是使用Java Jar。

基本上，如果有任何疑问，并且您不喜欢律师，请远离GPL。