4 ms·

The AGPL allows Amazon to offer a competing service. It just needs to be open-source. But the cloud vendor's efforts aren't typically with the software itself

by mfreed 6y ago

The AGPL allows Amazon to offer a competing service. It just needs to be open-source. But the cloud vendor's efforts aren't typically with the software itself -- they often run the open-source version unmodified -- but rather with the operations and systems around the software. Mongo's SSPL was trying to block this case by forcing folks to open-source all their surrounding infra (which likely AWS would never do), but at least for now, the SSPL was not accepted as an Open-Source License by the OSI. Also, I'd argue that efforts like the SSPL are actually trying to "backdoor" the goal of "cloud protection licenses" in the first place. They are trying to bake-in a poison pill that the cloud vendors won't want to do, as opposed to having a clause that just directly speaks to the stated goal.

JoshTriplett 6y ago
The SSPL has at least some hope of potentially being a viable FOSS license; the disagreements around that license were around details and implementation, not necessarily critical unfixable issues. Something like the Timescale license fundamentally can never be a FOSS license.
- _msw_ 6y ago
  I don't agree, Josh. Certainly not v1 (which, AFAIK, is the only version in use). I doubt v2 could gain broad support either.
  - JoshTriplett 6y ago
    I'm not suggesting it could trivially become an OSI-approved license. Rather, I think it's much closer in spirit than something like the Timescale or "Commons Clause" or similar licenses, that blatantly discriminate against fields of endeavor (OSD 6) by design. The SSPL, by contrast, is a copyleft license that has a much stronger copyleft than the AGPL. It may potentially be overstepping the intent of what the OSD means to allow, but it doesn't on its face violate the spirit of any of those clauses, not any more so than the AGPL does. I think it'd be possible to modify the SSPL into a version that could meet that agreement while maintaining the intent of the license.
    - _msw_ 6y ago
      To me it violates the spirit of OSD9.
      - JoshTriplett 6y ago
        Ah, got it. I personally feel like the spirit of OSD9 is primarily about not affecting unrelated programs. I think it'd be reasonable to affect related programs. I think the current version of SSPL oversteps wildly in that regard, but I feel like it could be pared back to something that would be consistent with what I'd consider to be the spirit of OSD9 (and the rest of the OSD), while still doing what it seems like the SSPL is trying to do. In doing so, I'd focus on "such that a user could run an instance of the service using the Service Source Code you make available", and drop all the specific service examples in favor of something like "any software you have made the Program depend on, such that the Program lacks some functionality compared to your service if that software is not present (even if you have made the Program support running without that functionality)". That would be broader than the comparable boundary of the AGPL, but much narrower than the current SSPL, insofar as it would only cover things the Program has been modified to depend on, rather than surrounding hosting infrastructure. In any case, I don't think it very likely that MongoDB would be willing to make such changes, but if they did, I think it'd be possible to arrive at a license that would pass the OSD.
yjftsjthsd-h 6y ago
> The AGPL allows Amazon to offer a competing service. It just needs to be open-source. Sure, but if the problem is "leeching off their software without paying for it", then being obligated to share their changes should fix the "leeching" bit. I mean, is Amazon leeching off Linux by shipping it on all their devices?
- mfreed 6y ago
  My own perspective is that companies should probably stop saying that "if only Amazon would contribute back the occasional patch, everything would be fine." If much of the future is cloud, then getting the hyper-scalars to contribute occasional patches doesn't solve the problem of competition. That's reflected in our post: Some may ask, “Why create a new license - why not just compete with public clouds by just providing the best product experience on a level playing field?” The problem is that the playing field is far from level. Today, the public cloud vendors (Amazon, Microsoft, Google) are trillion dollar corporations – the largest companies in the world – and have a myriad of advantages that arise from that size, including market position, pricing power, deep balance sheets, and (what many have even called) unfair business practices. They lock large customers into prepaid, discounted, multi-year enterprise-wide agreements, and give startups $100,000s of free credits. Now, non-profits like the Linux Foundation are not trying to solve for this same problem. But I think that the tech and innovation ecosystem would be much for the worst if everybody else is hamstrung when competing in the cloud, or else just have to go fully closed source and proprietary.
  - cycloptic 6y ago
    Can you honestly say this license is trying to solve for the same problem, rather than just carving a niche for your own business at the expense of other businesses, e.g. other startups who might be able to offer a better service contract to the public cloud vendors? Because it's hard for me to imagine it differently the way these are worded. This is my main problem with this type of licenses, none of them really seem to have any interest in actually getting the public cloud vendors to compete or buy services or contribute (financially or otherwise) to the upstream project. It just perpetuates the problem because now your company is the one doing it by telling customers they have to sign your agreement and can never buy from any other vendor. I'm sorry if this is an overly negative assessment but I just can't see it as much more than passing the buck when there is no attempt at reciprocity, through copyleft or through some other means. (As much as I had criticism of the SSPL, at least it tried to have this)

