| HN Mirror

So you have Contributor License Agreements that enable you to relicense to something like GPL or MIT whenever you want to?

Because AGPL itself can not be relicensed and it even needed special wording when created to become GPL-compliant.

Since you’re a startup I believe that you use AGPL to achieve the “fair source” idea (https://fair.io/) – where you yourself can provide a hosted service without providing all your source code while hoping others won’t be as they will need to provide all theirs.

In simplified terms: It’s an anti-AWS defense. Helping you avoid being outcompeted by a big cloud vendor using your project without paying anything for it.

And AGPL is a poor “fair source” license, especially as it was never designed to be a “fair source” license but also since it doesn’t give the impression of “fair source” but rather the impression of “open source”, giving an almost deceptive and dishonest look.

And since AGPL is perpetual, unlike eg BSL and FSL, one is stuck with the “fair source” license forever, rather than having it be converted into a mainstream OSS license over time. It can eg make it hard for someone else to eventually, if your company goes away and the project gets abandoned (which is sadly the most likely outcome of most startups), pick up the project and build a company around that while using similar “fair source” principles like you.

If you are doing like what SourceHut is doing (https://sourcehut.org/blog/2022-10-09-ip-assignment-or-lack-...) and going all in on AGPL and playing by its rules yourself as well and treating it as “open source” rather than “fair source”, then well done!

I still would likely want to avoid the legalese complexity of AGPL in my stack though and try to generally stick to permissive licenses and the occasional GPL-licensed projects, like eg Linux. And eg Google has similar guidelines when using OSS-code internally.