This is a common misconception. Nothing in the text of the AGPL requires this whatsoever.
But it's a common enough misconception that my personal recommendation tends to be to just steer clear anyway, if you're planning to run a closed-source business. It's better to not get sued at all, than to get sued by someone who's wrong.
But for reference, the only text added to the AGPL in comparison to the GPL is section 13 here:
In other words, if you run an AGPL database and modify it, you need to provide your users with the source of your modified version.
Nothing remotely suggesting that the rest of your entire software stack becomes AGPL licensed. (In fact I often wonder how people are imagining that would even work. It would basically imply that you can't, for example, run AGPL software on a Windows server...)
I spent some time reading about static linking and dynamic linking. From the FAQ
> "Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination"
If I had to guess, if you installed each application in your stack separately, and they simply interacted with each other through API calls, you could consider them "System Libraries" and therefore would not dragged into the AGPL. Example, The OS itself, Node, Postgres, and any other 3rd party applications. As long as you are not distributing them, I think they would count as System Libraries.
> "To prevent unscrupulous distributors from trying to use the System Library exception as a loophole, the GPL says that libraries can only qualify as System Libraries as long as they're not distributed with the program itself. If you distribute the DLLs with the program, they won't be eligible for this exception anymore"
The System Library exception isn't even needed. The key word in what you've quoted is "linking". If you aren't linking, then you aren't creating a combined derivative work at all.
If true, this license does nothing to mitigate the risk that a user may get locked into contracts they don't like, or the ability to continue to use the software if the developer goes bankrupt or is bought by a competitor.
If you can't use the AGPL version now, you can't use it later either.
And I don't see how it prevents "Cloud Vendors" from using it, but not everybody else as well.
Even if the (CLA-owning) organization changes the license, the last version available under the AGPL will always be available under the AGPL.
> If you can't use the AGPL version now, you can't use it later either.
Right. But you can use it now and later.
> And I don't see how it prevents "Cloud Vendors" from using it, but not everybody else as well.
Cloud vendors can use it. What they can't do is fork it and start making private changes that they do not release for others to use. Forking it is fine, making incompatible changes is fine, but keeping those changes proprietary is not.
The AGPL defends against competition from a big cloud operator, but not in the way you're thinking. It does not prevent the cloud operator from using or even modifying the software. It does prevent that operator from creating a competitive fork that benefits from starting with the AGPL code but then diverges in a way such that customers will want to pay the cloud operator for their up to date fancy version instead of the original project. I mean, they still could try to get people to pay for that, but the original project will have access to all of their changes so the cloud operator won't have any advantages when selling support or a license with different terms.
> but the original project will have access to all of their changes so the cloud operator won't have any advantages when selling support or a license with different terms.
Those changes would be under some sort of AGPL and the original project cannot merge it back, while still maintaining their option of a commercial license.
So once the original project merge any of their competitor's changes/forks, their project becomes AGPL only, and lose the ability to charge for a commercial license as a monetization strategy.
So I guess what you are saying is that the business model is that cloud vendors will buy a license, but only if they they want to make changes to the code, but not release those changes.
So not just small changes, big changes that have a significant value-add, and not easily replicated. It assumes cloud vendors will want to start building a business on top of this critical dependency.
It doesn't sound like a great deal for the cloud vendor.
I assume we are really only talking about Amazon, Microsoft and Google, and the developer hopes to just get bought rather than messing around with licenses.
> So I guess what you are saying is that the business model is that cloud vendors will buy a license, but only if they they want to make changes to the code, but not release those changes.
That, or the cloud vendor does not buy a license and uses it anyway, with or without changes. And existing customers of the originator continue to be their customers, rather than switching to become customers of the cloud vendor instead.
> So not just small changes, big changes that have a significant value-add, and not easily replicated. It assumes cloud vendors will want to start building a business on top of this critical dependency.
It doesn't assume that, it defends against issues caused by that.
> It doesn't sound like a great deal for the cloud vendor.
Exactly! But that's the point.
> I assume we are really only talking about Amazon, Microsoft and Google, and the developer hopes to just get bought rather than messing around with licenses.
The canonical case is where the original author does want to sell licenses and/or support and/or development contracts to various random companies, most of them not giant cloud companies. They do not want to be acquired. Their customers are most likely also customers of some large cloud company, and the original author most of all does not want to compete with the cloud company. The author will want the software to work well in the context of a cloud offering, and will not want their version to work worse than the cloud company's own version. If a big cloud company comes up with a way to make the software work better when using their cloud, then the original author wants to incorporate that improvement, preferably alongside improvements made by or for the other big cloud companies.
But you are correct about the importance of selling something, whether it is a license or support or development services. As a sibling comment to yours mentions, that's where the CLA (contributor license agreement) stuff comes in, where in order to be able to sell a proprietary license, they need to own all the code. This is where it can get ugly. Not everyone wants to hand over ownership of changes they make, so that the originator can make money off of them. And nobody has to. The AGPL only forces people to make their changes available, not to give them away; it's up to the originator to make people want to get their changes upstream.
