licensing - EPL（Eclipse 公共许可证）、GPL（GNU 公共许可证）/LGPL（较小的 GPL）和许可证例外？

Question

自由软件基金会认为EPL 和 GPL 是不兼容的。根据我对他们推理的阅读，LGPL 似乎也会受到类似的影响—— IANAL，如果阅读不正确，请纠正我。现在，为 GPL 代码的版权所有者提供了一个指南，以提供允许代码链接到不兼容库的例外情况，但它仍然会阻止从其他人链接到 GPL 代码（如果代码已经链接到 EPL 库），以及将 GPL 版程序与 EPL和另一个 LGPL 库链接的情况似乎不清楚。

我想知道几个问题的答案：

1. 将 GPL 版本的产品与 EPL 库和 LGPL 库链接到底有什么限制？没有 LGPL 版权持有者的明确许可是不允许的，就像 GPL 一样，还是允许的？
2. EPL版权持有人授予的例外是否足够？Trolltech（现在是诺基亚的一部分）认为这种例外是安全的，当时它使用自己的与 GPL 不兼容的 Qt 公共许可证来许可 Qt 库；以及 KDE 项目，其库链接到 Qt 并在 LGPL 下发布，而 KDE 应用程序通常在 GPL 下发布。FSF 的反对是由于“弱 copyleft”和“法律选择条款”——前者似乎没有异议，如果 EPL 许可持有人授予例外，但 EPL 版权持有人授予的何种例外将满足“选择法律条款”反对？

Answer 1

上图显示了许可证之间的关系。虽然不全面，但如果有箭头，那么它是兼容的。

从Eclipse 网站上它指出：

EPL 和 GPL 在任何组合中都不兼容，其结果将被视为：(a) “衍生作品”（Eclipse 将其解释为与美国版权法中该术语的定义一致）或 (b) 作品“基于” GPL 代码，因为该短语在适用的 GPLv2、GPLv3 或 GPL FAQ 中使用。此外，您不得在任何情况下合并 EPL 和 GPL 代码，其中这些许可证下的源代码都是相同的源代码模块。

根据自由软件基金会的立场，您不得在根据这些许可提供的代码之间存在链接的任何情况下组合 EPL 和 GPL 代码。以上适用于 GPL 版本 2 和 GPL 版本 3。

在我看来，除非有例外 - LGPL 和 EPL 代码不应该结合使用。事实上，很多软件都是在 LGPL 和 EPL 下获得双重许可的。

Answer 2

注意事项：我不是律师，但我已经非常仔细地阅读了这些许可证。如果您做出任何商业决定，您必须咨询律师。时期。否则，您将面临相当大的法律风险。

首先，让我们解决您的具体问题

问题：将 GPL 版本的产品与 EPL 库和 LGPL 库链接的具体限制是什么？没有 LGPL 版权持有者的明确许可是不允许的，就像 GPL 一样，还是允许的？

答：分解如下。

• 将 LGPL 2 和 3 代码与 EPL 1.0 链接可能没问题。
  • 参考：LGPL 2，第 5 节：不包含库的任何部分的派生，但旨在通过编译或链接与库一起使用的程序，称为“使用库的作品”。
  • 参考：LGPL 3，第 4 节：您可以根据您选择的条款传达组合作品，这些条款加在一起实际上不会限制对组合作品中包含的库部分的修改......
• 将 LGPL 2 和 3 代码与 GPL 2 和 3 代码链接可能没问题。请参阅图表是 @0A0D 的答案，以准确了解允许哪些组合。
• 绝对不允许将 GPL 2 和 3 代码与 EPL 1.0 链接。
  • 参考：见@0A0D 的回答。
• 关于版权所有者的明确许可：如果您获得所有版权所有者的许可，您可能可以做任何您想做的事情。鉴于这在法律和后勤方面的复杂性，应该认为这几乎是不可能的。
  • 示例：您可以（通过英勇的努力）尝试（通过金钱？）获得 Linux 内核的所有贡献者的许可，授予您 BSD 风格的代码许可，您可以修改和发布为非免费（商业）软件。同样，如前所述，可能但不现实。

问题：EPL 版权所有者授予的例外是否足够？Trolltech（现在是诺基亚的一部分）认为这种例外是安全的，当时它使用自己的与 GPL 不兼容的 Qt 公共许可证来许可 Qt 库；以及 KDE 项目，其库链接到 Qt 并在 LGPL 下发布，而 KDE 应用程序通常在 GPL 下发布。FSF 的反对是由于“弱 copyleft”和“法律选择条款”——前者似乎没有异议，如果 EPL 许可持有人授予例外，但 EPL 版权持有人授予的何种例外将满足“选择法律条款”反对？

答：分解如下。

• EPL版权持有人授予的例外是否足够？
  • 如上所述，这是可能的，但 EPL 1.0 代码的版权所有者会批准这样的例外是非常不现实的。
• 关于奇趣科技和多重许可，衍生作品通常可以选择应用哪个许可。因此，在 Trolltech/QPL/GPL 的情况下，忘记 QPL，只使用 GPL。
• 关于 KDE/LGPL，我不熟悉他们的许可策略，无法发表评论。但是，他们肯定已经让律师对其进行了审查。AFAIK：KDE 是一家德国注册的非营利组织，并且可能已就这些事项收到了一些无偿法律建议。即使不是，KDE 也已经足够老了，如果不合规，版权所有者现在肯定会反对。 在这里阅读更多。

最后，当我尝试结合来自 Eclipse 和 OpenJDK 的 Java 代码时，我也面临着类似的问题。

• Eclipse 使用 EPL 1.0。
• OpenJDK 使用带有类路径异常的 GPL 2（参见最底部的类路径异常）
  • 在此处阅读有关类路径异常的更多信息

我对许可证的阅读表明，明确允许组合这些作品，因为 Eclipse在其 GPL 2 和 3 不兼容声明中使用了衍生作品一词。此外，Classpath Exception明确指出，链接到此库不会创建衍生作品。