Some initial comments on the copyleft-next draft

Mike Linksvayer ml at gondwanaland.com
Sun Jul 22 19:35:18 UTC 2012


On Wed, Jul 18, 2012 at 7:40 PM, Richard Fontana
<fontana at sharpeleven.org> wrote:
> I removed the so-called 'anti-Tivoization' provisions of GNU GPLv3 section 6
> out of vanilla copyleft-next and into a separate document currently called
> "dl-supp". I also added a separate document called "ws-supp" containing
> substantially similar text to the first half of the GNU AGPLv3 section 13. I
> don't think I really explained this in the commit logs so I'll go into that
> a bit here. The idea is that the vanilla version of copyleft-next won't have
> an 'Affero clause' (much as GNU GPLv3 doesn't) and, unlike GNU GPLv3, it
> won't have 'anti-Tivoization' provisions. Only the *initial* licensor
> (someone who's starting a new work from scratch) can choose to supplement
> copyleft-next with one of those "supp" documents. Currently, vanilla
> copyleft-next is incompatible with {copyleft-next + dl-supp} and
> {copyleft-next + ws-supp} (much like "GNU GPLv2-only" is incompatible with
> GNU GPL3) (i.e. there's nothing corresponding to GPLv3/AGPLv3
> cross-compatibility), though this is just because I deferred thinking about
> whether there should be compatibility or not.

If the supplements remain, I'd hope for as much compatibility as
possible; something like the GPLv3/AGPLv3 mechanism seems fine.

I don't see any notion of additional conditions via supplements in the
main license draft. If they remain, will the license explicitly only
allow certain supplements? I'm somewhat skeptical of switches that
turn on significant further restrictions in any case. The FDL is the
nearest example of this I can think of (switches built in rather than
as supplements) which produces ugly notices, independent of the
non-freeness of those switches. I suppose MPL2's compatibility opt-out
is another example, but I haven't seen it used yet.

It is also not clear how the two draft supplements would work with
GPLvn compatibility (which of course I think maintaining is a good and
necessary thing). I'm not sure the affero clause implemented as a
permissible restriction in GPLv3, rather than as a separate license
with a compatibility mechanism, would have been better; I suspect it
would be more confusing. In any case, copyleft-next+ws-supp
relicensing under anything other than AGPLv3[+] doesn't make much
sense.

It'd be boring and relatively inflexible, but one way to go would be
copyleft-next without lockdown and service features, compatible with
all FSF strong copylefts, and arch-copyleft-next, compatible only with
AGPLv3+.

Above is just rambling. I realize that the supp mechanism might be
experimental and I may not understand.

> I added a provision similar to Apache License 2.0 section 5 which is
> something like a built-in "inbound=outbound" contributor agreement for
> projects. (While I like this Apache feature very much it is a bit awkward in
> copyleft-next in its current form.)

I love the section name. I don't understand (purely because I'm
ignorant) how this works -- specifically, doesn't "unless" make it
meaningless? At least if there's no limitation on what "unless" terms
can be?

> I added a provision to the basic copyleft clause that is designed to remove
> the copyleft requirement if the licensor separately offers a proprietary
> commercial version of essentially the same software. Maybe this isn't
> worthwhile, but it was something I'd wanted to experiment with trying to
> implement for a long time.

I enjoy this provision, a lot. Does it clearly only apply to offers of
proprietary versions that the offerer actually has the rights
necessary to legitimately offer?

Mike


More information about the copyleft-next mailing list