The only real technical hurdle I could see (also being a non-lawyer) is defining who the governance is? What would be a good, generalized method of defining it be?

The best thing I can think of would be a "STEERING.txt" [0] which is a text file with one or more persons who are "in charge" of a particular project/fork. In some projects it could be the BDFL, in others it could be council members who vote [1]. Similar concept to a MAINTAINERS.txt file.

The basic idea is that you can't change that list without having write access to that particular fork. If I fork the project though, I could rewrite that file however I want as I'm the person in charge of that fork.

Changes shouldn't be merged that add people to it without warrant. Any time you submit a merge request that doesn't touch that file, you're agreeing the people in that file could move the licence to a later version at some point in the future. [2]

If I do fork the project, I'm still bound by the original licence, obviously, even though I'm the new owner. So there may be a restriction that I can only change the licence of my fork to a same or later version of copyright-next. [2] I don't think it makes sense to allow going backwards?

[0] Name open to better suggestions.

[1] I'm tempted to say the contents should be in the form of # comments, to lay the groundwork for future machine-readable versions of this file, specifying eg, leadership, voting requirements, and other pertinent governance information. Sort of like machine-readable licence identifiers in file headers. But that's not relevant right now.

[2] Maybe even to a different copyleft licence in some especially-permissive projects?

The only real technical hurdle I could see (also being a non-lawyer) is defining who the governance is? What would be a good, generalized method of defining it be?

Not sure. I don't hate your suggestion of having a standard place where these are defined, but:

