Just one last nuance I'll add to what the parent wrote.
It wasn't actually the intent of the AGPL to keep a cloud service from setting up a competitor to your on-prem software. Rather it was to address what some felt was a loophole in the GPL's treatment of copyleft. (Namely that operating software as a service isn't considered distribution in the eyes of the GPL and therefore a cloud provider could add some secret sauce to your open source software without contributing back to the commons.)
That said, as a practical matter it seems to be pretty effective because most cloud providers won't use AGPL software (and a lot of other companies won't either).
But, because it doesn't actually prevent a cloud provider from competing with you with your own software, there have been a few (non-open source according to the open source definition) licenses created that specifically bar this sort of use.
> But, because it doesn't actually prevent a cloud provider from competing with you with your own software, there have been a few (non-open source according to the open source definition) licenses created that specifically bar this sort of use.
Excellent note, and very accurate!
I can start a company that sells your AGPLv3 software tomorrow. I just have to comply with the terms & conditions. If I'm doing absolutely nothing but operating the software without change, I can satisfy the license by saying "git clone github.com/your/software", done.
Where things get murky is on the concept of linking/derivative works. If I operate a cloud service and make changes to your software to make it use my cloud systems efficiently, those changes have to be open-sourced under AGPLv3. Does that leak too much proprietary information about my systems? Very possibly. That might be enough to stop me. But if I keep going down that road, I end up risking a legal argument that our systems have become so tangled together that parts of my software fall under AGPLv3.
For most companies, this is simply not worth the risk. MongoDB took it one step further with the SSPL:
> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. [...] “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
This is basically the anti-AWS license: for AWS to run MongoDB proper, they'd need to expose source for huge amounts of their backplane. It's also not open source under almost anyone's definition.
>This is basically the anti-AWS license: for AWS to run MongoDB proper, they'd need to expose source for huge amounts of their backplane.
Not true. For AWS to run MongoDB proper, they could just negotiate with MongoDB to offer it as a managed service - as Tencent, Alibaba, SAP, IBM, Swisscom, OVH and 10+ others have.
> It's also not open source under almost anyone's definition.
Enter the OSI. While it not be "Open Source" (note the capitals) I don't think anybody has the right to legislate the use of "open source" with lower case letters. A nit, but an important one - the capitals force us to realize that it's not a word in Webster's Dictionary. It's a proper noun definiton put forth and pushed by one organization. I can certainly say "...oracle is lying..." but if I say "...Oracle is lying...", I expect the black cars to drive up to my house pretty quickly.
Just one last nuance I'll add to what the parent wrote.
It wasn't actually the intent of the AGPL to keep a cloud service from setting up a competitor to your on-prem software. Rather it was to address what some felt was a loophole in the GPL's treatment of copyleft. (Namely that operating software as a service isn't considered distribution in the eyes of the GPL and therefore a cloud provider could add some secret sauce to your open source software without contributing back to the commons.)
That said, as a practical matter it seems to be pretty effective because most cloud providers won't use AGPL software (and a lot of other companies won't either).
But, because it doesn't actually prevent a cloud provider from competing with you with your own software, there have been a few (non-open source according to the open source definition) licenses created that specifically bar this sort of use.
> But, because it doesn't actually prevent a cloud provider from competing with you with your own software, there have been a few (non-open source according to the open source definition) licenses created that specifically bar this sort of use.
Excellent note, and very accurate!
I can start a company that sells your AGPLv3 software tomorrow. I just have to comply with the terms & conditions. If I'm doing absolutely nothing but operating the software without change, I can satisfy the license by saying "git clone github.com/your/software", done.
Where things get murky is on the concept of linking/derivative works. If I operate a cloud service and make changes to your software to make it use my cloud systems efficiently, those changes have to be open-sourced under AGPLv3. Does that leak too much proprietary information about my systems? Very possibly. That might be enough to stop me. But if I keep going down that road, I end up risking a legal argument that our systems have become so tangled together that parts of my software fall under AGPLv3.
For most companies, this is simply not worth the risk. MongoDB took it one step further with the SSPL:
> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. [...] “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
This is basically the anti-AWS license: for AWS to run MongoDB proper, they'd need to expose source for huge amounts of their backplane. It's also not open source under almost anyone's definition.
>This is basically the anti-AWS license: for AWS to run MongoDB proper, they'd need to expose source for huge amounts of their backplane.
Not true. For AWS to run MongoDB proper, they could just negotiate with MongoDB to offer it as a managed service - as Tencent, Alibaba, SAP, IBM, Swisscom, OVH and 10+ others have.
> It's also not open source under almost anyone's definition.
Enter the OSI. While it not be "Open Source" (note the capitals) I don't think anybody has the right to legislate the use of "open source" with lower case letters. A nit, but an important one - the capitals force us to realize that it's not a word in Webster's Dictionary. It's a proper noun definiton put forth and pushed by one organization. I can certainly say "...oracle is lying..." but if I say "...Oracle is lying...", I expect the black cars to drive up to my house pretty quickly.
3 replies →