(Update 2019-03-09: MongoDB retracted the license from OSI review.)
Does the SSPL have a chance of getting OSI-approved? Yes, of course there's a chance, though currently it looks like a rather slim one.
The SSPL is significantly stricter than the AGPL. The SSPL puts additional conditions on
[…] offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
This is on the border of what a copyright-based license can accomplish because it effectively treats Services based on the Program as a derived work of the Program. This does not seem to be inherently in conflict with the OSD. As for OSI-approval, it is up to the OSI as to whether they concur with the SSPL's interpretation of Services as derived works.
If, however, the “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software” for a Service based on the Program cannot be covered by a copyright license of the Program, then this would indeed look like a violation of the OSD as it would force “unrelated” software to be open-sourced.
My personal feeling is that the SSPL is so close to the line of what is legally possible for a copyright-based license that it will keep lawyers busy for a long time, and using the SSPL would be unwise until there is more clarity. An OSI-approval would bring some clarity, but would only be the OSI's opinion, not reliable legal advice.
If there is ever clarity in this matter, this would also have effects on GPL interpretation. The GPL is often interpreted so that other software that communicates with the GPL-covered software “at arms length” would not be covered. This would e.g. allow us to wrap a GPL-covered software with a proprietary interface. But if the SSPL is an open source license, this would suggest that such proprietary wrappers would also be subject to the GPL. This hinges on what exactly a creative work of computer software is. Is it a complete software system, or is it only individual libraries or files within a software system. Current open source practice points to the latter, but a widespread acceptance of the SSPL would suggest the former.
Primarily because of this huge shift of interpretation (i.e. under common copyright law interpretation, the SSPL asserts more control than it actually has) I think that it is unlikely that this license will be OSI-approved.
If OSI does not approve the SSPL, nothing happens. OSI approval doesn't confer any special status to the license. But without OSI approval, many people will be hesitant to use SSPL-covered software.
License compatibility is already clear: as a copyleft license, the SSPL is incompatible with other copyleft licenses such as GPL or AGPL, but like the GPL or AGPL is one-way compatible with permissive licenses such as MIT, BSD, or Apache 2.0.
Summary of the OSI's license-review thread on the SSPL:
- Bruce Perens notices that the SSPL might infringe the FSF's copyright on the AGPL, and raises similar concerns to the scope of derived works that I have discussed above.
- Bradley M. Kuhn opposes the SSPL as “a campaign by a well-resourced for-profit company to reframe what copyleft is.” They also notice that drafting an OSD-compliant copyleft license is a delicate matter – but no such care seems to have been taken by MongoDB here, and suggest that MongoDB should withdraw the SSPL from the license-review process. Many posters agree with that suggestion.
- VanL suggests that the SSPL may be unenforcable in the U.S. because it could be a misuse of copyright.
- Heather Meeker (who drafted the SSPL) responds that copyright misuse is not an issue here, in particular that the precedent cited by VanL hinged on non-compete clauses that are irrelevant here. “Sharing of source code is just not an anticompetitive practice.” They also note that in the U.S. challenges against the GPL on the basis of anti-trust laws have failed.
- I disagree here because while the GPL and SSPL go in the same direction, the SSPL goes much further. This is further elaborated by VanL in their response.
- Richard Fontana points out that discussions about possible copyright misuse are orthogonal to OSD compliance.
- Brendan Hickey thinks that SSPL is clearly incompatible with the OSD, and that the SSPL “appears so absurdly expansive that actually achieving compliance might be impossible in practice”. They also list a couple of scenarios where the license is unclear, e.g. “Use Docker to deploy an image that serves MongoDB” – would Docker then fall under the SSPL?
- Nigel T observes that the SSPL brings legal uncertainty to downstream users of a service because that service might be SSPL-covered.
- Florian Weimer observes that the SSPL seems misaligned with MongoDB's goals, but this is immaterial to OSD compliance. (This confuses me as well. If I pay Amazon for a hosted MongoDB instance, I'm paying them for the value of the instance and not for the value of any secret MongoDB tools they would have to release under the SSPL, if such tools even exist. Therefore, the SSPL would be unsuitable to dissuade Amazon from profiting from SSPL-covered code.)
- Stefano Zacchiroli notices a big difference between AGPL and SSPL: while the AGPL triggers source disclosure requirements on modification, the SSPL already triggers on mere use.
- Vadim Tkachenko sees the SSPL as anti-competitive, because any MongoDB competitor who offers a MongoDB service would have to use a pure-SSPL infrastructure stack. For example, you would not be able to use SSPL-covered software together with AGPL-covered tools. This would be an OSD 6 and OSD 9 violation.
- Bruce Perens profusely apologizes for phrasing OSD 9 “Must Not Restrict Other Software” in a way that only talks about other programs that are “distributed” along with the licensed software. The SSPL does not violate the letter of the OSD because it restricts tools that are not distributed together, but it clearly violates the OSD's intent.
Since to date no poster who is unaffiliated with MongoDB has stated that the license is perfectly OSD-compliant, but many posters have criticized either the provisions of the license or the manner in which MongoDB presented the license, OSI-approval of SSPLv1 seems quite unlikely (but it's only been a week so far.)
