Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



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.


> 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).


> 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.


> 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.


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.


Many GNU projects are maintained directly by the FSF/GNU (the same entity; their own statements acknowledge that they share personnel and have no clear boundary between them). And for many more projects they hold the copyright and provide the funding/hosting/etc. and the named maintainer is either a member or affiliated with the FSF/GNU, which suggests they exercise some control over it (e.g. the published hosting requirements for Savannah say that projects they host "should" follow the GNU hosting standards, which include requiring copyright assignment to the FSF if the FSF holds the copyright).


And the named maintainer has the right to not require CLA:s for their project. The FSF does not require the maintainer to require CLA:s.


Well, requiring copyright assignment (not just a CLA) is in their published rules for using Savannah, and something almost all major GNU/FSF projects did in the past. Even if it's now something they merely encourage rather than require (and I'd be interested to see a public confirmation of this) my point stands.


> 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.


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.


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."


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.


> 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.


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


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.


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).


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: