Fact-checked by Grok 2 weeks ago

Server Side Public License

The Server Side Public License (SSPL) is a copyleft software license created by MongoDB, Inc. in October 2018 as an extension of the GNU Affero General Public License (AGPL), requiring that any entity offering the licensed program as a managed service publicly release the source code of its entire service stack under SSPL terms. Designed to close perceived loopholes in the AGPL exploited by cloud providers—such as (AWS)—which hosted instances without contributing modifications or service-layer code back to the community, the SSPL mandates disclosure of all components used to operate and manage the software, including proprietary tools and infrastructure scripts. MongoDB adopted the SSPL for its Community Server edition starting October 16, 2018, alongside dual-licensing options like the commercial Server Side Enterprise License for enterprise users, aiming to protect its database technology from unreciprocated commoditization by hyperscale vendors. The license sparked significant debate over its compatibility with open-source principles, with the (OSI) rejecting it in 2021 for imposing undue burdens on service providers and failing to meet criteria like non-discrimination against fields of endeavor, leading companies like to cite it as a model for their own restrictive licenses while critics labeled it a proprietary trap disguised as . This controversy prompted community responses, including the creation of SSPL-free alternatives like FerretDB, an open-source MongoDB-compatible database, highlighting tensions between developer reciprocity goals and the broader ecosystem's preference for permissive licensing in cloud-native environments.

History

Origins and Development

The Server Side Public License (SSPL) was developed by MongoDB, Inc. as a response to the challenges posed by the growing prevalence of software-as-a-service (SaaS) models in the cloud computing industry. Prior to the SSPL, MongoDB Community Server had been released under the GNU Affero General Public License version 3 (AGPLv3), which aimed to extend copyleft obligations to network use but was perceived by MongoDB to fall short in enforcing reciprocity from large-scale service providers who modified and hosted the software without disclosing their changes or surrounding infrastructure. On October 16, 2018, MongoDB announced the SSPL, applying it to all Community Server releases from that date onward, including patch fixes for earlier versions. The license's origins trace to MongoDB's substantial investment in research and development—exceeding $300 million over the preceding decade—which fueled innovations in the document-oriented database but faced exploitation by cloud vendors offering managed MongoDB services without contributing equivalent value back to the open source community. MongoDB positioned the SSPL as an evolution of copyleft principles, explicitly requiring that any entity offering the software as part of a broader service must release the source code for the entire service stack under the same terms, thereby addressing ambiguities in the AGPLv3 that could lead to protracted legal disputes with hyperscale providers. This approach sought to sustain open source development by aligning incentives for commercial users, particularly those monetizing hosted instances, to participate in upstream improvements. In terms of development, the SSPL version 1.0 was drafted internally by MongoDB's legal team, building directly on the structure of the AGPLv3 while expanding the scope of obligations to encompass not just the software itself but the operational modifications and service layers built around it. The license text, copyrighted by MongoDB, Inc. in 2018, emphasizes verbatim distribution permissions while imposing strong conditions on service-oriented deployments to prevent "freeloading" on community efforts. No subsequent versions have been issued, and the SSPL remains tied exclusively to MongoDB's ecosystem, reflecting its tailored design to protect the company's dual model of community-driven innovation and enterprise offerings.

Introduction and Relicensing by MongoDB

The Server Side Public License (SSPL) is a source-available copyleft software license drafted by MongoDB, Inc., to impose reciprocal source code disclosure requirements on entities offering licensed software as a managed service. It extends the copyleft model of the GNU Affero General Public License version 3 (AGPLv3) by explicitly mandating the release of "Service Source Code"—encompassing not only the modified program but also surrounding management, authentication, and deployment components—under the same license terms when the software is provided remotely to third parties. MongoDB announced the SSPL on October 16, 2018, as a measure to counteract the practice of hyperscale cloud providers, including , DocumentDB, and Google Cloud Datastore, which replicate and commercialize MongoDB's functionality in proprietary without contributing modifications or enhancements back to the upstream project. This relicensing addressed a perceived shortfall in the AGPLv3's "remote network interaction" clause, which MongoDB argued failed to reliably compel disclosure from service operators who host unmodified instances alongside proprietary wrappers, thereby allowing value extraction from community-driven development without reciprocity. Under the relicensing, all releases and patch fixes of MongoDB Community Server issued on or after October 16, 2018, transitioned to the SSPL, while versions predating that date retained the AGPLv3. The change did not affect holders of 's commercial licenses, which permit proprietary deployments and without the SSPL's obligations. cited its cumulative investments surpassing $300 million over the prior decade as justification for the license's protective intent, aiming to sustain innovation by ensuring that service providers either contribute code or pursue commercial agreements.

OSI Approval Process and Rejection

