MongoDB has decided to change the licensing of MongoDB Community Server, seemingly to prevent businesses from monetizing on their product without giving anything back: https://www.mongodb.com/press/mongodb-issues-new-server-side-public-license-for-mongodb-community-server

Q1) Does this new license have a chance of being OSI approved? I'm thinking about this part of the OSI Open Source Definition in particular:

9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

It seems as if this might in some cases be in conflict with this part of SSPL:

13. Offering the Program as a Service.

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, 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.

“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.*

Q2) What will the consequences be if SSPL is not OSI approved?

1 Answer 1


(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.)

  • 5
    As a member of license-review, thank you for your truly comprehensive discussion of our debate. Oct 23, 2018 at 16:28
  • 1
    +1 Thanks for your post here--it is excellent. I am the GM at the OSI and wonder if you would be interested in providing such summaries on a regular basis? We would be happy to compensate you for your time. Can you contact me at masson(a)opensource.org if interested? - Patrick Masson
    – massonpj
    Nov 13, 2018 at 13:52
  • Hi @massonpj I sent you a mail about mailing list summaries a couple of days ago. If that somehow got lost you can also reach me at lukasatkinson.de or DM me on Twitter, see your recent follows :)
    – amon
    Nov 26, 2018 at 11:56
  • 2
    It should be noted that they replaced SSPLv1 with SSPLv2, after clarifying a number of terms. OSI decided that this was a whole new license and reset the clock on the approval process. So we probably won't hear about it for another couple of weeks or so at the earliest.
    – Kevin
    Jan 2, 2019 at 4:00
  • 2
    @Kevin it should be noted that they did only submit SSPLv2 to the OSI. All new releases of MongoDB are still SSPLv1.
    – Josef
    Jan 16, 2019 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.