Well, if there are no modifications to share, then there is no contribution to the community to share. This seems in line with intention to me.
The OP paradedb blog states for example:
> Future-Proof: Thanks to the copyleft provision, cloud vendors cannot easily resell our project without our consent. This gives us confidence in our ability to monetize without fear of predatory competition.
IANAL but my understanding of reading the various legal analyses of AGPL (which I've read several) is this part is not true: cloud vendors absolutely could resell their project without their consent, provided those cloud vendors don't modify the code. From an end user perspective and for an OSI OSS advocate those attributes are likely in your best short-term interest: they promote competition. But in the long-term, if the company launching an AGPL product believes it protects them from this, they're going to eventually find out what Mongo did: that it doesn't. And the result of that is that they'll either need to accept that there will be cloud vendors competing with them on the IP they created or relicense. Commercial interests/shareholders being as they are and many of these companies being VC-backed startups, the latter is frankly a more likely scenario.
The AGPL information page clearly states:
"if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there."
I'm not the sharpest tool, but I interpret that as all about the code. The license is not a tool I can use to prevent competition.
I've led several product management teams in my career and many engineers, executives, and customers I've talked to have this impression that if they put some bit of software under AGPL, then its nature is such that it's super viral: that potentially the entire product would necessitate becoming AGPL if the AGPL code is used in any fashion in the product. This has been primarily perpetuated from Google's statement on it: https://opensource.google/documentation/reference/using/agpl... and engineers that now there's a lot of lore around AGPL generally causing so much fear in any of big-tech company potentially needing to open source their entire service that it's treated as "companies wouldn't dare include our AGPL software in a competitive offering because then they'd have to open source their entire hosting stack, and nobody is going to be willing to do that."
My understanding that I heard through the grapevine is that this fear was what MongoDB was relying on for so many years and they found out that one of the big tech companies was about to offer a competitive MongoDB-as-a-service, which caused them to make their shift away from AGPL. Other (mostly database) OSS vendors caught wind of it as well through their networks, and that's why various OSS database products didn't go to AGPL but instead to proprietary licenses.
It then becomes a game of can you design your software in such a way that it will never be possible for cloud vendors to host it without modification, for example by keeping some required features closed-source (say a control plane, etc.).
For now, we feel this is good-enough protection and we hope that by doing our work right, we can give as much as possible to the community while still keeping guarded just enough to prevent cloud vendors from eating our lunch.