The Server Side Public License (SSPL) was submitted to the Open Source Initiative (OSI) license-review mailing list on November 21, 2018, for consideration as an OSI-approved open source license. The OSI's approval process requires public discussion on the mailing list, followed by analysis against the Open Source Definition (OSD), and ultimately a decision by the OSI board after a comment period. During the review, participants raised concerns that SSPL's Section 13—requiring providers of services using the licensed software to publish the source code of their entire service stack, including proprietary components—imposed discriminatory conditions on commercial hosting providers, violating OSD clause 6, which prohibits discrimination against fields of endeavor. Critics, including representatives from Red Hat and other organizations, argued that these obligations extended copyleft beyond the software itself to restrict surrounding infrastructure and business models, potentially conflicting with OSD clauses 5 (no discrimination against persons or groups) and 9 (license must not restrict other software). The review highlighted SSPL's intent to address "cloud provider exploitation" by extending AGPL-like network use triggers to encompass all operational software for hosted services, but this was deemed to create burdens that could render the non-reusable in unmodified form for many users. No formal approval recommendation emerged from the discussions, with widespread agreement among reviewers that SSPL failed to meet OSD criteria due to its conditional reciprocity demands on service operators. On March 8, , MongoDB announced its withdrawal of SSPL from the OSI , citing a desire to avoid prolonging debate while affirming the 's role in protecting against proprietary SaaS offerings of MongoDB software. In January 2021, the OSI explicitly affirmed that SSPL does not qualify as an under the OSD, characterizing it as a "fauxpen" approach that limits user freedoms rather than granting them. has not resubmitted SSPL and notes in its that while the license aligns with its goals for source availability, it lacks OSI endorsement due to differing interpretations of principles. The episode underscored tensions in licensing over balancing contributor protections against broad permissiveness, influencing subsequent debates on "source-available" models.

License Provisions

Core Copyleft Requirements

The Server Side Public License (SSPL) mandates that recipients of the licensed program who convey modified versions must distribute them under the same terms, including all notices, texts, and disclaimers, while providing the corresponding in its preferred form for modification. Section 5 specifically requires that such modifications bear notices indicating changes and the date of any substantial alterations, ensuring derivatives remain subject to SSPL's reciprocal obligations. For distributions, Section 4 obligates provision of the or an offer to supply it, preventing binaries without accompanying openness. The SSPL's most expansive copyleft provision appears in Section 13, which activates upon offering the program's functionality—or a modified version—to third parties as a service. In such cases, the licensee must make the "Service Source Code" available for network download at no charge under SSPL terms; this encompasses the corresponding source for the program itself plus all software used to enable the service, explicitly including management tools, user interfaces, APIs, automation scripts, monitoring systems, backup mechanisms, storage solutions, and hosting infrastructure—collectively sufficient for a user to deploy an equivalent service instance. Triggers for this requirement include remote network access to the program's features, services deriving primary value from the program, or those fulfilling the program's core purpose on behalf of users. MongoDB clarifies that Section 13 targets only external service offerings of (or derivatives) to third parties, sparing internal deployments or mere application usage atop the database, and took effect for versions released on or after October 16, 2018. This clause broadens traditional by extending reciprocity to the full operational stack, aiming to compel disclosure of proprietary layers that providers might layer over the software without reciprocating contributions. Unlike narrower clauses in licenses like the AGPL, SSPL's formulation demands the entire service-enabling , addressing perceived ambiguities in prior scopes.

Scope of Obligations for Service Providers

The obligations under the Server Side Public License (SSPL) for service providers arise specifically under Section 13, which addresses scenarios where the functionality of the licensed program—such as Community Server—or a modified version is made available to third parties . This trigger activates when the provider enables remote interaction with the program or offers a service whose primary value derives from accomplishing the program's core purpose on behalf of users, effectively extending beyond mere internal use to public or managed offerings. Service providers must then make the "Service Source Code" available to recipients for download over a network at no additional charge, licensed under the SSPL terms. The Service Source Code encompasses not only the Corresponding Source for the original or any modifications thereto—which includes all essential files needed to generate, install, and run the , excluding mere definitions or libraries—but also the Corresponding Source for all other programs utilized by the provider to operate, control, or manage the service. This broader requirement covers ancillary software such as management , , tools, systems, mechanisms, orchestration, and hosting , even if unmodified by the provider. These provisions apply to Community Server versions released on or after October 16, 2018, including subsequent patch releases. The intent, as articulated by , is to compel of the full service stack to prevent "as-a-service" offerings from exploiting SSPL-licensed components without , distinguishing it from narrower scopes in licenses like the AGPL. Providers offering such services publicly, such as cloud-hosted database instances, fall within this scope if they leverage post-2018 versions without commercial licensing alternatives. Non-compliance risks license termination, reverting interactions to claims under applicable law.

Permissions and Restrictions

The Server Side Public License (SSPL) grants recipients permission to run unmodified instances of the licensed Program without additional conditions, provided such use does not trigger Section 13 obligations related to provision. Licensees may also propagate the Program by conveying verbatim copies of its , preserving all notices, the text, and any of . Modifications to the are permitted, but conveyed modified versions must be licensed under the SSPL, include prominent notices of changes, and specify the date of any release terms. For distributions, licensees must provide the Corresponding Source—defined as the sufficient to generate the , including scripts and interfaces—either directly, via a written offer valid for at least three years, or through access under the same conditions as the . Key restrictions prohibit sublicensing the or imposing any further limitations on the rights granted by the SSPL, such as requiring license fees, royalties, or hardware purchase commitments from recipients. Licensees cannot convey the except as expressly allowed, and any attempt to modify or propagate beyond these terms automatically terminates the granted rights. The license mandates that no additional restrictions be placed on other software distributed with the , ensuring recipients retain full SSPL freedoms. A distinctive restriction arises under Section , which addresses "offering a as a Service." If a performs activities equivalent to Sections 4–6 (conveying source or ) with respect to the , or if the constitutes a meaningful part of the service's primary purpose or value and is made available remotely from the licensee's systems, the must provide the complete Service Source Code. This includes not only the but all components necessary to generate, install, and execute the service, such as management software, , and deployment tools, made available for download via a public at no charge during the service's operation plus one year thereafter. Failure to comply voids the license, effectively barring commercial hosting providers from offering SSPL-licensed software in without open-sourcing their entire operational stack. This clause extends beyond the itself to encompass broader service architectures, distinguishing SSPL from narrower licenses like the AGPL.

