On Tue, Aug 7, 2012 at 9:22 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/07/2012 01:34 AM, Luis Villa wrote:
On Mon, Aug 6, 2012 at 5:07 PM, Tom Marble tmarble@info9.net wrote:
AFAICT the incompatibility rises from the EPL choice of venue [2] which makes EPL not GPL compatible.
Hi, Tom- There is a deeper problem, inherent to the nature of copyleft. EPL states:
"When the Program is made available in source code form:
a) it must be made available under this Agreement;"
That's the essence of the copyleft, and says "once the source is under this license, it must stay under this license." Other copylefts have the same kind of language, leading to a conflict - both licenses say "the _entire copylefted work_ must be under this license," so as soon as there is overlap between the two copylefted works (say, because you place one EPL file in a GPL application, or vice-versa), you have a problem.
MPL 2, Sec. 3.3, or copyleft.next Sec. 11, get around this to some extent, but only one-way. Short of an EPL 2.0 that has a similar clause I don't think you can have the sort of compatibility you seem to envision.
Luis, what's your take (if any) on MPL/EPL compatibility?
Same problem (inclusion of individual MPL file in an EPL work is problematic.)
We likely could have added EPL to the list of MPL-compatible licenses, but did not sense much demand for MPL -> EPL one way compatibility. That may have been simply because the Mozilla and Eclipse communities don't overlap much.
I'd add that this is less difficult for MPL 2 because: 1) It's a relatively weak copyleft; and 2) to the extent we're strong (e.g., the patent clause, which I still need to discuss on this list), the requirement that you be combining with another work under the alternative license mitigates the risk somewhat of someone saying "ah, I'm using under this weaker patent clause, so I can sue you with impunity."
Luis