On Sat, Mar 21, 2015 at 1:07 PM, Antoine Pitrou <antoine@python.org> wrote:

It's not about meeting the trend, it's about fulfilling developers'
needs. It's not some kind of fad. In a world where more or more free
software projects are libraries rather than end user programs, many FS
developers don't want to burden their project with a strong copyleft
license.

In a world where the majority of software development is funded by for-profit entities (which is certainly a world unlikely to change anytime soon) isn't any degree of copyleft liable to be seen as an equivalent degree of burden? I'd argue, although I have no real data to back me up here, that there's a conceptual leap that folks have to make to accept even the barest whiff of copyleft, especially in commercial software. And in part as a result of that, even once convinced, most will attempt to fulfill the bare minimum of what they see as unwelcome obligations.

The risk then is that the users of code under a lesser-style license will, if extending such existing work, make sure their work never directly touches or becomes derivative of the weak-copylefted code. So you might get many users, but in practice you wouldn't get any more contributors than if you had gone with an entirely permissive license.

The benefit of copyleft-next, IMHO, is to a large degree the concise and readable nature of it. I'm not so convinced that entities who are attracted to the most 'liberal' licenses (especially if their intentions are to create proprietary software) are ever going to be easily convinced of the usefulness of copyleft. But entities who would otherwise be amenable to the actual implications of the GPL, but worry that in the many pages and clauses there will be some sort of 'gotcha', are the sweet spot.
 
Of course, perhaps it's too late and people are accustomed enough to
non-copyleft licenses that they don't feel a need to go back. But I'm
sure I'm not the only one to have evolved from a pro-copyleft position
to a "pragmatic" pro-BSD/MIT stance. Because there is no reliable
middle-ground.

I can sympathize with this argument, certainly. I think it's very important though to clearly define some categorical distinctions between the middle-ground and the pro-BSD/MIT stance, especially since many BSD/MIT proponents seem to see any and all additional stipulations as "less free" (with the exception in some respects of Apache's patent provisions, which I'd posit is mostly due to the general antipathy towards software patents in the same crowd). 

Without some hard lines in the sand, erosion towards fully permissive seems difficult to defend against, and perhaps even more importantly the arguments in favour of weak copyleft need to come across as something other than "it's like that thing you decided not to use, except less so".
 
> And obviously, considering the inherent "and later" language in
> copyleft-next and the explicit GPLv3 compatibility, this license itself
> has to remain nice and strong in its copyleftness, eh?

Well, I'm not sure what is obvious there. GPLv3 compatibility goes in a
single direction (from copyleft-next to GPLv3). A weak copyleft license
doesn't make that any less possible.

Fair point on the single direction compatibility. But I stand by the "and later" (or I guess in terms of the copyleft-next terminology I should say "Later Versions") point, because it would be problematic in several senses to make such later versions different in practice and spirit.

Firstly, in this hypothetical where copyleft-next becomes an outright weak-copyleft license, anyone who has code already licensed under copyleft-next might be unhappy to see their license change out from under them in a way that isn't just keeping up with legal theories and/or closing loopholes but is outright changing the meaning and philosophy of the license itself. [Caveats for this point: perhaps not enough folks have used copyleft-next for this to matter, and I can see the argument that any such change in the nature of the license should take place before widespread adoption.]

Secondly, to dramatically change both the general purpose and the practical specifics of the license would seem to me to weaken the power of the "Later Versions" clause if challenged, as someone could argue that the clear change in intent represents enough of a break that the distributor of the older-versioned copyleft-next'd code can't be assumed to have agreed it to. [Caveat: IANAL so I could be entirely misguided, perhaps the legal enforceability of such clauses is high and no court would accept legal theories attempting to unbind a work from them.]
 
Well, I don't want to rehash them too much here. You could take a look here:
https://lists.fedorahosted.org/pipermail/copyleft-next/2013-May/000674.html


I noticed you're responding there to Richard's stance that

> I have come up with one approach. If you are writing a Python library
> foo and you put it under copyleft-next, and you want me to use your
> library, you ought to have the burden of making clear that the moment
> I merely distribute a file that says 'import foo' my file is ipso
> facto "really copyleft-next". If you did not bother to do this, I
> ought to be free to rely on an assumption you intended something
> 'weaker'.
your response being

> Do note that "using a library" in the Python world can go very far,
> perhaps as far as monkeypatching the library in order to fix some
> undesired behaviour. The license (or its attached FAQ) has to be clear
> that such uses don't entail propagation of copyleft to the application
> as a whole.
This presents two very different approaches to Python code under copyleft-next. Curious to hear what the current theory and best-practice would be considered to be, with everyone having a few years now to mull that over. Perhaps some clarification on this would obviate or otherwise change the discussion, eh?  (In fact, the company I work for recently decided to adopt the usage of Python within our commercial software product, so I'm also quite interested from the perspective of my own job.) 
This might then address or change your unanswered question at https://lists.fedorahosted.org/pipermail/copyleft-next/2013-June/000726.html, Antoine.
On Sat, Mar 21, 2015 at 12:54 PM, Richard Fontana <fontana@sharpeleven.org> wrote:

FWIW at some point I retreated from calling copyleft-next a "strong"
copyleft license to a "non-weak" one (because of the direction certain
structural aspects of it were going in), though I will probably be
reassessing that. I.e. I saw it as potentially occupying some ground
between GPL and whatever a true weak copyleft is. I need to go back
for a reminder of Antoine's specific arguments.

Ah, fair enough. Interested to hear how you possibly reconsider this, then. The idea and label of "non-weak" seems quite reasonable IMHO.