> Note that if you self-host this, that you are bound by those code publication requirements of the AGPL 3.0 license that apply to your specific circumstance.

Dear everyone, please remember, the restrictions are on AGPL is about making changes and not upstreaming the changes. You can absolutely run it as a service, or as a networked part of your application.

For example, if you wanted to remove their branding or some message in an email or a link on a webpage from the source code, you could absolutely do that -- as long as you release the forked code under a similar license in the public sphere.

Businesses still won't touch AGPL (for now) and that's what they're going for to encourage enterprise signups (I find calling it "GPL-licensed" is a little misleading on the front page, but I get why they did it) -- but I think at some point that will probably end. I'm glad it's still going though, more chances for people to make money doing F/OSS (AGPL is free software).

I don't get what you're saying. Why would a self-hoster care about the code publication requirements of the AGPL? It's an OSS project, the end user doesn't care if the code has to be redistributed, they're not profiting from it remaining closed.

It's not uncommon for people to link their core product into their CRM (for billing and usage).

Which could in turn "infect" your core offering to now become AGPL (and now you're having to release your core product IP to the public).

Two services talking to each other doesn't mean that they have to use the same licence or that AGPL "infects" the other.

Incorrect. For example, the relevant paragraph from the Google doc linked elsethread:

> any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed.

What the OP is talking about is an aggregate, ie. two distinct pieces of software talking to each other over an interface, which is explicitly "non-viral", cf. AGPL v3 § 5.

That being said, the AGPL v3 is on the more arduous side of things, so it's easier to avoid them completely in a business context.

Sure, that seems like a reasonable interpretation to me.

However, I don’t have any specific recommendation against AGPL v3. Accounting is just one specific field where licensing virality could have particularly complex implications.

Just because someone wrote they in a google doc, doesn't mean that it is true.

It’s a risk most companies don’t want to chance.

I mean GitHub was literally built off of Git (GPL) and they had zero issues being acquired for $7.5billion.

Massive difference exist between GPLv2 (Git) vs AGPLv3 (Twenty).

You're comparing apples and oranges.

Google documents well why they forbid AGPL https://opensource.google/documentation/reference/using/agpl...

I don't think that's fair, Google is a monopoly with anticompetitive practices. Why is it a shocker that they would forbid AGPL? They want to have their fiefdoms while charging exorbitant rents. They can't compete fairly.

Also there are plenty of profitable software with AGPL licenses, some even get acquired by public companies [1].

[1] https://www.rapid7.com/about/press-releases/rapid7-acquires-...

At larger organizations, a significant amount of the custom code in CRM systems are proprietary business rules... e.g. pricing calculations, business rules regarding the fine details of internal and personnel operations, etc. It's not uncommon for them to contain information that is covered under NDA, which would be a non-starter for redistribution.