by mfreed 6y ago

JoshTriplett 6y ago

The SSPL has at least some hope of potentially being a viable FOSS license; the disagreements around that license were around details and implementation, not necessarily critical unfixable issues. Something like the Timescale license fundamentally can never be a FOSS license.

_msw_ 6y ago
I don't agree, Josh. Certainly not v1 (which, AFAIK, is the only version in use). I doubt v2 could gain broad support either.
- JoshTriplett 6y ago
  I'm not suggesting it could trivially become an OSI-approved license. Rather, I think it's much closer in spirit than something like the Timescale or "Commons Clause" or similar licenses, that blatantly discriminate against fields of endeavor (OSD 6) by design. The SSPL, by contrast, is a copyleft license that has a much stronger copyleft than the AGPL. It may potentially be overstepping the intent of what the OSD means to allow, but it doesn't on its face violate the spirit of any of those clauses, not any more so than the AGPL does. I think it'd be possible to modify the SSPL into a version that could meet that agreement while maintaining the intent of the license.
  - _msw_ 6y ago
    To me it violates the spirit of OSD9.
    - JoshTriplett 6y ago
      Ah, got it. I personally feel like the spirit of OSD9 is primarily about not affecting unrelated programs. I think it'd be reasonable to affect related programs. I think the current version of SSPL oversteps wildly in that regard, but I feel like it could be pared back to something that would be consistent with what I'd consider to be the spirit of OSD9 (and the rest of the OSD), while still doing what it seems like the SSPL is trying to do. In doing so, I'd focus on "such that a user could run an instance of the service using the Service Source Code you make available", and drop all the specific service examples in favor of something like "any software you have made the Program depend on, such that the Program lacks some functionality compared to your service if that software is not present (even if you have made the Program support running without that functionality)". That would be broader than the comparable boundary of the AGPL, but much narrower than the current SSPL, insofar as it would only cover things the Program has been modified to depend on, rather than surrounding hosting infrastructure. In any case, I don't think it very likely that MongoDB would be willing to make such changes, but if they did, I think it'd be possible to arrive at a license that would pass the OSD.

yjftsjthsd-h 6y ago

> The AGPL allows Amazon to offer a competing service. It just needs to be open-source. Sure, but if the problem is "leeching off their software without paying for it", then being obligated to share their changes should fix the "leeching" bit. I mean, is Amazon leeching off Linux by shipping it on all their devices?

mfreed 6y ago
My own perspective is that companies should probably stop saying that "if only Amazon would contribute back the occasional patch, everything would be fine." If much of the future is cloud, then getting the hyper-scalars to contribute occasional patches doesn't solve the problem of competition. That's reflected in our post: Some may ask, “Why create a new license - why not just compete with public clouds by just providing the best product experience on a level playing field?” The problem is that the playing field is far from level. Today, the public cloud vendors (Amazon, Microsoft, Google) are trillion dollar corporations – the largest companies in the world – and have a myriad of advantages that arise from that size, including market position, pricing power, deep balance sheets, and (what many have even called) unfair business practices. They lock large customers into prepaid, discounted, multi-year enterprise-wide agreements, and give startups $100,000s of free credits. Now, non-profits like the Linux Foundation are not trying to solve for this same problem. But I think that the tech and innovation ecosystem would be much for the worst if everybody else is hamstrung when competing in the cloud, or else just have to go fully closed source and proprietary.
- cycloptic 6y ago
  Can you honestly say this license is trying to solve for the same problem, rather than just carving a niche for your own business at the expense of other businesses, e.g. other startups who might be able to offer a better service contract to the public cloud vendors? Because it's hard for me to imagine it differently the way these are worded. This is my main problem with this type of licenses, none of them really seem to have any interest in actually getting the public cloud vendors to compete or buy services or contribute (financially or otherwise) to the upstream project. It just perpetuates the problem because now your company is the one doing it by telling customers they have to sign your agreement and can never buy from any other vendor. I'm sorry if this is an overly negative assessment but I just can't see it as much more than passing the buck when there is no attempt at reciprocity, through copyleft or through some other means. (As much as I had criticism of the SSPL, at least it tried to have this)