• I think the license shouldn't get into the business of specifying filenames and formats. Too many possibilities of that getting limited.
• I think a list of names is both too rigid and too limiting. (If it's a list and people disagree, how is that resolved?) For example, for something released as part of the Fedora Project, we might want to say "by approval of the Fedora Council using the full consensus process" — or, "by approval of the Fedora Council using the lazy consensus process with a period of at least seven days following an appropriate announcement". (Whereas for something I release on my own, it might simply be "if Matthew feels like it".)

That's why my idea was something like "following the project's normal governance structure".

Maybe there's something in the middle, like:

The Copyleft-Next Project may release new versions of copyleft-next,
designated by a distinguishing version number ("Later Versions").
Documentation accompanying the Corresponding Source of the
Covered Work may include a description of a process for allowing
Distribution of Covered Works under such a Later Version. Such
documentation may also explicitly remove the option of Distributing
Covered Works under Later Versions, or grant that option for any
Later Version.

On the other hand, this could become complicated quickly (the very thing I want to avoid!) if there are multiple sources of copyleft-next code merged into one project. (Keeping track of that is potentially a problem already just with the "explicitly remove the option" wording in the current license.) But I'm not sure that's avoidable — using your STEERING.txt suggestion, it's tempting to say "if you merge in code from different sources, merge the STEERING.txt", but that could lead to a bad outcome where a small project gets merged into one with many voters — potentially even maliciously simply for the purpose of changing the vote. And if you say "everyone in STEERING.txt must agree"... it's back to the original problem.

Re: defining governance, I think the licence should provide the flexibility to allow a project to define it's governance however it wants. Ideally it should just say "the decision is up to whoever is in charge, however that's decided or defined." My only concern is people who don't know better trying to make up their own legalese definition of their governance.

It may be helpful for the licence to offer some common defaults like "benevolent dictator for life" or "simple majority of council" that someone can select much like they'd pick "or any later version" or "only this version." The choice should still allow a "make up your own governance" option.

I'm sure defining "who's in charge" is a common legal problem and hopefully a real lawyer can supply some common boilerplates.

Re: multiple sources of code being merged into the same project
Yeah, you raise a good point. I was thinking of small forks that are quickly merged back into the mainline. In that case you have a relatively limited number of people working on it, and it was derived from the same legal situation as the thing it's being merged into.

The project and merge may have older, newer, or the same licences, and either one may try to lock to a particular verison.

I think it's reasonable that the versioning version/capabilities/restrictions of the larger project you're merging into should prevail in the case of a combination. However, the person(s) supplying the merged code need to be in an authoritative position to say that the versioning info of the thing being merged can be changed. If we can define who that is, then I think the core change this issue proposes makes that work. The core idea is to give "someone" the power to make that decision.

Note: in order to work, this may require having the option to downgrade the licence, not just upgrade it

This does raise a possible side benefit of the change you propose: enhanced compatibility between different codebases under the same licence but different versions (and different version restrictions) thereof.

It also highlights one significant change though: under the merging rules above, the person who first created and licenced a codebase doesn't have absolute say over it's licencing forever. If they allow it to be merged into another codebase, then that new codebase's governance does instead. This includes everything from small pull requests to large projects that join the source tree of another project.

Under the rules I proposed (and I want to highlight: just proposed!) that control is being given up willingly but lots of people are very fickle about maintaining eternal control. Or, are very comfortable about the code they submit remaining under the same licence forever. This change is very much about allowing people to trust and cede some of that control to a project's governance.

EDIT: tbh, this case of large projects being merged together is a really hard one. Linux and ZFS are a famous example. I don't think it's ever been pulled off unless either they're both under the same licence to start or one of them is permissively licenced.

Food for thought: Most projects accomplish the above with a CLA or similar that gives up contributors' copyrights (I believe many require you assign your copyrights to the FSF for example?) so that the project in question can manage them. Since future versions of a licence can change the restrictions arbitrarily, is there any practical difference between giving up your copyrights or allowing arbitrary re-licencing?

Edit: I suppose you could revoke your right in the future, if you wanted. An action that would require you to voice your dissent. Maybe it's enough to require that people voice their dissent within some time frame before switching licences, as opposed to requiring unanimous active/explicit agreement?

Would it makes sense to instead impose requirements on future licence versions that could be relicenced to? (I'm going to trust you to manage the project, but there are some hard rules you can't break) In that case, is there a legally specific enough definition of copyleft, for example?

Right, a specific goal is avoiding the need for a CLA or for something as huge as copyright assignment.

Additionally, I would like the permission to be narrow: limited to official, designated successors to this license, not a general ability to relicense to anything. (That ability often makes CLAs asymmetric — open source rules for everyone but the "owner". I don't want that, at all.)

The tricky bit is that a new version of a licence could technically be anything.

Ironically, the FSF provide a perfect example in the form of wikipedia. According to [1] at least, wikipedia were originally stuck licenced under the GFDL. They asked the FSF to produce a newer version that then allowed them to relicence under the CC-By-SA. As pointed out, the people who contributed under the GFDL may not have expected that to happen when they originally contributed.

Anyway, I should probably have clarified that point. If you allow "any later version" of a licence, you're opening the door to whatever the author of that licence may decree in the future.

Now, maybe that isn't an issue if you trust the people who wrote your licence. But, it is a reason why some people choose to omit the "or any later version" clause, locking their contribution to a specific known licence (with linux(?) being a common example). I suppose the assumption is that they could always just grant permission again in the future, and that is true, though it gets complicated with a project that has lots of contributors.

Trying to balance all of this out, I think maybe the best compromise is to allow project leadership to upgrade to any later version of the same licence, except in the case that a copyright holder voices an objection within some reasonable time period?

Then the project can move to a new version if it makes sense, and if someone has a problem with it you know specifically who and maybe why. You aren't trying to track down every single contributor that may be dead/missing/etc to get their consent.

If someone does wield this "veto power" then there exists the possibility that you could negotiate with them, or could fork from a version that doesn't have their contribution or something. The point is that the state of things at that point is known and you can actually work to address the concerns.

[1] https://www.theguardian.com/world/2013/oct/01/jellyfish-clog-swedish-nuclear-reactor-shutdown

Right, the first part of that seems to just be restating the problem. :)

I do think the idea of a reasonable time period for objections might address some of the other concerns we've talked about.