On Wed, Jul 18, 2012 at 7:40 PM, Richard Fontana fontana@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