Server Side Public License (SSPL)

What is the Server Side Public License (SSPL)?

The Server Side Public License (SSPL) is a source-available license created by MongoDB Inc. in 2018 to address what they termed the "cloud service provider loophole" in traditional open source licensing. The SSPL is based on the GNU Affero General Public License (AGPL) but adds significant additional requirements specifically targeting cloud service providers.

While the AGPL requires making source code available when software is used to provide a network service, the SSPL goes further by requiring service providers to release the source code for their entire service stack—including all programs used to make the software available as a service, such as management software, user interfaces, and orchestration tools.

The Open Source Initiative (OSI) has rejected the SSPL as an open source license, classifying it instead as a source-available license due to these expanded requirements.

Core Provisions of the SSPL

The SSPL largely follows the AGPL with one critical modification in Section 13, which states:

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. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

"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.

This expanded definition of what must be shared creates significant compliance requirements for anyone offering SSPL-licensed software as a service.

Origin and Adoption

MongoDB Inc. created the SSPL in response to cloud service providers offering MongoDB as a service without, in MongoDB's view, adequately contributing back to the project. MongoDB released version 4.0 of its database software under the SSPL in October 2018.

Other notable software that has adopted the SSPL includes:

• Elasticsearch (temporarily before moving to the Elastic License)
• Kibana (temporarily before moving to the Elastic License)
• Graylog (version 4.0 and later)

Comparison with Other Licenses

| License | Source Code Availability | Service Provider Requirements | OSI-Approved | |---------|-------------------------|------------------------------|--------------| | SSPL | Full access to source code | Must share entire service stack | No | | AGPL | Full access to source code | Must share modifications to covered code when offered as a service | Yes | | GPL | Full access to source code | Must share modifications only when distributing | Yes | | Commons Clause | Full access to source code | Restricts commercial use as a service | No | | Elastic License | Full access to source code | Prohibits offering as a managed service | No |

Impact on Software Supply Chains

The SSPL creates several significant considerations for software supply chains:

1. Service Offering Restrictions

Organizations must carefully evaluate whether their use of SSPL software constitutes "making the functionality available as a service" to third parties, as this triggers the expansive sharing requirements.

2. Stack Disclosure Requirements

The requirement to share source code for the entire service stack creates unprecedented compliance complexity, as it extends beyond the directly licensed software to supporting tooling.

3. Commercial Cloud Services

Commercial cloud providers have generally avoided offering SSPL-licensed software as managed services due to the requirement to open-source their management layers.

4. Dependency Implications

Using SSPL-licensed components as dependencies requires careful architecture decisions to avoid triggering service-related requirements.

License Compatibility Issues

The SSPL presents significant compatibility challenges:

1. Incompatibility with Open Source: As a non-OSI-approved license, the SSPL is not considered compatible with many open source licenses.

2. Copyleft Conflicts: The SSPL cannot be combined with GPL-licensed code in many scenarios due to conflicting requirements.

3. Contributor Agreements: Projects often require special contributor agreements to accept contributions under the SSPL.

4. Derivative Works: The extensive service stack disclosure requirements create ambiguity about what constitutes a derivative work.

SSPL Detection and Management

Identifying and managing SSPL-licensed software requires specialized approaches:

Detection Methods

1. License Text Scanning: Identifying the SSPL by its unique Section 13 text.

2. Package Metadata Analysis: Checking declared licenses in package metadata.

3. Release History Investigation: Some projects have changed to the SSPL in recent versions, requiring version-specific detection.

Compliance Considerations

When SSPL-licensed components are detected, organizations should consider:

1. Usage Pattern: Is the software being used internally only, or offered as a service?

2. Architectural Isolation: Can the SSPL component be isolated to minimize impact on other systems?

3. Alternative Components: Are there alternatively-licensed options available?

4. Commercial Licensing: Many SSPL projects offer commercial licenses that remove the service stack disclosure requirements.

Compliance Strategies for SSPL Software

Organizations using SSPL-licensed software should consider these approaches:

1. Internal Use Limitation

Use SSPL software only for internal applications not offered as a service to third parties, avoiding the service stack disclosure requirements.

2. Commercial Licensing

Obtain commercial licenses for SSPL software when using it as part of a service offering, typically available from the original creator.

3. Architectural Isolation

Isolate SSPL components architecturally to minimize their interaction with proprietary systems.

4. Alternative Adoption

Consider earlier versions of the software released under traditional open source licenses or fork projects from before the SSPL transition.

5. Contribution Strategy

If contributing to SSPL projects, understand the implications for your intellectual property and service offerings.

Community and Industry Perspectives

The SSPL has generated significant controversy in the software community:

Criticisms

• Overreach: Critics argue the service stack disclosure requirements go far beyond reasonable copyleft principles.
• OSI Rejection: The Open Source Initiative's rejection reinforces that the SSPL falls outside open source norms.
• Ambiguity: The definition of what constitutes making functionality available as a service creates legal uncertainty.
• Strategic Licensing: Some view the SSPL as primarily a business strategy to force commercial licensing rather than a genuine sharing model.

Support

• Sustainability: Supporters view it as necessary for sustaining development of software vulnerable to appropriation by cloud providers.
• Value Protection: It helps original creators protect the value of their work while still sharing source code.
• Cloud Era Adaptation: Some argue traditional open source licenses were not designed for cloud service delivery models.

Conclusion

The Server Side Public License represents a significant shift in the landscape of software licensing, particularly for database and infrastructure software commonly offered as cloud services. As neither fully open source nor traditionally proprietary, it creates unique challenges for software supply chain management.

Organizations must approach SSPL-licensed software with clear understanding of its extensive service-related requirements and implications. With proper license detection, usage analysis, and compliance strategies, companies can make informed decisions about incorporating SSPL components while managing the associated legal and operational risks.

As cloud services continue to dominate software delivery models, understanding and properly managing source-available licenses like the SSPL will remain an important aspect of software supply chain governance and risk management.