[HN Gopher] GPL upgrades via section 14 proxy delegation
___________________________________________________________________
GPL upgrades via section 14 proxy delegation
Author : weinzierl
Score : 99 points
Date : 2026-03-06 08:41 UTC (14 hours ago)
(HTM) web link (runxiyu.org)
(TXT) w3m dump (runxiyu.org)
| shevy-java wrote:
| > 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.
| weinzierl wrote:
| _" It is often impossible to gain consensus of all copyright
| holders since some may be unreachable."_
|
| How one feels about that is a matter of where one stands. The
| GPL first and foremost protects the interests of _software
| users_. Not developers. Not companies.
|
| In that regard, the above should be seen as a feature, not a
| bug. I believe it is the most effective way to protect the user
| from being locked-in.
| RobotToaster wrote:
| With the "or later" version it's a concern that in the future
| someone nefarious could gain control of the FSF, and publish a
| GPL removing most of the copyleft provisions.
|
| On the other hand, if Linux had used the "or later" version it
| could have helped prevent TiVoization.
| bonoboTP wrote:
| No because tivo could take it under the gpl2. It's not an
| auto upgrade. The new version is optional.
| gzread wrote:
| New distros and modules could be v3-or-later.
| hmry wrote:
| > if Linux had used the "or later" version it could have
| helped prevent TiVoization
|
| Only if the hardware manufacturer used a combined work of
| Linux and some GPLv3-only code, no? Otherwise, if Linux was
| GPLv2-or-later, they could just use it under GPLv2 terms and
| tivoize.
| sellmesoap wrote:
| GPL Vader license, pray I do not alter the deal any further.
| pabs3 wrote:
| According to Conservancy; Tivo didn't do "Tivoization", the
| GPLv3 doesn't prevent what Tivo actually did, and both
| GPLv2/GPLv3 prevent "Tivoization".
|
| https://sfconservancy.org/blog/2021/mar/25/install-gplv2/
| https://sfconservancy.org/blog/2021/jul/23/tivoization-
| and-t... https://events19.linuxfoundation.org/wp-
| content/uploads/2017...
| gzread wrote:
| Linus now has come to _support_ Tivoization. I presume this
| has something to do with where his salary comes from.
| samtheprogram wrote:
| Linus never cared about that use case of the GPL. He cared
| about the source code sharing.
| kube-system wrote:
| Anti-Tivoization is a pretty radical idea that restricts
| the rights of hardware developers for the benefit of
| software developers. Linus doesn't really care about
| strong-arming hardware developers the way RMS does. He just
| cares about the software.
| jmalicki wrote:
| Linus was a little liberal about the restrictions of
| software freedom (boy is that an awkward phrase) even early
| on - e.g. his general acceptance of "binary blobs" in the
| kernel and such for things like NVidia kernel drivers, to
| the chagrin of much harder-core free software people.
| duskdozer wrote:
| It seems that "or later" would be putting an upper bound on the
| GPL restrictions? If additional restrictions are added, then
| users can still choose 3. If any restrictions are removed, the
| users can choose the later version.
| zvr wrote:
| The main advantage for using "or later" is not really to be OK
| when a new version of the license is published, as this happens
| rarely.
|
| What you gain is the possibility of combining this code with
| any other code that is under a later version of the license. If
| there is code X under GPL-2.0-only and code Y under
| GPL-3.0-only, these cannot be combined, since each license
| declares that any derivative work has to be under the same
| license. If code X were under GPL-2.0-or-later, the combination
| would be compliant.
| mikkupikku wrote:
| I have long been skeptical of the "or later" clauses. I can
| imagine a not terribly distant future where RMS has passed away
| and GNU gets taken over by disinterested corporate psychos like
| happened to Mozilla, who then release GPL-4.0 without the
| copyleft, set up for industry looting of any GPL project that
| left in the "or later" clause.
| ronsor wrote:
| I think AI will render software licenses and copyright
| irrelevant long before a hypothetical evil GPL-4 gets
| released.
|
| Most new (corporate-sponsored!) software is already under
| permissive licenses anyway.
| mikkupikku wrote:
| True.. my hope is that open weight models will progress to
| the point where they become viable coding agents for
| normies, so that even if open source dies with copyright,
| we will still nonetheless see a renaissance in people
| controlling their own computers, being able to create their
| own programs to solve their own problems. HyperCard on
| steroids, that anybody can use with no technical
| background. We're not there yet even for frontier models,
| but maybe in a few more years..
| anthk wrote:
| If any AI's will be sued into oblivion from Copyright
| holders until the bubble collapses into itself due to LLM
| rot over time due to the lack of curated human input.
| ronsor wrote:
| This is quite frankly not a serious scenario. Once the
| label "national security" gets affixed to anything, you'd
| better be sure it's not going away.
|
| Also, half of all AI development is in China. Why would
| China care about Western copyright holders, or rather,
| why would they start caring?
| danlitt wrote:
| 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".
| shiomiru wrote:
| Isn't that effectively the same as or-later? I can always fork
| your project, change the MAINTAINERS file, and relicense
| without your consent.
| danlitt wrote:
| Uh yes of course, I thought of that and thought "isn't that
| neat" but of course it goes against exactly what the author
| wants. I don't find this fear very natural I suppose! A
| different trusted third party could be nominated, I guess
| (KDE project nominate KDE e.V. for instance).
| happymellon wrote:
| Indeed, it would need to be more specific, and say this list
| of people in this repo.
| duskdozer wrote:
| I think it's not the best, considering the chardet debacle. It
| would make sense though to have clauses indicating what happens
| or who gains the proxy role in the event the original author is
| gone.
| uhoh-itsmaciek wrote:
| 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.
| charcircuit wrote:
| 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.
| LtWorf wrote:
| Except that such a license will most likely be a proprietary
| one and will make all the other contributors angry at you.
| NegativeK wrote:
| 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.
| charcircuit wrote:
| There are times when it is best for the project to stop being
| fully open source. Such a hardline stance that it should
| always be open source and changing that is considered a rug
| pull is a harmful mindset to have as it can result in
| projects dying or missing their shot at success.
| ognarb wrote:
| 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...
| PunchyHamster wrote:
| > 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.
| gwd wrote:
| > 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.
| znpy wrote:
| 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)
| duskdozer wrote:
| Could you not just add that to the license itself?
| Tomte wrote:
| The GPL itself is copyrighted and the FSF expressly forbids
| variants.
| gzread wrote:
| Every project becomes public domain if the copyright holder
| stops being able to sue you btw
| bombcar wrote:
| You enter an "unclear title" scenario which may mean that
| individuals are fine using it, but no company wants to get
| involved because of the risks.
|
| Similar things happen with physical property, where a title
| cannot be cleared and either people just live with it or they
| go to court to get it "reset".
| wang_li wrote:
| When a copyright holder dies, their copy rights pass on to
| their heirs. Depending on the state, this means it can go to
| cousins or twelfth cousins twice removed if that's all that
| is alive. Failing that, it goes to the state. Any/all of
| these could potentially sue if there is money in it.
| gzread wrote:
| They could, which is why I said when the copyright holder
| loses the ability to sue, not when the creator dies.
|
| When it's a twelfth cousin they won't even know they have
| the copyright. Because it's an implicit right, they don't
| enumerate all your copyrights and tell your heir about
| them. The heir has to know.
| jaypatelani wrote:
| How about create a company/corporation and hold all sources under
| it. So directors of that company can change to later versions
| repelsteeltje wrote:
| 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?
| onli wrote:
| Remember that law is not technical. This is a declaration to be
| interpreted. The Interpretation that a specific person with the
| legal name Runxi Yu is designated here is very clear, the link
| just a helper to identify the correct person at the time of
| writing.
| repelsteeltje wrote:
| Thank you for pointing out this mistake. Of course, there
| also is nothing technically preventing anyone to ignore the
| GPL; the license itself is "just" some legalese.
|
| I do believe, though, that these kind of references (from
| paper into the real world) often introduce surprising
| gotchas. Especially when they are intended to address some
| future (mostly unknown) issue.
|
| The designated anchor point (person, technological artifact,
| legal entity) is itself often more likely subject to change
| than the thing it's trying to govern. Persons may be hit by a
| car, registries may expire, companies may go bankrupt.
| Governing laws may change. Countries may cease to exist...
| bombcar wrote:
| The LAW(r) has literally millennia of dealing with these
| kinds of things - especially with regards to physical
| property, the definitions of which may refer to a king of a
| country that hasn't existed for five hundred years. You can
| find all sorts of examples, look to the US southwest or
| Europe or any country that has been controlled by another
| for a time, and then stopped.
| boramalper wrote:
| 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.
| Quarrel wrote:
| 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.
| boramalper wrote:
| > only b is worth speaking of. In b, isn't having someone in
| a position to make a choice much better than no one?
|
| Actually, you're right! I thought the proxy can
| nominate/decide that any other license can be used in the
| future (i.e. "licensed under GPLv3 or X" where _I_ can chose
| X to be anything) but it seems that I was wrong. Re-reading
| more carefully ( _emphasis_ mine):
|
| > If the Program specifies that a proxy can decide which
| future versions _of the GNU Affero General Public License_
| can be used, that proxy's public statement of acceptance of a
| version permanently authorizes you to choose that version for
| the Program.
|
| So FSF creates the future versions of a specific license the
| work is under (in this case AGPL) and the "founder" chooses
| whether to allow its usage or not. That sounds reasonable to
| me.
|
| Thanks for the pushback!
___________________________________________________________________
(page generated 2026-03-06 23:01 UTC)