The Server Side Public License lets you run the program freely, but section 13 changes the deal if you offer it to third parties as a service. You must then release the Service Source Code under the SSPL. That covers the program and the software you use to run the service around it.
What triggers section 13
Section 13 applies when you make the program, or a modified version, available to third parties as a service. The license text describes this as users interacting with its functionality remotely over a network, where the value of the service comes entirely or primarily from the program, or where the service accomplishes the program's primary purpose.
Running the program for your own internal needs is a different case. Section 2 says you may run the unmodified program, and make and run covered works you do not convey, without conditions, as long as your license stays in force. Section 13 is the main limit on running it as a service for others.
What you would have to release
This is the part that surprises people. Service Source Code means the Corresponding Source for the program, plus the Corresponding Source for all other programs you use to make it available as a service. The license lists management, user interface, API, automation, monitoring, backup, storage and hosting software as examples.
The practical test the text gives is whether a user could run an instance of your service using the source you released. That is a much wider net than the network clause in the AGPL, which asks only for the source of your modified version.
Where SSPL shows up in an inventory
Most teams meet it as a dependency or infrastructure component, not as something they chose to build on. A database, a search engine or a cache may carry it. The questions to ask are narrow:
- Do we offer this component to customers as part of a hosted product, or only use it behind our own application?
- If customers reach it directly, is it the primary value of what we sell?
- Have we modified it?
If the honest answer to the first question is that it only sits behind your own application, section 13 is unlikely to be the center of the discussion, but that is a legal judgement. Put the question to counsel and write down the answer.
OSI status and why it matters to a policy
The Open Source Definition forbids discrimination against fields of endeavor. Many organizations treat the SSPL as source available rather than open source for that reason, and their license policies list it separately from approved open source licenses. Check the current position of the Open Source Initiative yourself before you quote it, since I did not confirm an approval status from a primary page for this post.
What to put in your license policy
Treat SSPL as a review required license. Record which component carries it, how you use it, whether it is modified, and who approved the use. Revisit when the usage changes, for example when an internal tool becomes a customer facing feature.
Safeguard generates SBOMs and scans dependencies, which gives you the component list that this review starts from. There is a free scan at gold.safeguard.sh/scan. It does not replace a legal reading of the license.
Quick check
Does using an SSPL database behind my own SaaS trigger section 13?
Section 13 is aimed at offering the program itself as a service to third parties. Whether your use counts depends on the facts, so get a legal review and keep the decision on file.
Does section 13 cover only the modified program?
No. It covers the Corresponding Source of the program and of the other programs you use to run the service, such as monitoring, backup and hosting software.
Sources
This post is general information, not legal advice.
Last reviewed: 19 October 2026.
