EPL（Eclipse公共许可证），GPL（GNU公共许可证）/ LGPL（较小GPL）和许可证例外？

Question

自由软件基金会考虑EPL and GPL to be incompatible。根据我对他们推理的解读，似乎LGPL会受到同样的影响 - IANAL，如果读数不正确，请纠正我。现在，有guide for the copyright holder of the GPL-ed code提供例外，允许代码链接到不兼容的库，但它仍然排除了链接到其他人的GPL编码（如果代码已经链接到EPL库）以及将GPL编辑的程序与EPL 和另一个LGPL库相关联的情况似乎不清楚。

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

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

Answer 1

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

从Eclipse website声明：

  

EPL和GPL不兼容   在任何组合中的结果   将被视为：（a）a   “衍生作品”（Eclipse   解释符合   在美国定义该术语   版权法）或（b）以“为基础的作品”   关于“GPL代码，就像那个短语一样   用于GPLv2，GPLv3或GPL   常见问题解答。此外，你可以   不要将EPL和GPL代码组合在一起   场景下的源代码   许可证都是相同的源代码   模块。

     

基于Free的位置   软件基金会，你可能不会   将EPL和GPL代码结合在一起   两者之间存在链接的场景   根据这些提供的代码   许可证。以上适用于两者   GPL版本2和GPL版本3.

在我看来，除非有例外，否则不应合并LGPL和EPL代码。事实上，许多软件都是LGPL和EPL下的双重许可。

Answer 2

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

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

问题：将GPL-ed产品与EPL库和LGPL库链接的限制究竟是什么？如果没有LGPL版权所有者的明确许可，是否允许使用GPL，还是允许？

答案：分解如下。

• 链接LGPL 2＆amp;使用EPL 1.0的3个代码可能没问题。
  • 参考：LGPL 2, Section 5：一个程序，它不包含任何图书馆部分的衍生物，但设计用于通过编译或链接它与图书馆合作，被称为“使用的作品图书馆“。
  • 参考：LGPL 3, Section 4：您可以根据您选择的条款传达合并作品，这些术语合在一起，实际上不会限制对合并作品中所包含的图书馆部分的修改... < / em>的
• 链接LGPL 2＆amp; 3个代码与GPL 2＆amp; 3代码可能还可以。请参阅图表是@ 0A0D的答案，以准确了解允许哪些组合。
• 链接GPL 2＆amp;使用EPL 1.0的3个代码绝对不允许。
  • 参考：请参阅@ 0A0D的答案。
• 关于版权所有者的明确许可：您可以做任何您想要的事情如果您获得所有版权所有者的许可。鉴于这种合法和后勤的复杂性，应该认为这几乎是不可能的。
  • 示例：您可以（通过英勇的努力）尝试从Linux内核的所有贡献者那里获得（有钱？）许可，以授予您BSD风格的代码许可证。修改和发布为非免费（商业）软件。再次，如前所述，可能，但不切实际。

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

答案：分解如下。

• EPL版权所有者授予的例外是否足够？
  • 如上所述，这是可能的，但EPL 1.0代码的版权所有者会授予此类例外是非常不现实的。
• 关于Trolltech和多许可，衍生作品通常可以选择应用哪个许可。因此，在Trolltech / QPL / GPL的情况下，忘记QPL，只使用GPL。
• 关于KDE / LGPL，我不熟悉他们的许可策略，无法发表评论。但是，他们肯定有律师对此进行审查。 AFAIK：KDE是德国注册的非盈利组织，可能会就这些问题获得一些无偿的法律建议。即使不，KDE也足够老了，如果不符合规定，版权所有者肯定会被提出异议。 Read more here.

最后，当我尝试结合Eclipse和OpenJDK的Java代码时，我也遇到了类似的问题。

• Eclipse使用EPL 1.0。
• OpenJDK使用GPL 2 w/Classpath Exception（参见Classpath异常的底部）
  • Read more about Classpath Exception here

我对许可证的阅读表明，明确允许合并这些作品，因为Eclipse在其GPL 2＆amp; G中使用术语衍生作品。 3不兼容声明。此外，类路径异常明确指出，链接此库不会创建衍生作品。