On 08/08/2012 02:03 PM, Mike Linksvayer wrote:
On Wed, Aug 8, 2012 at 10:41 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/08/2012 01:23 PM, Luis Villa wrote:
On Wed, Aug 8, 2012 at 10:16 AM, Richard Fontana fontana@sharpeleven.org wrote:
I haven't pushed this to [gitorious] yet, but I have a draft EPL compatibility provision that says: You may Distribute a Derived Work that includes files licensed under the Eclipse Public License 1.0 ("EPL"), provided that such Distribution complies with the requirements of the EPL. The requirement stated in [Distribution: General](b) of This License shall be narrowed in scope solely to the extent necessary to facilitate this permission.
A problem with this approach, which is the only one feasible I think, is it has that unfortunate "stet license cleverness" quality to it.
Yes, but that (and definition of "work") aside, it seems reasonable. Would certainly work for MPL, I would think (though can't review it carefully enough right at this moment to be certain).
BTW the reason I didn't even think of an "MPL compatibility provision" is because MPL 2.0 and (current) copyleft-next both achieve GPLv2+/AGPLv3+ compatibility. But I wonder if there's some value in making an EPL provision (if it works out) be an "EPL or MPL" provision.
The provision sounds clever, but I'm not sure I understand its effects. Is it intended to *not* reduce copyleft-next's copyleft requirement for derived work to level of EPL (or MPL; and if those two, why not also LGPL?) but allow including files under those licenses, to the extent those licenses would allow it, but copyleft-next would not without this provision?
Er... yes, I think you have it right. Here it may be useful to think of my traditionalist use of "strong" when speaking of strong copyleft (I see that Luis Villa is also using it more broadly, much like Bradley has). I am diminishing strong copyleft only as much as necessary to permit CN/EPL combinations that would otherwise comprise one unit of CN copyleft scope, if you will.
It's somewhat like GPLv3/AGPLv3 cross-compatibility, but that involved provisions in both licenses.
My avoidance of LGPL is partly for the same reason I stated for my avoidance of MPL: these licenses (now) have GPLv2+/AGPL3+ compatibility, so it seems less important, whereas EPL remains GPL-incompatible.
In the case of the EPL that'd be a derived work which is not a derived work under US law, ie nobody can say with any certainty whether the provision permits anything additional in practice?
That is *probably* right. I may need to provide a more detailed answer to this question, though.
- RF