Comparisons to Other Licenses

Relation to AGPL and Earlier Copyleft Licenses

The Server Side Public License (SSPL), introduced by in October 2018, is explicitly based on the GNU Affero General Public License version 3 (AGPLv3), reproducing its provisions nearly verbatim while appending a novel Section 13 to broaden enforcement. This addition mandates that any entity offering SSPL-licensed software—such as —as a remote service must release the code for the entire service stack under SSPL terms, including ancillary components like management interfaces, , and deployment tools not directly part of the core program. In contrast, AGPLv3's network clause (Section 13 in AGPL) triggers disclosure obligations only for modifications to the AGPL-covered software itself when users interact remotely, allowing wrappers or service layers around unmodified AGPL code to remain closed. For instance, a provider could legally host unmodified AGPL software with orchestration code under AGPL, but SSPL classifies such a full-service offering as a requiring comprehensive publication. This extension addresses a perceived in AGPLv3 exploited by "database-as-a-service" (DBaaS) providers, who could profit from SSPL precursors like (previously AGPL-licensed until 2018) without contributing upstream improvements or exposing their value-adding layers. positioned SSPL as a defensive measure against hyperscalers like , which launched managed -compatible services in 2016 without open-sourcing surrounding infrastructure, thereby capturing market share while free-riding on community-developed code. AGPLv3, ratified by the in 2007, itself evolved from GPL family licenses to close the " loophole" in earlier models, where binary distribution triggered share-alike but mere network access did not. Relative to pre-AGPL copyleft licenses like the GNU General Public License (GPLv2, 1991) or Lesser GPL (LGPL, 1991), SSPL represents a further intensification of viral reciprocity tailored to cloud economics. GPLv2 enforced source availability only upon physical or binary distribution of derivatives, leaving unmodified software in hosted environments unregulated—a gap AGPL partially bridged and SSPL escalates by redefining "modification" to include service-level integrations. LGPL variants permitted linking with proprietary code under narrower conditions, but SSPL rejects such leniency entirely for service-oriented use cases, prioritizing prevention of proprietary "black box" exploitation over permissive interoperability. Critics, including the Open Source Initiative (which rejected SSPL certification in 2019), argue this imposes asymmetric burdens on commercial operators disproportionate to traditional copyleft, potentially stifling adoption compared to AGPL's narrower scope. Proponents, aligned with MongoDB's rationale, contend it upholds copyleft's foundational causal logic: ensuring downstream value extraction reciprocates upstream openness in an era where services, not binaries, dominate distribution.

Distinctions from Permissive and Proprietary Models

The Server Side Public License (SSPL) imposes copyleft obligations absent in permissive licenses such as MIT or Apache 2.0, which allow unrestricted use, modification, and distribution—including proprietary derivatives and SaaS offerings—without mandating source code disclosure for changes or hosted services. Under SSPL Section 13, any entity offering the licensed program (or modifications) as a network service must provide, at no charge, the complete source code of the service, encompassing not only the program but all associated management, operations, and interface software used to deliver it. This extends beyond the software's codebase to the provider's operational stack, contrasting with permissive licenses that enable cloud operators to build and monetize closed-source managed services atop the original work, as exemplified by Amazon Web Services' DocumentDB, a MongoDB-compatible offering that avoids reciprocity under prior permissive terms. Such distinctions arise from SSPL's intent to rectify the "SaaS loophole" in earlier licenses, where hyperscalers leverage community-developed software for commercial hosting without contributing improvements, thereby undermining developers' incentives. Permissive models prioritize broad adoption and innovation through minimal restrictions, fostering ecosystems where derivatives need not reciprocate openness, whereas SSPL enforces viral sharing for service-based use to ensure economic sustainability for originators like , which relicensed in October 2018 to counter such exploitation. In relation to proprietary models, SSPL grants source availability, unlimited runtime use of unmodified versions, and rights to modify and redistribute under its terms—freedoms typically withheld in closed-source licenses that prohibit alteration or sharing absent paid agreements. software often reserves all rights to the licensor, limiting users to binary access and contractual use, while SSPL permits verbatim copying, modification for non-service propagation, and object code distribution paired with source offers. Yet, SSPL's service-specific burdens—requiring full-stack disclosure for commercial hosting—mirror proprietary tactics to restrict certain revenue models, prompting the to deem it non-open source for discriminating against fields of endeavor, unlike permissive grants or even AGPL's narrower network . This positions SSPL as a protective against by service giants, more permissive than pure closure but far stricter than permissive openness, effectively hybridizing with economic safeguards tailored to cloud-era dynamics.

Reception and Debates

Open Source Community Perspectives

