4 ms·

I've seen posts around AGPL and how it protects OSS vendors from their cloud cousins ever launching a competitive service and I'd just point people to https://

I've seen posts around AGPL and how it protects OSS vendors from their cloud cousins ever launching a competitive service and I'd just point people to https://katedowninglaw.com/2019/09/08/the-great-open-source-shake-up/ https://katedowninglaw.com/2019/09/08/the-great-open-source-... as a really great read from a lawyer on the various factors and motivations, and which in particular touches on AGPLs lack of ability to protect what many of these companies are worried about most. Specifically: > That understanding was the genesis for the GNU Affero General Public License 3 (AGPL 3) published in 2007: it was meant to solve for this exact problem by adding language to the GPL 3 which required companies to provide source code for software that users interacted with via a computer network if the software was modified AGPL 3 code (or a derivative work of such modified AGPL 3 code). But even the AGPL’s obligations can be avoided by simply not modifying the AGPL 3 code, which there is often no reason to do, or by building layers between the AGPL 3 code and proprietary code. That’s why a lot of these middleware companies didn’t choose to relicense to AGPL 3 and why MongoDB, who was already using AGPL 3, chose to revise the AGPL 3 to expand the circumstances under which services running on AGPL’ed code must open source the previously proprietary parts of those services.

zelphirkalt 2y ago
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.
- eskibars 2y ago
  My statement here is less that the AGPL doesn't set out to do what it says on the tin (it does) but more that many people launching SaaS companies don't understand what the tin says. Many at least consider AGPL because they believe it "protects" them in some fashion from other cloud providers monetizing their IP. 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.
  - TheChaplain 2y ago
    I suspect that is yet another case of "TL;DR", people just grab on to something they heard about or read the first sentence of? 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.
    - eskibars 2y ago
      It's definitely a case of people not reading, but honestly: who does read the full terms of a license? Most people just don't know which have requirements to attribute the work or redistribute license files or which provide the company they work for with certain advantages/disadvantages. They just "heard about" MIT or Apache 2 or whatever are safe to use and there are some license types that are unsafe to use. 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-policy 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.
  - philippemnoel 2y ago
hardwaresofton 2y ago
You’re absolutely right. I think what will really set this in people’s minds is when a company forks and maintains an AGPL clone. AGPL only works right now because companies are supposedly scared of it (and have blanket policies) but it does not do what some often think it does, in actuality.

zelphirkalt 2y ago

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.

eskibars 2y ago
My statement here is less that the AGPL doesn't set out to do what it says on the tin (it does) but more that many people launching SaaS companies don't understand what the tin says. Many at least consider AGPL because they believe it "protects" them in some fashion from other cloud providers monetizing their IP. 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.
- TheChaplain 2y ago
  I suspect that is yet another case of "TL;DR", people just grab on to something they heard about or read the first sentence of? 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.
  - eskibars 2y ago
    It's definitely a case of people not reading, but honestly: who does read the full terms of a license? Most people just don't know which have requirements to attribute the work or redistribute license files or which provide the company they work for with certain advantages/disadvantages. They just "heard about" MIT or Apache 2 or whatever are safe to use and there are some license types that are unsafe to use. 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-policy 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.
- philippemnoel 2y ago

hardwaresofton 2y ago

You’re absolutely right. I think what will really set this in people’s minds is when a company forks and maintains an AGPL clone. AGPL only works right now because companies are supposedly scared of it (and have blanket policies) but it does not do what some often think it does, in actuality.