On Wed, Aug 15, 2012 at 5:45 PM, Richard Fontana
Here's yet another weekly update on what's been going on with the
One of the more interesting changes I made this week was in the 'Later
License Versions' section (as it is now known). It was previously
written as a built-in "or-later" provision of the sort we see in a
number of FLOSS licenses such as MPL and EPL. I (for lack of any
better alternative) used 'the Copyleft-Next Group' (now the
'Copyleft-Next Project') as the name of the license steward authorized
to publish newer versions of the license. 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?
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
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 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 the
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? :)