The (OSI) rejected the Server Side Public License (SSPL) in 2019, concluding it fails to meet (OSD) due to discriminatory restrictions against commercial service providers and excessive obligations that render it incompatible with open source principles. Specifically, OSI cited violations of OSD criterion 5, which prohibits discrimination against persons or groups, and criterion 9, which requires licenses not to restrict other software, arguing that SSPL's requirement to open-source entire surrounding software stacks for imposes an unreasonable burden not present in approved copyleft licenses like the AGPL. Within developer forums and communities, SSPL has faced widespread criticism for effectively functioning as a source-available license rather than a true open source one, deterring adoption and collaboration. For instance, after Elastic N.V. relicensed Elasticsearch and Kibana under SSPL in January 2021 to curb cloud provider exploitation, the community responded by forking the projects into OpenSearch, highlighting concerns that SSPL prioritizes proprietary control over communal freedoms. Developers on platforms like Hacker News have described SSPL-licensed software as a "business risk," arguing it isolates projects from broader ecosystems by prohibiting seamless integration in proprietary or non-copyleft environments. Database specialists and open source advocates, including those at , have questioned MongoDB's status under SSPL, noting that its expansive —extending to all software interfacing with the licensed code for remote access—discourages enterprise use and favors over . The (FSF) has not endorsed SSPL, omitting it from its list of licenses, which implies incompatibility with ideals despite the license's elements extending beyond AGPL. While some voices defend SSPL as a pragmatic response to "cloud parasites" like AWS DocumentDB, which replicate functionality without contributing code, the prevailing community view emphasizes that such protections undermine the collaborative ethos of by limiting derivative works and downstream innovation.

Industry and Legal Critiques

Industry representatives, particularly from cloud service providers and support firms, have criticized the SSPL for imposing burdensome obligations that hinder commercial deployment of server software. Companies such as argue that the license effectively prevents cloud vendors from offering managed services without publicly releasing their entire operational codebase, including proprietary management, backup, and monitoring tools, thereby stifling competition and favoring MongoDB's own Atlas platform. This restriction, critics contend, creates and elevates costs for users, as alternatives like self-hosted or third-party managed instances become impractical for large-scale operations. ScyllaDB and other database firms highlight how the SSPL's expansive definition of "offering a " extends beyond traditional scopes like the AGPL's interaction clause, potentially encompassing any API-mediated use and deterring enterprise adoption due to compliance uncertainties. For instance, cloud providers like AWS and Alibaba have responded by developing compatible alternatives or forks, such as , to avoid SSPL entanglements, underscoring the license's incompatibility with permissionless in database-as-a-service models. These critiques portray the SSPL as a proprietary-leaning tool that undermines the collaborative ecosystem of by discriminating against hosting providers. Legally, the SSPL faces scrutiny for failing to meet the Open Source Definition (OSD), particularly provisions against discrimination in fields of endeavor (OSD 6) and against specific technologies (OSD 9), as it targets operators with additional source disclosure requirements not applied to other users. The (OSI) explicitly rejected SSPL compliance in 2019, prompting to withdraw its approval application amid concerns over these restrictions. Furthermore, the license's vague delineation of "service" introduces enforcement risks, potentially leading to disputes over whether ancillary tools or integrations trigger full codebase publication, a breadth exceeding even AGPL precedents and raising questions of overreach in enforcement. Legal analysts note that such ambiguities could render the SSPL vulnerable to challenges in jurisdictions emphasizing clear contractual terms, further eroding its appeal for risk-averse enterprises.

Proponents' Arguments for Protective Intent

Proponents of the Server Side Public License (SSPL), led by MongoDB, contend that it addresses a critical vulnerability in prior copyleft licenses like the GNU Affero General Public License (AGPL) by extending reciprocity requirements to operators of network-based services. Specifically, the SSPL mandates that entities offering SSPL-licensed software as a service to third parties must provide the source code for their entire service infrastructure, including management tools, user interfaces, and supporting systems, under the same license. This provision, introduced by MongoDB on October 16, 2018, targets what proponents describe as exploitation by hyperscale cloud providers, such as Amazon Web Services (AWS), which had launched managed MongoDB-compatible services like DocumentDB in 2017 without disclosing service-related code or contributing enhancements back to the upstream project. MongoDB executives, including then-CTO , argued that traditional licenses failed to capture value created in the SaaS model, where cloud vendors derive substantial revenue—AWS alone reported over $10 billion in database service income by —by packaging software with wrappers, effectively commoditizing the core project while retaining competitive advantages in and operations. The SSPL's protective intent, per its drafters, ensures "" by compelling service operators to share innovations that improve deployment, , and , thereby sustaining developer motivation and preventing free-riding that could starve projects of resources. This mechanism preserves end-user freedoms to use, modify, and redistribute the software while adapting to modern cloud economics, where software value accrues through hosted delivery rather than distribution alone. Further, proponents emphasize that the license incentivizes sustainable business models for maintainers, as non-compliant service providers must either open-source their stacks—potentially benefiting the —or negotiate commercial terms, as did with its Enterprise Advanced offering. By requiring source disclosure for services accessed over a , the SSPL aims to foster a collaborative environment akin to on-premises but calibrated for distributed systems, countering the trend where, by 2018, over 80% of deployments occurred in environments without reciprocal contributions. Critics of weaker licenses, echoing 's rationale, assert this protects against "asymmetric value extraction," where small teams invest years in development only for giants to extract billions without reciprocity.

Controversies and Legal Challenges

Debate Over Open Source Compliance

