On Wed, Aug 8, 2012 at 3:10 PM, Richard Fontana <fontana(a)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