We do that in KDE too, where the decision to update to a possible gpl4 is decided by a vote of the KDE e.v. (the legal non profit organization behind the project) membership.

https://invent.kde.org/office/marknote/-/blob/master/LICENSE...

> I find neither approach to be ideal. It is often impossible to gain consensus of all copyright holders since some may be unreachable.

Well, licences are not universal wonder tools. They have restrictions about their use cases. But, narrowing this down solely to "GPL xyz" versus "GPL xyz - or later fancypants", I always found the variant WITHOUT the "or later" to be better. It simply adds more complexity when a licence can willy-nilly be changed, at a later time, when a change happens. I understand the use case for the "or later" part, as the GPL is very strict as well as an ideological tool against abuse from corporations (let's be honest here; and I think the GPL is a good licence, despite this too), but even then I find it better to stick to the simpler variants. It is one reason why I may use GPLv2. I also use MIT/BSD when I essentially don't care much. I don't think I have had a use case for GPLv3; and not for "or later" either. LGPL is also fine.

> It’s patently clear that the license allows this, and it surprises me that this is rarely brought up in debates about GPL-3.0-only and GPL-3.0-or-later.

I was unaware that a proxy can be designated upfront; so that's another complexity with regards to the "or later" part. What can proxies do? I dislike the "or later" clause; it really just makes this way more complicated than it should be.

Can I (pedantically) raise an epistemic issue with:

> Pursuant to Section 14 of the GNU Affero General Public License, Version 3.0, [Runxi Yu] is hereby designated as the proxy who is authorized to issue a public statement accepting any future version of the GNU Affero General Public License for use with this Program.

Notice that [Runxi Yu] is an external reference, pointing to runxiyu.org.

Wouldn't this mean that the designated proxy is (any?) future entity claiming to be Runxi Yu and substantiating that claim by demonstrating control over DNS entry for runxiyu.org could effectively upgrade the GPL licence? Or practically, if the domain registration lapses, a hacker takes control or Runxi Yu looses interest — what might happen to the license? And how would this affect any contributers?

A risk of putting in a literal person is that you might stop maintaining the project, and changing the maintainer is now effectively a license change. It may be better to say "consensus among whoever is currently maintaining the project, as specified by the file MAINTAINERS".

> It’s patently clear2 that the license allows this, and it surprises me that this is rarely brought up in debates about GPL-3.0-only and GPL-3.0-or-later.

It's an interesting avenue, but the ultimate problem is that people die and/or lose interest in projects. What happens to this particular project if Runxi dies, or decides to make furniture out of wood instead? That basically becomes "GPL-3.0-only" again.

Every project becomes public domain if the copyright holder stops being able to sue you btw

Not quite - copyright passes to heirs or estates when the holder dies, so it doesn't simply lapse. You might be practically safe from litigation, but that's different from public domain. The term still runs 70 years post-death in most jurisdictions. Orphan works are the real grey area - technically still protected, often unenforceable, but not actually public domain.

I wonder if one can leave written what to do in such cases in their will.

(Similarly to what the author of the article wrote: i’m not a lawyer and this is not legal advice)

So it's GPL-3.0-only with extra steps.

So it's basically GPLv3-or-later but with veto power of the "-or-later" part by the maintainer (but not the contributor). That's pretty clever. And, since you're asking someone to maintain your contribution, it also seems pretty fair.

If you are an individual developer, please don’t do this. I think proxy delegation is best suited to an organisation (ideally to a non-profit) whose lifespan is longer than of a solo developer and more likely to have “checks and balances” that protect all maintainers’ rights vs just you and yours.

If you don’t want to hand FSF a carte blanche regarding your project—perfectly understandable—then pick a “version X only” variant and move on.

Why?

It seems like there are two options:

a) The "founder" of the code disappears in to the ether, and it is the equivalent of "version X only";

b) The "founder" stays involved, and if GPL 3 is updated, they can choose.

only b is worth speaking of. In b, isn't having someone in a position to make a choice much better than no one? What is the boogie monster that is the worry? The FSF puts out the 4.0 version, with a special "except for boramalper" clause, that lets you specifically monetise the hell out of it while keeping it closed source? I would not lose much sleep over that.

Stallman is a nutcase, in an endearing way (ok, maybe you have to have moved in the right circles). But he has put in place a system that needed just such a nutcase, who established clear black lines that could not be crossed, and who was also writing enough amazingly meaningful code that we needed to take his license seriously, that could then establish the institutions and governance to make it all live beyond him.

Minor pedantic thing: it's boogeyman, not "boogie monster". I could be wrong, maybe both work. Anyway, your broader point holds - proxy delegation means someone can actually make a call when GPL 4 arrives, rather than everything just staying frozen at v3.

> It’s patently clear2 that the license allows this, and it surprises me that this is rarely brought up in debates about GPL-3.0-only and GPL-3.0-or-later.

There is nothing surprising about it as the contentious issue about GPL3.0 is the patent claim one (which did cause multiple companies go "HELL NO we're not touching GPL with 100m pole"), not this.

This still gives too much power to the FSF. It is better to use a CLA and have the proxy be able to switch over to any license when the need arises.

CLAs have a use beyond shitty anti-open source rug pulls, but they've been abused enough that I'll trust the FSF first.

And I fully acknowledge that the FSF isn't and will never be perfect.

We tried the CLA route and it backfired exactly like LtWorf says — contributors got skittish the moment they realized we could relicense to something closed. Lost two good maintainers over it. The FSF constraint is actually the feature, not the bug. Nobody's worried you'll pull the rug.

Except that such a license will most likely be a proprietary one and will make all the other contributors angry at you.

How about create a company/corporation and hold all sources under it. So directors of that company can change to later versions

We added a section 14 proxy clause to our project's NOTICE file two years ago. The tricky part nobody mentions: it only covers contributions made after adding the clause. All those commits from contributors who disappeared in 2018 are still GPL-3.0-only unless you tracked them down. We ended up auditing three years of commit history.