The (OSI) has explicitly stated that the Server Side Public License (SSPL) does not comply with (OSD), rendering it ineligible for OSI approval as an . The OSI's determination stems from SSPL's imposition of obligations that extend beyond the licensed software itself, particularly requiring operators of remote services to disclose the source code of their entire service infrastructure—including potentially components not derived from the SSPL-licensed material—under SSPL terms if the service utilizes the software. This violates OSD criterion 6, which prohibits licenses from restricting other software distributed or used alongside the licensed work, as SSPL effectively conditions freedoms on open-sourcing unrelated elements of a service provider's stack. Critics argue that SSPL discriminates against commercial fields of endeavor, contravening OSD criterion 5 by targeting service providers who monetize the software via software-as-a-service (SaaS) models, while exempting non-commercial or internal uses. Unlike the GNU Affero General Public License (AGPL), which OSI approves and limits reciprocity to the modified software offered over a network, SSPL's broader "service source code" requirement—encompassing management tools, interfaces, and deployment automation—creates compliance barriers that are often infeasible for large-scale operators, effectively limiting redistribution freedoms for certain users. Legal analysts have noted that this structure transforms SSPL into a source-available license rather than open source, as it prioritizes the licensor's (MongoDB's) business protection over universal software freedoms, potentially enabling "license proliferation" that fragments the ecosystem. MongoDB, the license's drafter, defends SSPL as an evolution of principles to address AGPL's perceived inadequacies in preventing hyperscale cloud providers from offering proprietary atop without reciprocal contributions. maintains that SSPL preserves core freedoms—use, modification, and distribution—for non-SaaS contexts while closing a "SaaS loophole," asserting compliance with OSD through undiscriminated application to all service operators, regardless of scale or intent. However, this position has not swayed OSI reviewers, who in 2018 discussions highlighted the license's failure to ensure practical exercisability of rights, leading to its retraction from formal approval review amid stalled community consensus. The debate underscores tensions between ideals of maximal freedoms and protective measures against extraction by commercial entities, with surveys of developers indicating widespread rejection of SSPL-licensed projects in distributions like due to non-compliance risks. Proponents of stricter view SSPL as a necessary innovation, yet empirical adoption patterns—evidenced by forks like FerretDB migrating to permissive licenses—reveal community preference for OSI-approved alternatives to avoid legal ambiguities in compliance.

Conflicts with Forks and Alternatives like FerretDB

The Server Side Public License (SSPL) imposes obligations that extend beyond the licensed software itself, requiring distributors offering the software as a managed service to release the source code of their entire service stack—including hardware, operating systems, and ancillary tools—under SSPL terms. This expansive requirement discourages forking MongoDB's codebase for commercial or cloud-based deployments, as modifiers risk non-compliance if they cannot or will not disclose elements of their . Unlike more permissive licenses such as AGPLv3, SSPL's viral nature effectively limits forks to non-service contexts, prompting developers to pursue protocol-compatible alternatives rather than direct derivatives. A prominent example of such tensions involves FerretDB, an 2.0-licensed proxy that translates MongoDB's wire protocol queries to SQL for backends, positioning itself as a without incorporating MongoDB's . On November 3, 2023, issued a cease-and-desist letter to FerretDB, alleging unlicensed use of MongoDB Community Edition in FerretDB's development, which purportedly violates SSPL or prior AGPL terms, alongside potential claims related to protocol implementation. FerretDB maintains that its project reimplements the independently to avoid SSPL restrictions, emphasizing its open-source status under OSI-approved terms to enable broader adoption, including in cloud environments. This dispute escalated publicly by April 2025, with reiterating threats of legal action over alleged licensing infringements, while FerretDB highlighted SSPL's non-OSI approval as a barrier to true open-source forking or . The conflict underscores broader challenges: SSPL's design, intended to curb "free-riding" by providers, inadvertently stifles community-driven evolution through forks, favoring alternatives or reimplementations that evade its scope but invite litigation over . No major SSPL-compliant forks of have gained traction, as evidenced by the absence of active AGPL-based derivatives post-2018 relicensing, driving migrations to projects like FerretDB or CouchDB.

Broader Implications for OSS Ecosystem

The introduction of the Server Side Public License (SSPL) in 2018 by has spurred a reevaluation of sustainability amid the dominance of , prompting developers and companies to explore licenses that impose stricter reciprocity requirements on service operators. Unlike traditional licenses such as the GNU AGPL, SSPL mandates the release of an entire service's —including proprietary management layers—when the software is offered as a managed service, a condition the (OSI) deemed incompatible with due to its discrimination against commercial hosting models and undue field-of-endeavor restrictions. This rejection, formalized in 2018, has contributed to a broader trend where projects like and transitioned to SSPL or analogous source-available licenses (e.g., Business Source License) by 2021, aiming to curb "cloudification" by hyperscalers like that derive revenue from OSS without equivalent contributions. In the ecosystem, SSPL's framework has accelerated fragmentation, as evidenced by community-driven forks such as FerretDB (launched in 2021 as an Apache-licensed alternative to ), which prioritize permissive terms to maintain interoperability and adoption despite forgoing the protective intent of SSPL. This has intensified debates over viable business models, with analyses indicating that restrictive licenses protect dual-licensing revenues for vendors— reported $1.7 billion in annual recurring revenue by fiscal 2024 partly through subscriptions circumventing SSPL constraints—but at the cost of reduced upstream and ecosystem . Distributions like and have excluded SSPL-licensed software from repositories, citing compliance burdens that extend beyond code to operational infrastructure, thereby limiting its propagation in environments. Long-term, SSPL exemplifies a shift toward "fair source" paradigms that challenge the permissive-copyleft binary, fostering innovations like time-bound source-available models while highlighting vulnerabilities in cloud-era OSS: a 2024 legal review noted over 20% of database projects adopting hybrid licenses since 2018, correlating with stalled growth in community contributions for affected repositories. Critics, including OSI affiliates, argue this erodes the collaborative ethos underpinning OSS success, potentially deterring investment as users favor verifiable compliance over vendor-specific protections; proponents counter that without such measures, commoditization by cloud giants—exemplified by AWS's DocumentDB launch in —undermines developer incentives, necessitating evolved reciprocity to sustain .

