COSS Community 🌱

Heather Meeker for COSS Community

Posted on

SSPL Re-Takes the Stage in 2021

With the recent adoption by Elastic of the Server Side Public License (SSPL), after SSPL’s initial release in 2018, interest in the license has suddenly rekindled. We have seen lots of public commentary about the move and the license, but as usual, some of the truth and most of the nuance gets lost in the sound bites and headlines.

Here are a few questions that have been popping up:

-Is SSPL "open source"?
-Is changing the license fair?
-Is SSPL a good livensy for a commercial open source project?

What is Open Source -- Exactly?

Everyone knows about open source these days, but what exactly is an open source license? It might surprise you to hear there are different opinions on that subject. A license like SSPL hits at the heart of this question. Depending on whom you ask, SSPL lies right at the boundary of what can be an open source license -- or beyond it. For SSPL, there is a lot of history behind where the line is drawn, and how people talk about it.

The Open Source Initiative (OSI) is an organization that certifies licenses as open source. "Open source" is not a trademark, though, and trademark law is the main way our legal system gives one entity the power to prevent others from using a term to describe something.

There is also an Open Source Definition (OSD). It was written over 20 years ago. There are also similar definitions from the Free Software Foundation and Debian. They are similar but not identical. In fact, the Free Software Definition is probably the simplest and tersest of these definitions. The most important element of it is called “Freedom Zero”: The freedom to run the program as you wish, for any purpose. https://www.gnu.org/philosophy/free-sw.en.html

But, necessarily, there are many open source licenses that are not approved by OSI. There are several reasons for this. First, there are literally hundreds of variations of licenses like BSD and MIT. OSI has approved some of the more common ones. Second, some licenses are simply never submitted to OSI for approval.

Third, and most important, OSI approval is a sufficient but not a necessary condition for a license to meet the open source definition. Once upon a time, OSI approved licenses based on whether they fit the OSD. But today, OSI also imposes other criteria to approve a license. OSI’s website cites these rules for the approval process: https://opensource.org/approval

Approve if, after taking into consideration community discussion, the OSI determines that the license conforms to the Open Source Definition and guarantees software freedom....

Reject if (a) the OSI determines that the license cannot practically be remedied to adequately guarantee software freedom, or (b) there is sufficient consensus emerging from community discussion that the license should be rejected for substantive reasons, ....

And many of the legacy licenses OSI approved long ago would probably not be approved today. So in sum, the criteria for approval have changed, but the OSD has not.

In recent years, there have been several controversies over the use of the term “open source,” even to describe software that is released under an approved OSI license. OSI has, officially and unofficially, sought to discourage uses of “open source” of which they do not approve. But because “open source” is not a trademark, their power to legally control the use of the term is quite limited, and controversies about the boundaries of what is open source are largely philosophical and political. Accordingly, different stakeholders place varying weight on whether OSI has approved a license, to determine whether they will use software, or weather they consider it open source.

For example, all of the major Linux distros have rules about what they will include. But their lists of approved licenses are not exactly the same as the OSI approved list -- usually excluding some of the OSI approved licenses, and including some that are similar but not approved. Most private companies have compliance policies with “stop/go/caution” lists, but they usually exclude some OSI-approved licenses, like AGPL, for which compliance can be more difficult to monitor. The OSI imprimatur carries weight with government procurement, or non-profit foundations that support open source programs, where they particularly want a community consensus (in the form of OSI approval) to demonstrate that they are working in the public interest.

When I advise clients about what to call "open source," I advise them to use the term only for licenses that meet the OSD.

Is SSPL Open Source?

