EPL (Eclipse Public License), GPL (GNU Public Lice

问题:

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:

1. What exactly is the restriction against linking a GPL-ed product against both an EPL library and an LGPL library? Is it not allowed without the LGPL copyright holder's explicit permission, as it would be with GPL, or is it allowed?
2. Would an exception granted by the EPL copyright holder be sufficient? Such an exception was considered safe by Trolltech (now part of Nokia), when it used to license the Qt library using its own Qt Public License which is GPL-incompatible; and by the KDE project, whose libraries link against Qt and are released under the LGPL, while KDE apps are generally released under the GPL. The FSF's objection is due to "weak copyleft" and "choice of law clause" -- the former seems unobjectionable, if the EPL license holder grants an exception, but what sort of exception granted by the EPL copyright holder would satisfy the "choice of law clause" objection?

回答1:

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

Question: What exactly is the restriction against linking a GPL-ed product against both an EPL library and an LGPL library? Is it not allowed without the LGPL copyright holder's explicit permission, as it would be with GPL, or is it allowed?

Answer: Decomposition follows.

• 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...
• Linking LGPL 2 & 3 code with GPL 2 & 3 code is probably OK. See chart is @0A0D's answer to understand precisely which combinations are allowed.
• Linking GPL 2 & 3 code with EPL 1.0 is definitely not allowed.
  • Ref: See @0A0D's answer.
• Regarding copyright holder's explicit permission: You can probably do anything you want if you get permission from all copyright holders. Given the complexity of this legally and logistically, it should be considered nearly impossible.
  • 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.

Question: Would an exception granted by the EPL copyright holder be sufficient? Such an exception was considered safe by Trolltech (now part of Nokia), when it used to license the Qt library using its own Qt Public License which is GPL-incompatible; and by the KDE project, whose libraries link against Qt and are released under the LGPL, while KDE apps are generally released under the GPL. The FSF's objection is due to "weak copyleft" and "choice of law clause" -- the former seems unobjectionable, if the EPL license holder grants an exception, but what sort of exception granted by the EPL copyright holder would satisfy the "choice of law clause" objection?

Answer: Decomposition follows.

• Would an exception granted by the EPL copyright holder be sufficient?
  • As noted above, this is possible, but highly unrealistic that copyright holders of EPL 1.0 code would grant such an exception.
• Regarding Trolltech and multi-licensing, the derivative works generally have the option to select which license to apply. Thus, in the case of Trolltech/QPL/GPL, forget about QPL, and just use GPL.
• Regarding KDE/LGPL, I am unfamiliar with their licensing strategy and cannot comment. However, surely they have had lawyers review it. AFAIK: KDE is a German registered non-profit and has likely received some pro-bono legal advice on these matters. Even if not, KDE is old enough that, if not in compliance, a copyright holder would have surely objected by now. Read more here.

Finally, I am also facing a similar issue as I try to combine Java code from Eclipse and OpenJDK.

• Eclipse uses EPL 1.0.
• OpenJDK uses GPL 2 w/Classpath Exception (see very bottom for Classpath Exception)
  • Read more about Classpath Exception here

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.

回答2:

The above diagram shows the relationships between licenses. Though not comprehensive, if there is an arrow then it is compatible.

From the Eclipse website it states:

The EPL and the GPL are not compatible in any combination where the result would be considered either: (a) a "derivative work" (which Eclipse interprets consistent with the definition of that term in the U.S. Copyright Act ) or (b) a work "based on" the GPL code, as that phrase is used in the GPLv2, GPLv3 or the GPL FAQ as applicable. Further, you may not combine EPL and GPL code in any scenario where source code under those licenses are both the same source code module.

Based upon the position of the Free Software Foundation, you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3.

In my opinion, unless an exception is made - LGPL and EPL code should not be combined. In fact, a lot of software is dual-licensed under LGPL and EPL.