Adoption and Impact

Software Projects Under SSPL

The primary software project licensed under the Server Side Public License (SSPL) is , a management system developed by . Starting with patch releases and versions issued on or after October 16, 2018, relicensed its community edition from the GNU Affero General Public License (AGPL) to SSPL to address concerns over cloud providers offering managed services without reciprocal contributions. This change applied to the core database software, while enterprise features remained under separate commercial terms. Elastic N.V. adopted SSPL in a dual-licensing model for , a distributed search and analytics engine, and , its associated visualization tool, effective January 21, 2021. Previously under the Apache License 2.0, the shift to dual SSPL and Elastic License 2.0 aimed to restrict hyperscale operators from reselling these tools as managed services without open-sourcing their surrounding infrastructure. This relicensing affected all versions post-change, limiting redistribution freedoms compared to prior permissive terms. Adoption of SSPL remains limited beyond these cases, with no major additional projects identified in licensing databases or announcements as of ; its restrictive clause on service offerings has deterred broader use among open-source developers. and represent the license's core applications in data infrastructure software, where extensions target monetization models.

Effects on Cloud Providers and Business Models

The Server Side Public License (SSPL), introduced by on October 16, 2018, imposes a requirement that compels any entity offering SSPL-licensed software as a hosted service to disclose the source code of their entire service stack, including components like management interfaces and scaling infrastructure. This provision effectively precludes major cloud providers, such as (AWS), , and Google Cloud, from launching managed services based directly on SSPL software without risking exposure of competitively sensitive code. As a result, hyperscalers have systematically avoided deploying SSPL-licensed projects like MongoDB Community Server in their database-as-a-service offerings, opting instead for self-managed instances or alternatives. In direct response to the SSPL adoption, AWS accelerated the development and launch of on January 9, 2019, a proprietary document database engineered for compatibility with the 3.6 and tools but built on an independent engine rather than 's codebase. This circumvents SSPL obligations while enabling AWS to deliver scalable, managed capabilities, thereby sustaining revenue from database hosting without code-sharing mandates. Similar adaptations occurred elsewhere: supports compatibility via a proprietary backend, and Cloud Firestore provides document without relying on SSPL components. These moves reflect a strategic pivot where cloud providers invest in emulation to maintain service , avoiding while fostering customer lock-in through integrated ecosystems. The SSPL's restrictions have reshaped cloud providers' business models by disrupting the commoditization of open-source databases, which previously allowed low-cost managed services akin to AWS RDS for relational databases. Instead of forking and open-sourcing under SSPL—which would undermine proprietary value—providers like AWS have prioritized proprietary innovations, potentially increasing operational costs for R&D but enhancing margins through exclusive features and bundled services. For users, this translates to reduced options for cost-effective, truly open-source managed deployments, often resulting in higher pricing for compatible proprietary services or the need for self-hosting, which elevates administrative burdens. MongoDB's Atlas service, conversely, benefits from insulated competition, as hyperscalers cannot replicate its full stack without SSPL adherence, bolstering MongoDB's cloud revenue—Atlas accounted for over 60% of its total revenue by fiscal 2023. However, the license's deterrent effect limits SSPL software's penetration in public clouds, constraining broader ecosystem growth and prompting alternatives like FerretDB, a PostgreSQL-based MongoDB-compatible fork under Apache 2.0.

Long-Term Developments and Alternatives

Since its introduction in 2018 by MongoDB, the SSPL has experienced limited proliferation, with adoption primarily confined to MongoDB's ecosystem and a brief dual-licensing experiment by Elastic for Elasticsearch and Kibana in January 2021, after which Elastic retained a proprietary Elastic License alongside SSPL. By 2023-2025, broader trends indicate a shift toward source-available licenses rather than SSPL specifically, as companies seek to curb cloud providers' value extraction without reciprocal contributions, though SSPL's stringent requirements—mandating full source disclosure for managed services—have deterred widespread use due to compliance burdens on hyperscalers. This has contributed to ecosystem polarization, with open-source purists favoring OSI-approved licenses and commercial entities experimenting with restrictive models, evidenced by no major SSPL-specific legal precedents but ongoing debates over its incompatibility with traditional copyleft. Emerging developments include a away from SSPL toward strategies, such as Redis's relicensing to AGPLv3 in May 2025 explicitly to address cloud hosting without adequate reciprocity, highlighting SSPL's perceived overreach in alienating potential users. Similarly, the rise of time-bound licenses like the Business Source License (BSL), adopted by projects such as and , offers a middle ground by converting to permissive open-source terms after a delay (e.g., 4 years), allowing initial commercial protection without perpetual barriers. These evolutions reflect causal pressures from cloud , where permissive licenses enable "openwashing" by providers like AWS, prompting developers to weigh velocity against safeguards. Alternatives to SSPL emphasize OSI-compliant like AGPLv3, which extends GPL obligations to network users but falls short on comprehensive managed-service coverage, as remote access alone does not trigger full source release. or triple licensing models, as seen in Redis's 2025 approach combining AGPL with commercial terms, provide flexibility for contributors while restricting extractive cloud models. Custom source-available licenses, such as Elastic's ELv2 prohibiting competitive hosting, or add-ons like the Commons Clause atop Apache 2.0, serve as targeted countermeasures but risk similar rejection by distributions like and . Overall, these options prioritize empirical business sustainability over universal openness, with BSL gaining traction for its predictability in fostering long-term contributions post-conversion.