To understand the bid and ask on this topic, you have to understand the process of OSI approval and the facts behind SSPL. SSPL was created by MongoDB to address the so-called “AWS stripimininig problem.” At the time, many companies were adopting source available licenses -- licenses with restrictions that do not meet the OSD, but MongoDB took a different approach. SSPL was applied to the MongoDB software, and submitted by MongoDB for approval to OSI. After months of discussion, it was withdrawn from consideration for OSI approval. SSPL was never approved or rejected by OSI. The discussion is publicly available (License review archives are here: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/, but searching the archives is cumbersome, so here is a thread with some of the discussion: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/thread.html

SSPL was submitted on the premise that it met the open source definition. During the long and lively discussion, some concerns were articulated about why it did not actually meet the OSD. MongoDB offered to make certain changes to meet objections.

But the discussion went far beyond the question of meeting the OSD, including objections based on aspects other than the text of the license. Below are two examples from Bradley Kuhn, who was not the only voice raising objections, but whose comments capture the flavor of the discussion. These were objections not about the license terms, but about the identity of MongoDB and whether a private company should have the right to write and submit a license for approval.

"The fundamental problem IMO is that we are reasonably sure that MongoDB plans to abuse the copyleft system with the SS Public License -- refusing themselves to be bound by it while using it as a lever to force "customers" into buying proprietary licenses." -- Bradley Kuhn

"I think it is completely reasonable for the OSI to reject a license review request not necessarily for the content of the license, but on grounds that a public process of comment and discussion were not used to draft a license containing a major policy change in FOSS licensing." -- Bradley Kuhn

Adding to the confusion was the facts that OSI offers no definition of what "guarantees software freedom." On a certain level, no license -- Apache or BSD or GPL or AGPL -- can do this. In fact, the motivation for creating a license like SSPL was a view that AGPL was not sufficient to compel all users to share their changes.

Participants in the discussion disagreed on whether the license should be approved, and what the criteria should be for approval. Some have suggested that OSI should be more transparent and concrete about its criteria, or update the OSD to reflect the concerns articulated in the discussion.

But when commentators say that SSPL is "not open source" -- that’s an opinion that some, but not all, share. Presenting it as fact is misleading, particularly when the reasons for that conclusion are not disclosed.

Is it fair to change a license?

It depends on whom you ask, of course. Changing licenses can be disruptive, so for the licensor, the question is whether the change is worthwhile. But no software licensor has an obligation to continue to support and improve its own open source project at all, much less under any given license.

License changes are unusual but not exactly rare. Plenty of open source projects have licensing models that change over time. Most changes most toward more permissive licensing, but some move away from open source licenses entirely, or add licenses as options, or move to stronger copyleft.

A user base that uses a project under an existing license is usually dismayed by a change. But anyone who dislikes a license change can always stick with the version under its preferred license, or fork the project, and we have seen lots of examples of this, like LibreOffice and the Red Hat build of OpenJDK. That’s one of the reasons open source is good for business continuity.

Is SSPL a good license for a company to adopt?

That's a question about business strategy. For most companies, particularly new companies, SSPL or even AGPL is not the right choice.

Companies adopt these licenses to forestall competition, particularly among cloud services providers. But any license that forestalls competitors runs the risk of decreasing adoption by other users. SSPL and the common source-available licenses (like PolyForm, and the Elastic license for that matter) are not on most company policy "go" lists, like Apache 2.0 would be. With any new or unusual license, potential adopters bear what I call an "understanding tax." These licenses are complicated and not well understood. All that creates friction that reduces adoption.

Both MongoDB and Elastic have stated publicly that adopting SSPL changes nothing for most of their users, but they are successful and mature companies with large existing user bases. Most startup project would have trouble gaining traction with a license like SSPL.

Top comments (1)

Collapse
 
chasnelson1990 profile image
Chas Nelson

Great article @heathermeeker . I have a question for you: my company is currently working towards making our codebase open source and we've been really struggling with the argument of competition vs adoption with AGPL.

As a bit of context we're developing tools for other businesses to use when developing their own AI tools and products. We plan to offer our code as open source repositories largely because one of the things our tools are focused on is transparency and auditability and we believe that we have to practice what we preach.

We expect we will be able to build up a modest community of developers/data scientists contributing to the open source tools but our sales market is largely non-data companies who need to use our tools for productivity, audit and regulation of AI tools or products they may be developing with in-house data teams or external data partners.

We intend to host the whole pipeline with a SaaS-like model. For us, AGPL makes business sense. To us it says: "use our code, sell our code, but make sure you contribute back - we're only small and if you steal from us we'll go under" but I am very aware that there are big companies who say no to AGPL and also some community backlash over recent years. Do you have any thoughts or advice on how a small company balances the fear of competition from the big players with the desire to see widespread adoption?