On Wed, Aug 8, 2012 at 6:49 PM, Richard Fontana fontana@sharpeleven.org wrote:
What I found at least temporarily convincing in Mike's comments was, first, his saying that what I wrote is incomprehensible (another design goal is maximal comprehensibility), and second, his hint that this may be bad policy.
My comment "adding linecount and incomprehensibility" may have been too strong -- I meant "and reducing comprehensibility". Also, I didn't mean to hint that the provision is bad policy, but rather ineffective, with respect to the EPL -- based on my understanding which I guess is not totally wrong based on your response in https://lists.fedorahosted.org/pipermail/copyleft-next/2012-August/000127.ht... (but I'm happy for my guess to have been merely incomprehensible and totally wrong).
"eliminating some of the rough edges through allowing simple inclusion of already-quite-open code" as Luis put it is a desirable goal. The provision does seem effective to me if it addressed the MPL -- there are cases where unambiguously MPL code could be included in a copyleft-next project, if only copyleft-next allowed for it.
Maybe it'd be nice to allow inclusion of code under any copyleft license (that is actually a free software license of course) to the extent copyleft-next can allow it, in the way the draft had stated for EPL (not weakening copyleft-next's copyleft, except with respect to the files included under other copyleft). But it'd only make a difference for weak copylefts, or future strong copylefts that explicitly address copyleft-next or general class strong copylefts.
Mike