References

  1. [1]
    Server Side Public License (SSPL) - MongoDB
    “This License” refers to Server Side Public License. “Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
  2. [2]
    Server Side Public License, v 1 - SPDX
    "This License" refers to Server Side Public License. "Copyright" also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
  3. [3]
    SSPL — FerretDB
    The SSPL (Server Side Public License) is a software license created by MongoDB, Inc. · The SSPL is a copyleft license that requires any organization that offers ...
  4. [4]
    MongoDB's SSPL license: what does "offering as a service" actually ...
    Apr 15, 2021 · The primary intention is to prevent Amazon etc. from offering the MongoDB product as part of their cloud service without disclosing the source code AND without ...
  5. [5]
    Server Side Public License FAQ | MongoDB
    All versions of MongoDB's Community Server released on or after October 16, 2018, including patch fixes for prior versions, will be licensed under the SSPL.Missing: definition | Show results with:definition
  6. [6]
    The SSPL is Not an Open Source License
    Jan 19, 2021 · The license du jour is the Server Side Public License. This license was submitted to the Open Source Initiative for approval but later withdrawn.
  7. [7]
    The Case Against the Server Side Public License (SSPL)
    Oct 11, 2022 · This new kind of proprietary software license provides more freedoms than conventional proprietary licenses of decades past. But it is not open source.Missing: controversies | Show results with:controversies
  8. [8]
    MongoDB Issues New Server Side Public License for MongoDB ...
    The leading modern, general purpose database platform, issued a new software license, called Server Side Public License (SSPL), for MongoDB Community Server.
  9. [9]
    December 2018 License-Review List Summary
    Jan 7, 2019 · On Nov 21, the [SSPL v2] has been submitted for review. [SSPL v2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/ ...
  10. [10]
    The License Review process - Open Source Initiative
    Mar 13, 2024 · The OSI License Review Process ensures that licenses and software labeled as “Open Source” conform to existing community norms and expectations.
  11. [11]
    MongoDB "open-source" Server Side Public License rejected - ZDNET
    Jan 16, 2019 · The specific objection is that SSPL requires, if you offer services licensed under it, that you must open-source all programs that you use to ...
  12. [12]
    Red Hat explains why it's skeptical of the open source software ...
    Jan 18, 2019 · A clash between Red Hat and MongoDB shows the pitfalls of using open source licensing to fight against Amazon and other cloud giants.
  13. [13]
    SSPL Was Not Commons Clause - /dev/lawyer
    Jun 13, 2019 · I summarize the missed opportunity that was MongoDB's Server Side Public License, and how it was missed.
  14. [14]
    MongoDB no longer seeks OSI approval for SSPL | Lukas Atkinson
    Mar 9, 2019 · MongoDB no longer seeks OSI approval for SSPL. MongoDB announced that they are withdrawing the SSPL license from the OSI license-review process.<|separator|>
  15. [15]
    MongoDB Withdraws SSPL From Open Source Initiative Approval ...
    Mar 11, 2019 · MongoDB is withdrawing its controversial license, the Server Side Public License, from the approval process of the Open Source Initiative.Missing: history date
  16. [16]
    Difference between MongoDB SSPL and GNU AGPL
    Mar 2, 2019 · The 13th clause of the license states the following: If you make the ... clause 13 of the SSPL requires that you provide the source code of IIS.MongoDB's SSPL license: what does "offering as a service" actually ...AGPLv3 - Does indirect use over intermediary servers constitute ...More results from opensource.stackexchange.com
  17. [17]
    Is MongoDB Truly Open Source? A Critical Look at SSPL - Percona
    Is MongoDB open source? Explore the debate around MongoDB's SSPL license vs. true open source. Understand the OSI's stance and the impact on users.<|separator|>
  18. [18]
    The Dark Side of MongoDB's New License - ScyllaDB
    Oct 22, 2018 · MongoDB recently revised its open source license, creating the new Server Side Public License (SSPL). How does it compare to APGL?
  19. [19]
    AWS, MongoDB, and the Economic Realities of Open Source
    Jan 14, 2019 · This is in contrast to “permissive” open source licenses that allow ... MongoDB-created license called the Server Side Public License (SSPL).
  20. [20]
    https://www.mongodb.com/blog/post/mongodb-now-released-under-the-server-side-public-license
  21. [21]
    SSPL Is Bad | Hacker News
    Mar 29, 2024 · SSPL is mainly bad for the companies that use the license. They cut themselves off from their own open source communities.
  22. [22]
    osi - Has the FSF ever commented on the SSPL?
    Mar 31, 2023 · As your question acknowledges, the SSPL does not appear on the FSF's license list. Given how comprehensive this list otherwise appears to be, it ...Is the term 'open source' a trademark?Why is the Reciprocal Public License OSI-approved but not FSF ...More results from opensource.stackexchange.comMissing: criticism | Show results with:criticism
  23. [23]
    What I learned from the Server Side Public License - Sonar
    Feb 3, 2021 · 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.<|separator|>
  24. [24]
    Righteous, Expedient, Wrong - /dev/lawyer
    Jan 20, 2021 · On the same day Elastic NV and AWS traded barbs about Elastic's move to MongoDB's Server Side Public License, OSI weighed in with a hit ...
  25. [25]
    licensing - SSPL and the Open Source Definition
    Oct 23, 2018 · (Update 2019-03-09: MongoDB retracted the license from OSI review.) Does the SSPL have a chance of getting OSI-approved?Missing: timeline | Show results with:timeline
  26. [26]
    Why SSPL is Bad For You, Part 2
    Feb 2, 2021 · If you're just using software, SSPL is bad for you because it restricts your choices. SSPL is usually chosen to give one vendor a monopoly on ...
  27. [27]
    FerretDB/FerretDB: A truly Open Source MongoDB alternative - GitHub
    FerretDB is an open-source alternative to MongoDB. It is a proxy that converts MongoDB 5.0+ wire protocol queries to SQL and uses PostgreSQL with DocumentDB ...
  28. [28]
    [PDF] FerretDB Inc. - Blocks and Files
    Nov 3, 2023 · Moreover, any unlicensed use of MongoDB Community Edition to build FerretDB would violate the AGPL and/or SSPL. Absent a valid license to ...
  29. [29]
    MongoDB, FerretDB clash over open source definition
    Apr 8, 2025 · MongoDB has sent a cease-and-desist letter giving notice of potential legal action to startup FerretDB, claiming it infringes MongoDB's licensing terms.
  30. [30]
    https://www.documentdatabase.org/blog/mongodb-alternatives-ferretdb/
  31. [31]
    Has SSPL-licensed MongoDB been accepted? - Reddit
    Feb 11, 2024 · Have MongoDB users moved to FOSS alternative projects like Apache CouchDB or FerretDB? Why there is not an active AGPL MongoDB fork project?Can MongoDB be used for public websites because of licence ...r/programming - MangoDB – a truly open source MongoDB alternativeMore results from www.reddit.comMissing: conflicts | Show results with:conflicts
  32. [32]
    Moving Away From Open Source: Trends in Source-Available ...
    Sep 25, 2024 · Specifically, the SSPL requires anyone making the SSPL-licensed software or a modified version available to third parties as a service to ...Missing: obligations | Show results with:obligations<|separator|>
  33. [33]
    Open Source at a Crossroads: The Future of Licensing Driven by ...
    Jun 1, 2025 · After a set period, either four years or an earlier period set by the licensor, the BSL automatically converts to an open source license of the ...<|separator|>
  34. [34]
    FAQ on Software Licensing - Elastic
    We moved our Apache 2.0-licensed source code in Elasticsearch and Kibana to be dual licensed under Server Side Public License (SSPL) and the Elastic License.
  35. [35]
    Amazon Web Services calls MongoDB's licensing bluff ... - GeekWire
    Jan 9, 2019 · Last October, MongoDB announced that forthcoming releases of the eponymous open-source project would be covered by a new license called the SSPL ...
  36. [36]
    AWS, MongoDB database collision stirs open source tensions
    Jan 11, 2019 · The SSPL has no effect on MongoDB customers who have purchased commercial licenses. MongoDB claims the licensing change was necessary to ...
  37. [37]
    AWS Launches New Document-Oriented Database Compatible with ...
    Jan 13, 2019 · While offering a MongoDB-compatible API, DocumentDB is not running MongoDB software, which caused hand-wringing among some technology watchers.
  38. [38]
    MongoDB's New License Model Won't Save It From Competition ...
    Jan 10, 2019 · These moves were in response to the terms of the SSPL, which were deemed contrary to the spirit of open source. Adding insult to injury, AWS ...
  39. [39]
    MongoDB Matters: Amazon's War with MongoDB Heats Up
    Mar 4, 2019 · MongoDB's recent and well-publicized new license-the Server Side Public License (SSPL)-was explicitly designed to prevent cloud vendors such ...
  40. [40]
    Doubling down on open, Part II | Elastic Blog
    Jan 14, 2021 · SSPL is a source-available license created by MongoDB to embody the principles of open source while providing protection against public cloud ...
  41. [41]
    Fall 2024 Software Licensing Roundup | FOSSA Blog
    Oct 23, 2024 · But in 2021, Elastic relicensed Elasticsearch and Kibana to be dual-licensed under the Server Side Public License (SSPL) and the Elastic License ...<|separator|>
  42. [42]
    The Future of Open Source is Polarized - Percona
    Aug 15, 2023 · While some companies state that changing licenses away from open source is an industry trend, the community sees it as a hostile step.
  43. [43]
    Redis is now available under the AGPLv3 open source license
    May 1, 2025 · To counter this, companies like MongoDB and Elastic adopted SSPL to protect their business from cloud providers extracting value without ...Redis Released · Redis vs. Redis Open Source · Change<|separator|>
  44. [44]
    Evolution of Open Source Licensing to the Triple Licensing Model
    May 8, 2025 · This strategy involves offering a commercial license, a non-compete license for adoption, and a strong copyleft license for open source goodwill.Missing: history | Show results with:history