EPL(Eclipse公共许可证)，GPL(GNU公共许可证)/LGPL(较小的GPL)和许可证例外? [英] EPL (Eclipse Public License), GPL (GNU Public License)/LGPL (Lesser GPL) and license exceptions?
问题描述
自由软件基金会认为 EPL和GPL不兼容.根据我对他们的推理的理解，似乎LGPL也会受到类似的影响-IANAL，如果该理解不正确，请更正我.现在，有一个针对GPL版本代码的版权所有者的指南提供例外情况，以允许代码与不兼容的库链接，但仍会阻止从其他人链接到GPL版本的代码(如果代码已针对EPL库进行链接)，以及链接GPL-针对EPL 和另一个LGPL库的ed程序似乎还不清楚.
The Free Software Foundation considers EPL and GPL to be incompatible. Based on my reading of their reasoning, it would seem that the LGPL would be similarly affected -- IANAL, please correct me if that reading is incorrect. Now, there is a guide for the copyright holder of the GPL-ed code to provide exceptions allowing for the code to be linked against incompatible libraries, but it'd still preclude linking to GPL-ed code from others (if the code is already linked against an EPL library), and the situation with linking a GPL-ed program against an EPL and another LGPL library seems unclear.
我想知道几个问题的答案:
I'd like to know the answer to several questions:
- 将GPL版本的产品同时链接到EPL库和LGPL库的限制到底是什么?没有LGPL版权所有者的明确许可(如GPL那样)是不允许的吗?还是允许?
- EPL版权持有人授予的例外就足够了吗?当Trolltech(现为诺基亚的一部分)使用自己的Qt公共许可证(与GPL不兼容)授权Qt库时，这种例外被Trolltech(现为诺基亚的一部分)认为是安全的.以及KDE项目，其库链接到Qt并在LGPL下发布，而KDE应用程序通常在GPL下发布. FSF的异议归因于弱版权"和法律选择条款"-如果EPL许可持有人授予例外，但EPL版权持有人授予的哪种例外将满足选择权"，前者似乎是没有异议的.法律条款"异议?
推荐答案
Caveat Emptor:我不是律师，但是我已经仔细阅读了这些许可证.如果您要做出任何商业决定，则必须咨询律师.时期.否则，您将面临相当大的法律风险.
Caveat Emptor: I am not a lawyer, but I have read these licenses quite closely. If you are making any commercial decisions, you must consult a lawyer. Period. Otherwise, you will expose yourself to considerable legal risk.
首先，让我们解决您的具体问题
First, let us address your specific questions
问题:将GPL版本的产品同时链接到EPL库和LGPL库的限制到底是什么?
答案:随后分解.
- 链接LGPL 2&使用EPL 1.0的3个代码可能还可以.
- 引用: LGPL 2，第5部分:一个程序，它不包含库的任何部分的派生产品，而是设计为通过编译或链接与库一起使用的程序，称为使用库的作品".
- 引用: LGPL 3，第4部分:您可以传达合并的根据您选择的条款进行的工作，可以有效地结合在一起，而不会限制对合并工作中包含的库部分的修改...
- Linking LGPL 2 & 3 code with EPL 1.0 is probably OK.
- Ref: LGPL 2, Section 5: A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library".
- Ref: LGPL 3, Section 4: You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work...
- 引用:请参阅@ 0A0D的答案.
- 示例:您可以(英勇努力)尝试从Linux内核的所有贡献者那里获取(使用金钱?)许可，从而为您授予BSD样式的代码许可修改并发布为非免费(商业)软件.再次，如前所述，可能，但不现实.
- Example: You could (with heroic efforts), attempt to secure (with money?) permission from all contributors to the Linux kernel to grant you a BSD-style license of the code that you could modify and release as non-free (commercial) software. Again, as noted previously, possible, but unrealistic.
问题: EPL版权持有者授予的例外是否足够?当Trolltech(现为诺基亚的一部分)使用自己的Qt公共许可证(与GPL不兼容)授权Qt库时，这种例外被Trolltech(现为诺基亚的一部分)认为是安全的.以及KDE项目，其库链接到Qt并在LGPL下发布，而KDE应用程序通常在GPL下发布. FSF的异议归因于弱版权"和法律选择条款"-如果EPL许可持有人授予例外，但EPL版权持有人授予的哪种例外将满足选择权"，前者似乎是没有异议的.法律条款"异议?
答案:随后分解.
- EPL版权持有者授予的例外就足够了吗?
- 如上所述，这是可能的，但高度不切实际的是，EPL 1.0代码的版权所有者会授予此类例外.
最后，当我尝试结合Eclipse和OpenJDK的Java代码时，我也面临着类似的问题.
Finally, I am also facing a similar issue as I try to combine Java code from Eclipse and OpenJDK.
- Eclipse使用EPL 1.0.
- OpenJDK使用带有类路径异常的GPL 2 (有关类路径，请参阅底部例外)
- Eclipse uses EPL 1.0.
- OpenJDK uses GPL 2 w/Classpath Exception (see very bottom for Classpath Exception)
- Read more about Classpath Exception here
我对许可证的阅读表明，明确允许将这些作品组合在一起，因为Eclipse在其GPL 2和更高版本中使用了衍生作品一词. 3不兼容声明.此外， Classpath Exception 特别声明与该库的链接不会创建派生作品.
My reading of the licenses says that combining these works is allowed expressly because Eclipse uses the term derivative work in their GPL 2 & 3 incompatibility statement. Further, the Classpath Exception specifically states that linking against this library does not create a derivative work.
这篇关于EPL(Eclipse公共许可证)，GPL(GNU公共许可证)/LGPL(较小的GPL)和许可证例外?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
