On Wed, Aug 8, 2012 at 3:10 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 08/08/2012 02:03 PM, Mike Linksvayer wrote:
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.
I was also using "strong" traditionally (which I think of as greediness, meant neutrally a la a greedy regex match, but I know people make much of possible pejorative interpretations of terminology...some people like the hereditary metaphor, thus perhaps traditional "strong" means inverse relationship closeness triggering ~same license requirements) rather than the strength of other intended-as-pro-freedom conditions. (I've heard people refer to CC-BY-SA as a strong copyleft license, which it is in the traditional sense, but hardly at all in an expanded sense, as it doesn't even require modifiable form.) (Incidentally, there's a third kind of copyleft strength, which can't be discerned by reading license text--the universe of stuff licensed under the copyleft in question and perhaps compatible ones; a single atom universe can be incredibly greedy and demanding, but everyone will ignore it. I suspect this kind is more important than the other two, but under-appreciated, as bottom-up things usually are relative to command-and-control things.)
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.
That could be a reason to address MPL and LGPL and avoid EPL: add flexibility within GPL-compatible universe, shun the rest. But...
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.
I'm surprised you're interested in adding linecount and incomprehensibility to achieve a low-certainty and small effect. Sort of like I said on identi.ca, I don't see the point unless somehow this would politically lead to an EPL 2.0 which would join the GPL-compatible universe.
Mike