Open Source and the SSPL
Two weeks ago I submitted the second version of the Server Side Public License (SSPL) to the OSI for review. The revision was based on feedback from the OSI license-review mailing list, which highlighted areas in the first version that would benefit from clarification. We think open source is important, which is why we chose to remain open source with the SSPL, as opposed to going proprietary or source-available. I am hopeful that the SSPL will also be declared an OSI-approved license, because the business conditions that prompted MongoDB to issue the SSPL are not unique to us and I believe the SSPL can lead to a new era of open source investment.
Open source software is better for its users than proprietary software for several reasons. The open source approach leads to more robust and secure software, because more people are able to look for and fix bugs. It’s much less risky for a business to commit to using open source projects as key components, because it can’t be stranded the same way it could be if the maker of proprietary software it relied on closed up shop. Building applications on open source projects and investing expertise into them means that no matter what, you can still fix bugs, add features, and fork those projects if necessary. The same remedies are available to anyone if a company stewarding an open source project becomes “evil”, or if for any reason it just won’t address their concerns about bugs or missing features.
The OSI opened the door for open source software in the mainstream with pragmatic, business-case advocacy and by introducing a standard, accepted definition of open source. That standard — the Open Source Definition (OSD) — isn’t just well-intentioned, it’s also well-crafted. Its ten criteria are carefully composed to preserve the freedom of those using open source software, to encourage the maximum amount of evolutionary benefit to software that comes from modification and experimentation, and to do both while ensuring that open source appeals to commercial endeavors as much as possible. As they write in an annotation of OSD criteria 6, No Discrimination Against Fields of Endeavor:
The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.
Which brings me back to the SSPL, which was written to address the new landscape where large cloud providers are positioned to capture most of the value created by open source projects, without contributing anything back. As I wrote when I announced the SSPL v1, it should be a time of incredible opportunity for open source, but if we continue to see project after project co-opted into cloud vendor ecosystems, it will not be a sound strategy to invest money into building open source projects, and many projects that would otherwise be open will instead be closed.
So that’s the intention of the Server Side Public License. For pragmatic reasons, MongoDB transitioned to use of SSPL v1 at the same time as we submitted the license to the OSI for approval, but the feedback that has come out of the process has made the SSPL a better license, and if version 2 is approved by OSI, we plan to apply it to the next release of MongoDB.