On Thu, Oct 11, 2012 at 10:45 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
Mike Linksvayer wrote on 9 August:
there are cases where unambiguously MPL code could be included in a copyleft-next project, if only copyleft-next allowed for it.
Honestly, I'm not convinced that a truly strong copyleft can allow unilaterally inclusion of other copylefted code -- even weak -- without bilateral compatibility clauses.
I don't see why not, when the weaker copyleft's scope is unambiguously a subset of the stronger one's. MPL and copyleft-next seem such a case. One can comply with MPL's file-scoped copyleft by keeping MPL'd files under MPL. These could be incorporated in a copyleft-next project if copyleft-next permitted it. Maybe (wild speculation!) they can be even if not explicitly permitted, just as permissively licensed files can be.
We have to consider that such provisions while seemly safe on the surface may actually be manipulated to undermine the stronger copyleft by enterprising defense attorneys.
Ok, I now see "truly" as an important qualifier to "strong copyleft can allow...". Additionally, added complexity may not be worth it.
and
Richard Fontana wrote on 2 September:
This proposal might make the most sense for licenses that are generally considered non-copyleft but GPL-incompatible (the proposed language seems modeled on things like the [I believe FSF-recommended] OpenSSL GPL linking exception). For copyleft licenses, it raises the same problem on a more general level that we dealt with when thinking about a clause that would achieve EPL compatibility.
Exactly. I think anyone who wants this kind of compatibility has to prove that it can't be used by the nefarious to circumenvent copyleft.
Note that the ways copyleft is subverted are subtle and complicated. Most people don't see that because they rarely get the rather horrible experience of regularly dealing with people who are trying. You may have to take my word for it that this happens, but if folks want to raise specific questions, I'm happy to talk about it in detail. There's enough of it and it's common enough that it's difficult to generalize.
I'm curious about how one would exploit (as in undermine strong copyleft) permission to add MPL licensed files to a copyleft-next project, files remaining under MPL. I guess that one would start by contributing MPL files, and eventually rewrite copyleft-next portions, such that the whole project consists of nothing but MPL files. In some case I guess this could make avoid-strong-copyleft-through-reimplementation more feasible by providing a bridge to such. But I'm guessing you have one or more nefarious strategies in mind?
Mike