TL;DR overview
- The Server Side Public License (SSPL) was created by MongoDB to address the perceived free-riding by cloud providers who offer open source software as a managed service without contributing back.
- SSPL requires that anyone offering the licensed software as a service must release the complete source code of their entire service stack under the same license—a provision most organizations cannot accept.
- The Open Source Initiative has not approved SSPL as an open source license, and major Linux distributions do not include SSPL-licensed software in their repositories.
- Organizations evaluating SSPL-licensed dependencies should assess the license obligations carefully and consider the compliance implications for their deployment model.
When the Server Side Public License (SSPL) was submitted to the Open Source Initiative (OSI), many people criticized it, and the license was eventually withdrawn. A key cause of the criticism was that it was drafted by a for-profit company (MongoDB). I, and others, pushed back—arguing that the nature of the company should be mostly irrelevant to the evaluation of the license.
Now, in the wake of SSPL’s adoption by Elastic, I realize I was partially wrong. In this post, I’ll cover why many aspects of the “living license” outside the plain text, including company engagement, should be considered by OSI, and give some recommendations that I hope will be useful to both OSI and future license authors.
OSI’s standards—in writing and in practice
You won’t find “who wrote the license” anywhere in the Open Source Definition. When the Open Source Initiative evaluates a license, the license should, in theory, stand on its own. If it is good, it gets approved; if not, it doesn’t. The OSI also has a long history with important licenses sponsored by large for-profits, including Netscape, Sun, IBM, and even Microsoft. And the current license submission process (which I significantly revised while I was on the OSI Board of Directors) does not ask license submitters about their corporate form or governance.
Despite these rules and history, when SSPL was originally submitted to the OSI in 2018, there were several important concerns raised. But the loudest critique (or at least the one I found the most frustrating at the time) was a claim that, regardless of the text, MongoDB should be distrusted as a license steward.
I’ve now realized that my frustration at this was subtly, but importantly, wrong. It’s still true that “was this written by a for-profit company?” is a bad test, and OSI should rarely, if ever, consider this factor. But as I wrote about in my last post, a written license (especially one that seeks to push the boundaries of what we do with licenses) is part of something broader, analogous to a movement or product launch. Since the license is, in this sense, a “living document,” I was wrong to say that OSI should only focus on the text. Instead, I now believe that, especially for new or innovative licenses, OSI should (carefully!) consider factors outside the text. Here’s how that could have applied to SSPL.
Non-license factors OSI could and should have considered
So what should OSI have thought about when SSPL was submitted? If we take the OSI’s proper focus as the living license ecosystem, not just the static license text, here are a few things we can learn. In the interests of brevity, I won’t address every topic from my last post (on “writing a successful license”), but here are a few that particularly jump out:
- Dual-licensing’s warped incentives for license stewards: A good license steward has strong incentives to clarify and enhance the license over time, through investments in things like education, training, etc. In contrast, a license steward who plans to use a license as part of a dual-licensing scheme has every incentive to make the license worse, by having sales teams who create fear about their own license, and having a disincentive to create educational material that improves the understanding of the license over time.
There are many AGPL projects where you literally can't pay someone money to avoid the AGPL. There are zero SSPL projects in the same position. — Matthew Garrett (@mjg59) January 28, 2021 So it could be appropriate for OSI to inquire about dual-licensing plans, and reject a steward who has no plans to single-license under the proposed license. - Developer evangelism: If the purpose of an innovative license is to make a particular change in the world, people have to use it. And that means the license author has to do work to reach out to potential users! OSI could have asked MongoDB about their plans to encourage developer adoption, and the answers might have been revealing. (For example, outreach exclusively to other AWS competitors using a dual-licensing model might have said one thing; good-faith outreach to the FSF or other community-backed SaaS projects, like Mediawiki, might have said another.)
- Iteration and improvement: When the Cryptographic Autonomy License was first submitted to the OSI, it was explicitly as a beta, with clear expectations that OSI’s input would be considered before the license reached 1.0. This demonstrated a good-faith intent to iterate the license in a manner consistent with the goals and purpose of the Open Source Initiative. In contrast, the SSPL was submitted as “1.0” and, to the best of my knowledge, neither MongoDB nor anyone else has adopted the subsequent versions of the SSPL.
- Lawyer education: How seriously you take lawyer education is a good signal of how seriously you take your license, since lawyers are a key audience for use and deployment of the license. If lawyers understand the license, developers and organizations will be able to use it in the way you intend; if they don’t understand it, the license will be shrouded in uncertainty and doubt—or worse, it just won’t be used at all. It’s hard to do this before a license is finalized, but certainly not impossible.
Doing it better next time
At the end of the day, a standardized license text cannot prevent a malicious copyright holder from forking a project into a proprietary license. This is true regardless of the scope of copyleft (as long as there is a CLA in place), and indeed happens all the time with non-copyleft permissive licenses like Apache! OSI also can’t see into the future, or read into the hearts and minds of a corporation. These facts make it very hard to say “OSI should not approve licenses that support dual-licensing."
So instead of trying to divine what lies inside the secret heart of a company, or enforcing an unwritten rule that only the FSF can expand the scope of copyleft, what reasonably objective standards could OSI fairly use to assess the potential future stewardship of a strong copyleft license? I’ll suggest the following standards:
- Pre-OSI public discussion and iteration: I’ve previously proposed that, as a matter of good drafting, OSI should require that the author solicit public feedback on a license for some time before submitting it to OSI. I still think this would be good for drafting quality, and I now also think it would also be good for assessing how seriously committed a license author is to the hard work that goes with a good-faith strong copyleft license—including education, network-building, and drafting.
- Adoption from non-author projects: Imagine if a license’s submission contained the phrase “We, project X, support the expressed purpose of this new license, and would strongly consider switching our project to it if OSI approves it.” The hard work of convincing another existing project to make a statement like that is a good sign that the steward intends to be a steward and not just a dual-license troll. (It’s possible that, as a practical matter, this would be the death knell for for-profit-sponsored licenses, since few communities would be excited to place their future in the hands of a for-profit. But by asking it in this way, the question is asked of projects that have their own code and reputation on the line, instead of asking OSI to guess whether it will be adopted or not.)
- Evaluating other governance components: Simon Phipps aptly calls the “give lots of rights early, and then remove rights later” model the “rights ratchet.” In a complementary Twitter thread Tobie Langel noted that for the rights ratchet to work, there must be (among other things) a weak community and centralized trademark control. It’s possible that, where there is a plausible case that the license is a bad-faith attempt to execute a rights ratchet on a particular project or group of projects, OSI could evaluate the overall state of those projects and attempt to understand what other structures have been put in place to reduce the risk. For example, if a project has a strong community of contributors from other companies, or has trademark policies in place that would protect the existing community’s ability to fork, this might reduce concerns about whether a shift to an innovative license is legitimately intended to increase openness.
Some of these tests would be easy for OSI to check for (in fact, in some ways easier than existing unwritten rules around drafting quality!), while the last would be a lot of work. At the same time, it’s also something that a good-faith license submitter could consider beforehand—and I suspect would eliminate a lot of bad-faith argument on all sides.
SSPL version 1, as submitted, would likely still have failed these tests. In particular, the controversial language it used that could have extended even to an entire operating system would likely not have made it through any genuine community-based pre-OSI review process. And to date the only projects adopting it have also been via companies executing a “rights ratchet,” rather than any non-corporate communities.
The bottom line: licenses are living documents, and we should evaluate them that way
I was wrong that the open source license review process can’t look at the author, because the success or abuse of a license is predicated on a broad set of factors outside of the license text. At the same time, by looking at these broad factors thoughtfully, we can create better tests than the ones we’ve got—and hopefully encourage future license authors to respect them!