In October of 2018, MongoDB relicensed its previously open source database to a new source available license of its own creation. Up until that point, the license governing the project had been the AGPL, an OSI approved open source license that took the copyleft provisions of the GPL and extended them into applications hosted on networks.
In simple terms, where the GPL’s reciprocal provisions included software packaged and distributed in binary fashion, they did not apply to modified GPL projects hosted and made available over networks. If you wanted to distribute a new version of the Linux kernel, for example, you were required to make those changes available under the same terms. If you hosted applications on the internet running on a modified Linux kernel, however, you did not.
The AGPL was explicitly designed to close this so-called loophole. Historically, however, usage of the license has been rare relative to other open source licenses of both the copyleft and permissive varieties. This was in part because large internet companies strictly forbade its usage for fear of running afoul of the extended protections.
For MongoDB, however, the protections afforded by the AGPL did not go far enough. As a result, they set out to craft a license that followed in the AGPL’s footsteps by not applying reciprocal provisions to software hosted in a network fashion, but dramatically expanding the scope of these protections beyond the boundaries of the protected software itself and into adjacent software.
Specifically, the license says the following (emphasis added):
“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.
The AGPL strictly governs a given project’s codebase, then, while the SSPL extends itself to any immediately adjacent software. If large internet companies – and cloud providers in particular – were averse to the AGPL, then, the SSPL was a non-starter. In practical terms it is nearly impossible to comply with the terms of the license, and the reach is clearly at odds with if not totally irreconcilable with the ninth requirement of the open source definition.
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.
MongoDB initially attempted to work with the OSI to have the SSPL accepted and approved as an open source license, but the combination of a flawed review process and the license’s fundamental nature led to the eventual abandonment of those efforts. The license instead remains source available, not open source.
Other commercial vendors seeking exclusivity, however, began to take up the source available license at the expense of open source alternatives. In January of 2021, Elastic moved away from the permissive Apache license to a dual license strategy, one license of which was the SSPL. In March of 2024, Redis did the same.
Recently, however, the SSPL’s trajectory appears to have been altered. In September of last year, Elastic added the AGPL as another licensing option – effectively deprecating the more restrictive SSPL. Then this year on May 1st, Redis again followed in Elastic’s footsteps and added the AGPL as an option. In describing the thought process behind the move, Salvatore Sanfilippo – the original author of Redis – said:
My feeling was that the SSPL, in practical terms, failed to be accepted by the community. The OSI wouldn’t accept it, nor would the software community regard the SSPL as an open license. In little time, I saw the hypothesis getting more and more traction, at all levels within the company hierarchy.
No mention was made of the unique Redis fork Valkey in that post, but it appears in the comments and the idea that it had no role in the internal discussions on the license choice is implausible. Regardless of the motivation, the decision to return to an open source license was a consequential one and further evidence of a changing trajectory for the license and for open source.
Nor is it just SSPL projects moving to the AGPL. Grafana and MinIO previously moved from Apache licenses to the AGPL in April and May of 2021, respectively. The Zitadel project, meanwhile, did the same in March.
What do these moves collectively suggest, then, about the health of open source? Two things, at least, are implied.
- First, that commercial open source vendors continue to seek stronger protections for code they have authored. In the last decade plus, permissive licenses saw substantial jumps in their usage, and because licensing has historically been more fashion statement than rigorous analysis, each new permissively licensed project encouraged the next. In recent years and amongst commercially backed projects, however, there has been a backlash. Company after company leveraged permissive licenses initially in a bid to gain ubiquity, then ratcheted up protections with new licenses as they transitioned from a focus on growth to exclusivity of value capture.
That much has been apparent for years. The real question was where the equilibrium would be found: in OSI approved open source licenses, or in source available alternatives? The available evidence at this time suggests that the AGPL may be that equilibrium, combining OSI-approval with staunch protections and disincentives for large clouds, among other potential competitors.
-
And speaking of protections and large clouds, the second implication is that the AGPL is now viewed as sufficiently protective. A large part of the original justification for the SSPL and other source available alternatives was the need for protections from large, hyperscale clouds picking up permissively licensed projects and using their greater resources and distribution to advantage themselves over the original authors. It was even claimed by individuals outside of MongoDB, in fact, that AWS’ DocumentDB – which replicated MongoDB’s API without leveraging the MongoDB codebase – was a demonstration of the power and necessity of the SSPL. The timeline, however, does not support this argument. The SSPL was first applied to MongoDB in October 2018. DocumentDB, meanwhile, was released in January of 2019. Even at the speed AWS operates, they did not write, stand up, test and release a new database service in two months. It’s clear that for AWS, at least, the AGPL was sufficient disincentive to avoid the codebase. Questions remain as to whether the AGPL is a deterrent strong enough for Chinese cloud providers, then, but rightly or wrongly the market seems to be settling on the AGPL as the commercial open source license of choice, not the SSPL.
Which, even if some are disappointed that the AGPL is being used effectively as a proprietary software license, represents a win for open source. It also suggests that the next competitive frontier, thanks to Google v Oracle, will not be codebases but APIs, but that’s a subject for another time.
For now, it’s necessary to examine what represented a clear loss for open source, which was the drama surrounding the CNCF, NATS and Synadia. In late April, a conflict bubbled to the surface that would better have been kept private. In short, there were allegations that Synadia – the principal authors of NATS – wanted to withdraw its donation from the CNCF, including the trademarks. All is now putatively well between the two organizations, and NATS and its trademark will remain with the CNCF with Synadia’s stewardship.
But the flareup starkly revealed traditional fault lines in the wider open source community around the role of foundations. For many, this situation provided an opportunity not to protest the alleged about face but rather to attack foundations generally and the CNCF specifically for their shortcomings, both perceived and real.
Generally, critiques of foundations are appropriate. While RedMonk’s view is generally that foundations are useful and indeed vital, they are imperfect institutions that often struggle to balance the competing needs of vendors, enterprises and individual developers. Attention on where and how these “worst solutions except everything else that’s been tried,” to paraphrase Churchill, can be improved and refined is an important exercise.
The time for that exercise, here at least, is not when their existence is existentially threatened. Whatever else one may think of them, objectively speaking foundations exist as an external home for software, one in which certain guarantees and commitments are held sacrosanct, and in which commercial entities can trust and, optionally, collaborate. Vendors that choose to donate projects to foundations do so understanding, or at least should, that donation is a one way door. If commercial organizations can commit a project to this neutral third party, and then unilaterally withdraw from the foundation whenever it suits them, the guarantees of neutrality that foundations provide are immediately rendered worthless. The idea, then, the CNCF or any other foundation could blithely let a disaffected project depart was genuinely appalling to hear, akin to condoning the secession of states. However one feels about how a foundation has assisted or not assisted a member project, the idea that the irrevocable promise companies knowingly and willingly make when donating a project and its trademark to a foundation is actually, depending on the circumstances, revocable was genuinely shocking. It was also a sign that widespread bitterness towards and distaste for foundations remains a stronger force than may be commonly understood or appreciated.
While open source appears to have made progress towards a consensus around open source licenses that are commercially acceptable, then, the NATS storm was a black eye for open source broadly. Between the simmering antagonism towards foundations at scale, the direct attacks on the CNCF specifically and the revelations about NATS’ performance and Synadia’s alleged behaviors, it was not a great week for open source.
Two steps forward, one step back.
Disclosure: AWS and MongoDB are RedMonk customers. The CNCF, Elastic, Grafana, MinIO and Redis are not currently RedMonk customers.
