在 LGPL 代码中包含 GPL 标头 [关闭]答案

【问题标题】：Including GPL headers in LGPL code [closed]在 LGPL 代码中包含 GPL 标头 [关闭]
【发布时间】：2011-09-12 12:25:08
【问题描述】：

我想在基于 C 的专有应用程序中使用 Bluez 蓝牙 (GPL) 库。我想要 GPL 解决方法来使用它。

我的计划是：

编写一个链接到 Bluez 库 (GPL) 的 LGPL 包装库，还包括 Bluez 库头文件（也是 GPL）。因此包装器变成了 LGPL（对吗？）。
将 LGPL 包装库链接到我的专有应用程序中。

这样我的专有应用程序就不会受到 GPL 污染了吗？

如果不是，这里的正确解决方法是什么？

提前致谢

【问题讨论】：

我投票结束这个问题，因为它是关于许可和法律问题，而不是编程或软件开发。 See here 了解详情，help center 了解更多信息。
这将是迁移到开源 SO 的绝佳候选者

标签： c bluetooth gpl lgpl

【解决方案1】：

不，这是不可能的。 GPL 要求整个应用程序在 GPL 下分发。没有规定让包装器来解决它，当然也没有规定 GPL “衰减”为 LGPL。（也许您正在考虑另一个方向 - LGPL 允许您重新许可为 GPL。）您想要做的是对 GPL 应用程序的经典侵权，并且几乎肯定会被追究（假设您被抓住了） .

正确的解决方法是编写您自己的蓝牙实现或在 GPL 下分发您的应用程序。

最后，标准免责声明适用：我不是律师。如果您自己无法阅读 GPL 并无法确定我刚刚告诉您的内容，那么您确实需要在接触任何 GPL 代码之前聘请律师为您解释。

【讨论】：

而且，根据您的程序从 Bluez 中使用的内容，编写自己的库可能并不难。逆向工程 Blues，用它运行你的应用程序，而不是它使用哪些功能等以及如何使用。运气好的话，您只能使用 Bluez 提供的一小部分功能。
我对 Bluez 不熟悉，但如果您想与用户的蓝牙设备、偏好、配对等配置集成，可能会遇到困难......
就个人而言，除非您的目标是完全阻止在操作系统上集成和使用专有软件，否则我认为在 GPL 下许可一个库是对 GPL 的滥用，这是正确的设备管理集成所必需的而不是 LGPL 或其他限制较少的许可证。但是，选择许可证的是做工作和编写代码的人......
大多数时候我倾向于同意。但是，正如你所说，这是他们的选择。顺便说一句，FSF 官方战争计划：将所有克隆库设为 LGPL，将所有新库设为 GPL。

【解决方案2】：

这并不容易 :-) 你无法摆脱 GPL 的限制。

我的公司也有类似的案例。我们选择的解决方案是将需要使用基于 GPL 的库（在我的情况下是 libiw）的功能分开，并编写一个也基于 GPL 的独立应用程序（因此我们打开尽可能少的代码）。然后从我们的主应用程序启动“小程序”（例如通过 fork/execl 函数）并通过信号、管道或诸如 RPC 之类的东西与它通信。我不知道它是否适用于您的情况，因为我不知道您的应用程序要做什么，但这是我们选择的解决方法。

【讨论】：

即使这样也只有在不能说小程序只能与你的主程序一起工作的情况下才有效。如果是这样，它仍然是侵权的。
是的，这是经典的 gcc/ObjectiveC 案例，它导致 ObjectiveC 编译器被 GPL 保护。
有趣的R..，我不知道任何例子，只知道理论。

【解决方案3】：

任何这样的变通方法都违背了 GPL 的精神，如果 FSF 点缀他们的 Is 并越过它 Ts，那么就不应该有任何这些。

您唯一的合法选择是 (IANAL)：

不要使用库
遵守 GPL
向版权所有者索取不同的许可

请联系律师寻求专业建议。

【讨论】：

另一种选择，支付/捐赠以获得不同的许可证。如果不是免费的，价格可能是合理的，它支持您认为有用的库的进一步开发。