[tgma]

This.

The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing).

AGPL is also not considered a very safe license by large organizations even if you want to run it internally unmodified, alongside the rest of your application. Many big companies have blanket bans on AGPL.

[goodpoint]

There is no deception. You are perfectly free to use, modify and redistribute AGPL stuff. You can publish your changes without signing the CLA.

[jay_kyburz]

What happens if you (the contributor) fork the project, make a really great feature in your own fork, make it available as the license requires, then the startup integrates changes from the fork back into their own project. Does this then prevent them from ever changing the license away from AGPL?

[tgma]

Yes. If they do it they will be able to license the form back as AGPL but that wouldn't let them license the new thing under their commercial license (effectively useless commercially). At that point they are a peer with you.

Some startups may not know this or knowingly violate this.

[goodpoint]

> Does this then prevent them from ever changing the license away from AGPL?

No, as long as they either remove the contributed code or distribute it in a way that is compatible with AGPL

[lmm]

> The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing).

There's nothing specific to the AGPL or startups here, it's a common model. The FSF themselves require copyright assignment if you want to contribute to FSF projects.

[teddyh]

Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.

Secondly, don’t equate the FSF with any other company. The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy; therefore, it’s completely reasonable to also trust the FSF with a copyright assignment.

[lmm]

> Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.

The FSF requires copyright assignment for many (possibly no longer all?) of their own projects, e.g. GnuTLS. Of course it's up to an individual project whether it requires it (how could the FSF possibly control what some unrelated project does?), but on those projects that the FSF themselves run (or at least many of them, and traditionally it was all of them), they require it.

> The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy;

They cannot change the GPL. They can publish new version of it, and recommend that you license your project with a term that permits it to be used under those new versions, but this is not obligatory (and notably e.g. the Linux kernel does not).

[teddyh]

> The FSF requires copyright assignment for many (possibly no longer all?) of their own projects

The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers. Which is what I wrote. The fact that many projects do choose to require copyright assignment does not make you be less wrong when you said that the FSF requires it.

> They cannot change the GPL.

Technically true. But the FSF can publish a new version of the GPL, which all GPL-licensed software using the “or any later version” language, which is most GPL software, will then use. Linux is an oddity here.

[lmm]

> The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers.

And in the case of their own projects, the projects where the FSF is the project/the maintainers, what is it they do? They require copyright assignment.

[teddyh]

What are you talking about? The FSF is not the direct maintainer for any projects, as far as I know. The project maintainers are people.

[powersnail]

> The FSF is in the unique position in that the FSF could change the GPL if they wanted to.

They can publish new versions of GPL if they want to. They can't retroactively change the terms that users of the software and contributors agreed to.

Just like any code owners who has the complete control of copyright can publish their code under a different license.

[richardwhiuk]

GPL includes a line which allows it to be used under any future version of the GPL.

So if you license under GPLv2, the FSF can create GPLv5 and add whatever clause they like in it.

[tgma]

Importantly, GPL does not include such line. That line is not part of the GPL. Critical software such as Linux famously do not have that and are not GPLv3 for example.

The Author can choose to license the Copyrighted Work under various licenses. The common boilerplate that many Authors of GPL software choose to use is a boilerplate that says they are licensing their Work under GPL version X or any later versions supplied by FSF. That boilerplate is Author's declaration of license contract and not the license itself.

Basically the Author is directly saying (not through the GPL text) that "I trust FSF to come up with future licenses and call whatever they want GPL version Y [Y>X] and I'll be willing to license my work under that license sight-unseen also."

[powersnail]

If I accept their license on 2024-08-14 to use their software, they can do whatever they want to the license after that, but they won't be able to revoke my license to use the code as of 2024-08-14 under the license present to me on 2024-08-14.

No update on the license can retroactively change what I agreed to.

[teddyh]

> the FSF can create GPLv5 and add whatever clause they like in it.

They cannot add anything to it; the new license has to, IIRC, be substantially similar in spirit.

[zzo38computer]

That is only if the license of that software says they can use later versions of GPL; it is not automatic.

[tgma]

The model is equivalent. Everything else is different.

FSF's structure, purpose, history and guardrails against non-hijacking make it distinct from a startup whose purpose is to claim "open source" but preclude Amazon and keep their revenue stream. Nothing against them or their business model; it's their prerogative, of course. So is the community and customer's read on their future actions. To claim you should assume they are the same is preposterous and/or fooling yourself. Criminals and police officers both have guns too. Doesn't make them identical.

[lmm]

Organisations that start by claiming to be open-source and rug-pulling are something to be wary of. But neither AGPL nor CLAs are a particular red flag for that. Plenty of well-behaved organisations use CLAs or copyright assignments, and plenty of badly-behaved organisations use licenses other than the AGPL (e.g. Redis had a 3-clause BSD-style license but still did the same thing).

[tgma]

Can’t really refute a hypothetical. Is there a polymarket bet for that? I will categorically take the under on your position for any company doing CLA with AGPL. The intent is so glaringly obvious.