On Wed, Aug 15, 2012 at 8:38 PM, Richard Fontana
On 08/15/2012 09:31 PM, Luis Villa wrote:
>> I have mostly deleted an earlier idea of listing representative
>> permissive licenses as inbound-compatible to guide interpretation of
>> what "Further Restrictions" means. Instead, I assume that figuring out
>> inbound license compatibility will be no more difficult than it was
>> under GPLv2. The one exception is that I explicitly provide for
>> Apache License 2.0 compatibility, because this is both useful and
> I am tempted to say that, once this language is refined, it should be
> split off and turned into a general-purpose additional permission
> exception for GPL *2*.
I want Apache License 2.0 code to be compatible with copyleft-next
works without need to invoke the separate permission to 'relicense'
under a version of the (A)GPL. (I'm not sure if that's what you were
Ah, I had not looked at the latest draft before opening my mouth.
I am less optimistic than you about whether or not building an
interpretive tradition works, but perhaps (assuming it ever got that
far) copyleft.next could be published with explicit analysis and
interpretation of various clauses that have previously been treated as
Further Restrictions, and use that to establish the ground rules.
The idea here is that a common sense-based license
compatibility tradition can grow up organically around copyleft-next
much as it did under GPLv2; but the one interesting non-legacy license
which causes problems is the Apache License 2.0, chiefly because of
its section 9. The natural result (without this clause in
copyleft-next) ought to be that section 9 is a 'Further Restriction'.
What I don't want is some general categorical clause of the sort GPLv3
section 7 has authorizing Apache-style upstream indemnification
FWIW, to be historically accurate, this would be "NPL 1.0-style
indemnification clauses." It's still in MPL 2.0, if I correctly
understand the part you find objectionable.