EPL(Eclipse公共许可证),GPL(GNU公共许可证)/ LGPL(较小GPL)和许可证例外？

Question

自由软件基金会认为EPL和GPL不兼容.根据我对他们推理的解读,似乎LGPL会受到同样的影响 - IANAL,如果读数不正确,请纠正我.现在,有一个GPL编码版权所有者的指南,提供允许代码链接到不兼容的库的异常,但它仍然排除了链接到其他代码的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网站上可以看出:

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

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

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

Answer 2

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

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

问题:将GPL-ed产品与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(现在是诺基亚的一部分)认为是安全的,当时它曾使用自己的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也足够老了,如果不符合要求,版权所有者肯定会受到反对. 在这里阅读更多.

最后,当我尝试组合Eclipse和OpenJDK的Java代码时,我也遇到了类似的问题.

• Eclipse使用EPL 1.0.
• OpenJDK使用GPL 2 w/Classpath Exception(参见Classpath异常的底部)
  • 在此处阅读有关Classpath Exception的更多信息

我对许可证的阅读表明,明确允许合并这些工作,因为Eclipse 在其GPL 2&3不兼容声明中使用术语衍生作品.此外,Classpath异常特别声明链接此库不会创建衍生作品.