[copyleft-next] Update 2012-08-15

Richard Fontana fontana at sharpeleven.org
Thu Aug 16 00:45:48 UTC 2012


Hi,

Here's yet another weekly update on what's been going on with the
copyleft-next draft.

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.

My idea here was that there is an inherent problem of trust raised by
these 'or later' clauses (especially where built into the license, but
also where, as with the GNU GPL, 'or later' licensing is encouraged
and all license versions indicate that absence of an indicated version
constitutes permission to use any version). Since the FSF and OSI are
establishm^Hed organizations that are perceived as not necessarily
agreeing on things all the time, perhaps giving these venerable
organizations a sort of veto power on the Copyleft-Next Project's
designation of future versions is a decent idea. Or maybe not. Note
that under this kind of provision, the Copyleft-Next Project could
still issue a 2.0 license but it just wouldn't be one that 1.0
licensees could 'relicense' to via the built-in or-later clause. Cf.
the mostly-ignored 'proxy' provision in the corresponding sections of
(A)GPLv3.

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
necessary.

As noted on the mailing list, I have deleted the
anti-anti-circumvention provision. The offer remains open to restore
it if anyone can explain to me a real-world scenario where it
accomplishes something worth ~9 lines of license text.

I reduced the 'Minimum Period' for Corresponding Source availability,
where CS is made available on the net, from 3 years to 2 years, on the
assumption that this was not problematic.

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".

For those who care about word counts, vanilla copyleft-next continues
to shrink (though I think we are about at the limit now and if
anything the license is likely to get longer). (And we still have a
FIXME for the System Libraries definition. :)

GPLv3:                 5644
GPLv2:                 2968
MPL 2.0:               2435
Apache License 2.0:    1581
copyleft-next:         1431

  - Richard



More information about the copyleft-next mailing list