El McQuade

Software Engineering

Why is the SSPL not an open-source license?

Disclaimer: I’m an OSS dabbler, and definitely not a lawyer.

Prerequisites: Some familiarity with the GPL and AGPL licenses.

The Server Side Public License (SSPL) was created by the MongoDB team in October 2018, as an alternative to the AGPL. The AGPL was perceived to not offer enough protection against SaaS providers profiting from their work without contributing back to the original project. Effectively, the software could be used in a product, but wrapped in a way that the source for any additional features did not need to be redistributed. The main purpose of the SSPL was to add protections against this (see FAQ).

Originally, this was intended to be a license that MongoDB could use and still be considered open-source software, which has many benefits, e.g. increased perceived attractiveness/community involvement. Like many terms in software, ‘open-source’ is a term that has a formal definition yet is often given some leeway in less formal contexts (see also AI, Agile, or anything to do with testing). The definition was coined and an organisation was formed to maintain it – the Open Source Initiative. The definition is considered ‘de facto’ by a substantial set of international entities. It might seem antithetical to the distributed, fork-happy OSS community to have a central body for this, but it has some concrete benefits – it offers consistent expectations for any user of any open-source application. Without that, it adds friction to the adoption of OSS.

The SSPL was submitted to, but never approved by the OSI.

My initial thoughts were that SSPL was isomorphic to GPL, an OSI-approved license, and that as the SSPL was not approved, it might have been due to influence from big cloud providers in the approval process. Looking back at the original discussions, it’s clear that the reasons for non-approval were more nuanced, and, importantly – almost certainly impartial. The OSI reported a revenue of about $200k from a variety of sources. For the amount of work involved in reviewing licenses and other activities, this number is hardly a large enough sum to indicate any corporate lobbying that wouldn’t be immediately obvious under scrutiny.

So, why was SSPL different enough in spirit to GPL that it wasn’t approved? A snippet from the discussion gives us a clue:

‘…In turn, Mitchell disagrees that the OSD would be so clear. “If OSD 6 banned any kind of [discrimination], GPLv2 discriminated against proprietary software makers.” “There should be a new, crips [sic], clear rule on open source copyleft scope. OSD 9 isn’t it.” Perens responds to individual points in Mitchell’s message. “Free Software and Open Source drew a line in the sand, gave it a brand, and have defended that line. There will always be attempts to push it elsewhere, and they will always be resisted.”’

What is OSD6? From the official definition:

“The license must not restrict anyone from making use of the program in a specific field of endeavor”

First, a recap on GPL. Let’s take Microsoft Visual Studio (VS), and its C++ compiler (MSVC), as an example. Visual Studio supports many other languages, and incorporates debugging, profiling and many other tools. Let’s say MS wanted to integrate a superfast parser that had been developed by a 3rd party, but was under a GPL license. As an intrinsic component, MS would likely have to open-source MSVC under that GPL license. They wouldn’t however, have to open-source Visual Studio under that license, as MSVC is not an intrinsic component of Visual Studio.

Now, let’s look at SSPL. A diff with the AGPL is available here. Clause 13 had been singled out as where the issues lie. On first glance, it’s difficult to see how:

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

However, below you will see:

‘“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.’

‘Service Source Code’ is not as narrow in scope as it first sounds To reiterate, it includes:

  • Management software
  • User interfaces
  • APIs
  • Backup software
  • Storage software
  • Hosting software

Effectively, this captures a massive chunk of the infrastructure stack – not only of the ‘service’, but possibly other unrelated services. Instead of needing to relicense a single subsystem when taking the dependency, it means effectively relicensing the entire platform. So, a rough comparison with the GPL example from above – it would be like needing to re-license Visual Studio, and all its tools. And, as the specific things listed in the ‘service source code’ scope are very much targeted at a typical SaaS provider, it effectively prohibits the use of the software in that specific field of business.

From what I gather, the SSPL is the closest we have to protecting community-driven software from exploitation by existing or hypothetical SaaS providers. I agree that it is more onerous than the GPL, and should *not* be considered open-source. The AGPL offers some protection, in that changes to the core application have to be contributed back to the community. But, anything built around that doesn’t, and trying to license for that will almost certainly cross the “line in the sand” into non-open-source territory.

Thanks for reading. This was inspired by a long afternoon on twitter in a thread about the SSPL. Many thanks to those that answered my questions and patiently corrected my bad assumptions. Please get in touch with any corrections.

Updated 8-Dec-2020: 1: Added clarification 2: Rewrote conclusion (previously suggested we need to continue trying for an open-source license); 3: Corrections & clarifications in the introduction wrt. license basis and AGPL