4 ms·

> The SSPL allows free and unrestricted use and modification, with the simple requirement that if you provide the product as a service to others, you must also

> The SSPL allows free and unrestricted use and modification, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL. That doesn't sound like something incompatible with Open Source Initiative standards for "open source". And it sounds like something existing OSI-approved licenses could do? And yet, SSPL is not OSI-approved, and they did not choose an existing OSI-approved license, instead the SSPL which they say "embodies the principles of open source", but isn't actually an open source license by accepted standards. So... why? What's going on? What is this really about? The press release of course doesn't answer the question "why not use an actual OSI-approved license"? What they describe seems pretty similar to AGPL, which is a pretty inconvenient license for use in commercial products, but is OSI approved. What does SSPL do that AGPL doesn't, and what about it makes OSI approval challenging?

erezsh 6y ago
I can answer that. The OSI doesn't approve any license that "discriminates on fields of endeavor", which means you are not allowed to prevent cloud providers from competing with you with your own product. Premium sponsors of the OSI include AWS, Google and Microsoft.
- jrochkind1 6y ago
  Thanks. What about the SSPL is considered discriminating against a field of endeavor? The AGPL is OSI-approved, and as I understand it also has a requirement "that if you provide the product as a service to others, you must also publicly release any modifications". (Possibly not "as well as the source code of your management layers", but that addition doesn't seem to post any additional problems related to "restrictions of fields of endeavor", I could see a future AGPL adding it, it seems somewhat the spirit of the AGPL). What are the parts of SSPL that differ from AGPL in a way that OSI woudln't aprpove? (The requirement about 'fields of endeavor' can be debated and is one of the currently more debated ones in OSI, but i my memory it goes way back in time to the early days of open source, I think you can probably find Stallman arguing for it before OSI even existed, I don't think it's there for some kind of nefarious reasons inserted by OSI sponsors. But certainly one can disagree with it.) (Here's Stallman against fields of endeavor restrictions from 2013, definitely not pre-dating OSI, but I think this does go way back, and I don't think anyone thinks Stallman's opinions are bought by corporate sponsors, and Stallman is obviously quite influential in ideas about what open source is. https://web.archive.org/web/20130509151342/https://www.gnu.org/philosophy/programs-must-not-limit-freedom-to-run.html https://web.archive.org/web/20130509151342/https://www.gnu.o...)
  - andreareina 6y ago
    Probably the clause that calls out offering ES as a service.
  - erezsh 6y ago
    The AGPL is easy to circumvent. MongoDB already answered all these questions when they created the SSPL in the first place: https://www.mongodb.com/licensing/server-side-public-license/faq https://www.mongodb.com/licensing/server-side-public-license... (iirc they also wrote a lengthy blog post about it)

erezsh 6y ago

I can answer that. The OSI doesn't approve any license that "discriminates on fields of endeavor", which means you are not allowed to prevent cloud providers from competing with you with your own product. Premium sponsors of the OSI include AWS, Google and Microsoft.

jrochkind1 6y ago
Thanks. What about the SSPL is considered discriminating against a field of endeavor? The AGPL is OSI-approved, and as I understand it also has a requirement "that if you provide the product as a service to others, you must also publicly release any modifications". (Possibly not "as well as the source code of your management layers", but that addition doesn't seem to post any additional problems related to "restrictions of fields of endeavor", I could see a future AGPL adding it, it seems somewhat the spirit of the AGPL). What are the parts of SSPL that differ from AGPL in a way that OSI woudln't aprpove? (The requirement about 'fields of endeavor' can be debated and is one of the currently more debated ones in OSI, but i my memory it goes way back in time to the early days of open source, I think you can probably find Stallman arguing for it before OSI even existed, I don't think it's there for some kind of nefarious reasons inserted by OSI sponsors. But certainly one can disagree with it.) (Here's Stallman against fields of endeavor restrictions from 2013, definitely not pre-dating OSI, but I think this does go way back, and I don't think anyone thinks Stallman's opinions are bought by corporate sponsors, and Stallman is obviously quite influential in ideas about what open source is. https://web.archive.org/web/20130509151342/https://www.gnu.org/philosophy/programs-must-not-limit-freedom-to-run.html https://web.archive.org/web/20130509151342/https://www.gnu.o...)
- andreareina 6y ago
  Probably the clause that calls out offering ES as a service.
- erezsh 6y ago
  The AGPL is easy to circumvent. MongoDB already answered all these questions when they created the SSPL in the first place: https://www.mongodb.com/licensing/server-side-public-license/faq https://www.mongodb.com/licensing/server-side-public-license... (iirc they also wrote a lengthy blog post about it)