Some initial comments on the copyleft-next draft

Richard Fontana fontana at sharpeleven.org
Mon Jul 23 01:11:12 UTC 2012


On 07/22/2012 03:35 PM, Mike Linksvayer wrote:
> I don't see any notion of additional conditions via supplements in the
> main license draft. 

The old section 7 of GPLv3 is completely gone in copyleft-next, except
that one sentence has been moved to the no-further-restrictions
section. This is somewhat sad because section 7 is in many respects
GPLv3 at its best. copyleft-next (at the moment) proposes to deal with
inbound license compatibility differently from GPLv3 (though reaching
almost the same practical results), by giving examples of a few
well-known licenses that are compatible. I don't entirely like that
mechanism but I think it is superior to the one in GPLv3.

Apart from the Apache License, where I now think the better approach
(specifically avoided in GPLv3) is to single it out for explicit
compatibility, supplemental additional conditions should be allowable
under copyleft-next to the same degree they are under GPLv2, and
understanding of what sorts of conditions ought to be allowable should
have some space to evolve. This is partly motivated by a desire to
shorten and simplify the license.

> 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 don't think it would have been better, although I think the fears of
a plethora of Affero-ish licenses and ad-hoc conditions were overblown.

> In any case, copyleft-next+ws-supp
> relicensing under anything other than AGPLv3[+] doesn't make much
> sense.

Relicensing under GPLv3+ doesn't make sense there, but I suppose
relicensing under "GPLv2 only" could. For a practical historical
example, consider the license of stet. Bradley Kuhn has noted that
stet was the first software to be released under AGPLv3, which is
technically true. However, the actual license notice, which Bradley
and I came up with, said this:

  This notice constitutes a grant of such permission as is necessary
  to combine or link this software, or a modified version of it, with
  Request Tracker (RT), published by Jesse Vincent and Best Practical
  Solutions, LLC, or a derivative work of RT, and to copy, modify, and
  distribute the resulting work.  RT is licensed under version 2 of
  the GNU General Public License.

*At the time* I considered this clever.

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

That's an interesting idea.

>> 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?

Most contributions to projects don't have any explicit licensing
information, so in most situations this will reinforce what I'd argue
would already be implicit. You can imagine situations where someone
might wish to contribute a patch under explicitly more permissive terms.

>> 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? 

No, that is currently not made explicit. But I suppose it should be,
as otherwise it might be read as suggesting that a licensee is
generally free to license modified versions of copyleft-next code
under proprietary licenses.

- Richard





More information about the copyleft-next mailing list