On 08/15/2012 09:31 PM, Luis Villa wrote:
On Wed, Aug 15, 2012 at 5:45 PM, Richard Fontana
> I have now revised this to
> state that any newer version released by said Copyleft-Next Project
> will not be 'Authorized' unless it is approved as such (as a sucessor
> to the earlier copyleft-next) by both the FSF and the OSI.
Can you clarify what this means, as OSI does not confirm "successors" per se?
It rests on an admittedly fanciful assumption that both the FSF and
the OSI would at least begrudgingly accept the role of deciding
whether copyleft-next 2.0 was worthy of being a successor to
In the worst case it just means no 'or-later' effect. Though that is
not desirable. I don't really know how to solve this trust problem,
particularly given that the license is currently quasi-imaginary. :-)
> the mostly-ignored 'proxy' provision in the corresponding sections of
Which I really liked, actually, but were unworkable for compatibility
reasons - if LO designates the LO Foundation as "proxy" for
MPL2-licensed code, and Mozilla designates MoFo, what happens to mixed
It could still be used under MPL2, right?
But in the (A|L)GPLv3 world the proxy option has been almost entirely
> 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
getting at.) 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
clauses. I have already seen misuse of this (of course by 'proprietary
relicensing' companies using GPLv3/AGPLv3).
> I reduced the 'Minimum Period' for Corresponding Source
> where CS is made available on the net, from 3 years to 2 years, on the
> assumption that this was not problematic.
Any specified length of time is problematic for daily-build QA
strategies (unless the language allows pointing to a specific RCS
revision as acceptable source); this was one of our primary reasons
for avoiding it in MPL.
> I broadened and put into a separate section what has been called
> proprietary-relicensing 'poison pill' (I briefly used that as the
> section title). Now, if the original licensor proprietary-relicenses,
> most of the conditions of the license vanish for the licensee, so
> copyleft-next turns into an ultra-permissive license. On the other
> hand, the provision is narrowed to apply only where the
> proprietary-relicensing is done for "commercial gain".
Which means... what, exactly? :)
Precisely, I was thinking about that earlier. It calls to mind the
uncertainty over how to interpret the "NC" Creative Commons licenses.
It is probably better to take 'commercial gain' out. I still like the
provision itself though.