Hacker News new | ask | show | jobs
by teddyh 676 days ago
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.

2 comments

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