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.
> 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.
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.
"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.
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.
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.
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.
> Anti-Tivoization is a pretty radical idea that restricts the rights of hardware developers for the benefit of software developers.
How does anti-tivoization restrict the rights of hardware developers, considering that hardware developers can choose not to pre-install anti-tivoization-licensed/contracted software? Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes, using encryption to communicate only with certain other pieces of hardware, or for that matter, any restrictions at all. All in the name of enabling hardware developers to tinker with their hardware without those pesky software developers getting in the way with their pesky encryption.
> Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
In the way that all copyleft enforcement requires copyright, then yes… but what does that have to do with anything?
I think Linus was spot on about the FSFs scope creep when he said:
“The kernel license covers the kernel. It does not cover boot loaders and hardware, and as far as I'm concerned, people who make their own hardware can design them any which way they want.”
>> Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
> In the way that all copyleft enforcement requires copyright, then yes… but what does that have to do with anything?
What rights of hardware developers does anti-tivoization restrict? For example, do you believe in a moral right (or a strong moral privilege) for hardware developers to install any software of their choosing on their own hardware? Most hardware-agnostic software copyright licenses and the lack of a copyright license restrict such a right/privilege. Porting most proprietary software to your own custom hardware would violate copyright (unless your port is a clean-room rewrite) because copying most proprietary software to anywhere including an instance of market-standard hardware would violate copyright. Actually, a FOSS license with an anti-tivoization clause does not prevent a hardware developer from installing or modifying covered software: the license conditions do not trigger until the software (or hardware containing the software) is distributed (as with the GPLv3) or a modified version of the software is run over a network (as with the AGPLv3).
> Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes, using encryption to communicate only with certain other pieces of hardware, or for that matter, any restrictions at all.
The concept that software "runs on" hardware and not the other way around makes a massive difference in how I believe hardware should be able to restrict software vs. how software should be able to restrict hardware. Letting a human validate the appropriateness (however that may be defined, including and not limited to criteria unrelated to structural integrity) of a bridge will have more moral use cases (both as a percentage of use cases and as absolute "numbers" of use cases) than letting a bridge validate the appropriateness of a human trying to cross it.
> Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes
(I would generally disapprove of both a hardware license that prohibits software from validating the hardware and a software license that prohibits hardware from validating the software.) Morally speaking, I might oppose a particular program that shuts down if the hardware has been repaired by a third-party while simultaneously supporting a particular program that shuts down if the hardware randomness module has been altered. I might oppose a particular computer that refuses to run DeCSS while simultaneously supporting a particular computer that refuses to run cryptocurrency miners.
Does anti-tivoization prohibit hardware from validating software, or does anti-tivoization merely prohibit hardware from acting on a detection of invalid software?
> All in the name of enabling hardware developers to tinker with their hardware without those pesky software developers getting in the way with their pesky encryption.
How does anti-tivoization get in the way of tinkering by hardware developers, considering that (1) the hardware developer chooses which kernel and which operating system the hardware ships with and (2) a FOSS license with an anti-tivoization clause does not restrict personal use any more than an otherwise equivalent FOSS license without such a clause does? Are the hardware developer's rights restricted if a buyer of the hardware can't install a kernel or operating system of the buyer's choosing?
> 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.
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.
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..
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.
Because China it's making good Wuxia movies today and they woudn't neither like being ripped off if they exported either their movies or manhua to the West.
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.
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?
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.
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...
The LAW® 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.
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".
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.
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).
> 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.
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".
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.
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.
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.
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.
> 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.
It's really best to pin down a concrete license rather than a template with <insert-unknown-stuff-here> variables. No "or future versions", no proxies.
> 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.
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.
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.
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.
"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.
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.
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...
No because tivo could take it under the gpl2. It's not an auto upgrade. The new version is optional.
New distros and modules could be v3-or-later.
Linus now has come to support Tivoization. I presume this has something to do with where his salary comes from.
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.
Linus never cared about that use case of the GPL. He cared about the source code sharing.
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.
> Anti-Tivoization is a pretty radical idea that restricts the rights of hardware developers for the benefit of software developers.
How does anti-tivoization restrict the rights of hardware developers, considering that hardware developers can choose not to pre-install anti-tivoization-licensed/contracted software? Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
You can also choose to not buy a TiVo?
Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes, using encryption to communicate only with certain other pieces of hardware, or for that matter, any restrictions at all. All in the name of enabling hardware developers to tinker with their hardware without those pesky software developers getting in the way with their pesky encryption.
> Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
In the way that all copyleft enforcement requires copyright, then yes… but what does that have to do with anything?
I think Linus was spot on about the FSFs scope creep when he said:
“The kernel license covers the kernel. It does not cover boot loaders and hardware, and as far as I'm concerned, people who make their own hardware can design them any which way they want.”
>> Is it anti-tivoization that restricts the rights of hardware developers, or does copyright law do that?
> In the way that all copyleft enforcement requires copyright, then yes… but what does that have to do with anything?
What rights of hardware developers does anti-tivoization restrict? For example, do you believe in a moral right (or a strong moral privilege) for hardware developers to install any software of their choosing on their own hardware? Most hardware-agnostic software copyright licenses and the lack of a copyright license restrict such a right/privilege. Porting most proprietary software to your own custom hardware would violate copyright (unless your port is a clean-room rewrite) because copying most proprietary software to anywhere including an instance of market-standard hardware would violate copyright. Actually, a FOSS license with an anti-tivoization clause does not prevent a hardware developer from installing or modifying covered software: the license conditions do not trigger until the software (or hardware containing the software) is distributed (as with the GPLv3) or a modified version of the software is run over a network (as with the AGPLv3).
> Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes, using encryption to communicate only with certain other pieces of hardware, or for that matter, any restrictions at all.
The concept that software "runs on" hardware and not the other way around makes a massive difference in how I believe hardware should be able to restrict software vs. how software should be able to restrict hardware. Letting a human validate the appropriateness (however that may be defined, including and not limited to criteria unrelated to structural integrity) of a bridge will have more moral use cases (both as a percentage of use cases and as absolute "numbers" of use cases) than letting a bridge validate the appropriateness of a human trying to cross it.
> Imagine if the situation was the other way around and a CPU came with a hardware license agreement prohibiting any software that ran on it from validating hardware attributes
(I would generally disapprove of both a hardware license that prohibits software from validating the hardware and a software license that prohibits hardware from validating the software.) Morally speaking, I might oppose a particular program that shuts down if the hardware has been repaired by a third-party while simultaneously supporting a particular program that shuts down if the hardware randomness module has been altered. I might oppose a particular computer that refuses to run DeCSS while simultaneously supporting a particular computer that refuses to run cryptocurrency miners.
Does anti-tivoization prohibit hardware from validating software, or does anti-tivoization merely prohibit hardware from acting on a detection of invalid software?
> All in the name of enabling hardware developers to tinker with their hardware without those pesky software developers getting in the way with their pesky encryption.
How does anti-tivoization get in the way of tinkering by hardware developers, considering that (1) the hardware developer chooses which kernel and which operating system the hardware ships with and (2) a FOSS license with an anti-tivoization clause does not restrict personal use any more than an otherwise equivalent FOSS license without such a clause does? Are the hardware developer's rights restricted if a buyer of the hardware can't install a kernel or operating system of the buyer's choosing?
The entire GPL is a radical idea that restricts the rights of software developers for the benefit of software users.
> 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.
GPL Vader license, pray I do not alter the deal any further.
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.
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.
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..
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.
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?
Because China it's making good Wuxia movies today and they woudn't neither like being ripped off if they exported either their movies or manhua to the West.
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.
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?
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.
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...
The LAW® 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.
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".
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.
Isn't that effectively the same as or-later? I can always fork your project, change the MAINTAINERS file, and relicense without your consent.
Indeed, it would need to be more specific, and say this list of people in this repo.
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).
> 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
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".
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.
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.
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)
Could you not just add that to the license itself?
The GPL itself is copyrighted and the FSF expressly forbids variants.
Got it, yeah I see that now
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.
> 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!
It's really best to pin down a concrete license rather than a template with <insert-unknown-stuff-here> variables. No "or future versions", no proxies.
> 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.
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.
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