[VoxPelli]

The AGPL license is a no-go for me.

While it’s technically true that it’s an OSI license it’s mostly used to scare away competing cloud vendors from hosting the software, which isn’t in spirit of OSS.

Have you looked into the more modern choices?

Like the Business Source License that MariaDB created and uses or the Functional Source License that Sentry created as an improvement over the Business Source License? https://fsl.software/

Both those licenses have a fair source phase that automatically resolves into an open source phase over time.

Thus one gets the best of two worlds: An honest descriptive license for protecting one’s business model + a normal permissive OSS license that ensures longevity and prevents lock-in.

[senorrib]

You’re seriously calling out a perfectly valid OSS for not being “in the spirit of OSS”, and pitching for licenses that are explicitly NOT OSS?!

AGPL couldn’t be more in the spirit of OSS. The entire free software movement started to defend the _users_ freedom, not individual companies’.

[VoxPelli]

AGPL is often used by startups to achieve the effect of “fair source” licenses while still being able to claim to be fully OSS.

AGPL is a poor “fair source” license and a controversial OSS license.

AGPL in “fair source” projects are always paired with Contributor License Agreements etc that ensures the company behind it owns all the rights to the project and can re-license it however they want without having to abide by AGPL themselves. Which is not in the spirit of OSS at all. And if the company goes out of business, then AGPL makes it really hard for anyone else to eventually pick up and continue on the “fair source” business model of the project.

Using a proper “fair source” license like the Business Source License or the Functional Source License will make for a better and more honest “fair source” phase of the project and both those licenses will resolve to non-controversial OSS licenses over time.

So:

- Is “fair source” in the spirit of “open source”? No

- Is AGPL an “open source” license? Yes

- Is AGPL often used to OSS-wash “fair source” projects? Yes

- Are all AGPL projects “fair source” projects? No, there exists proper OSS-projects with AGPL licenses

- Is AGPL in startup projects almost always paired with CLA:s that makes the startup play by different rules than everyone else? Yes

- Is it more in the spirit of “open source” or “fair source” to have the startup play by different rules than everyone else? In the spirit of “fair source”

- Is AGPL a good choice for “fair source” projects? No, it perpetuates the different rules between the startup and the community forever, even after the startup has ceased to exist, whereas proper “fair source” licenses convert to less extreme OSS licenses over time

Edit: The only company that I know that does an AGPL project in an “open source” spirit rather than a “fair source” spirit is Sourcehut: https://sourcehut.org/blog/2022-10-09-ip-assignment-or-lack-...

[exAspArk]

Our philosophy in general is to go to a more open license over time (vs the other direction). So we might consider other more permissive OSI-approved licenses.

Would you be able to share why AGPL license is a no-go for you? I'm genuinely curious about your use case. In simple words, it'd require a company to open source their BemiDB code only if they made modifications and were distributing it to other users (allowing modifications and using it internally without any restrictions)

[senorrib]

Please, don’t. AGPL is great and you’re fine using it.

[VoxPelli]

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.

[VoxPelli]

Opened an issue to see if this could maybe be documented on the fair.io website: https://github.com/fairsource/fair.io/issues/58

[riiii]

Because you want to take their hard work, modify it and not share it back to the community?

I'm not crying that "it's not for you".

[VoxPelli]

Absolutely not.

I want to keep the legalese in my setups at a manageable level, avoid needless lock-ins (AGPL is one of the least compatible licenses out there, code from an AGPL project can only ever be used in another AGPL project) and have it be clear when I contribute to a proprietary project in disguise (which most startup AGPL projects are, thanks to CLA:s) and when I contribute to an actual OSS project