How to interpret the SSPL terms on licensing the service under SSPL?

Question

The SSPL as used by MongoDB is a license based on GPL, but not OSI-approved, thus programmes under that license would e.g. not fall under the topic of this community here.

Now, reading through the license it reads indeed very much similar to the GPL. The notable difference is, that for SaaS applications, you have to release basically the whole setup under SSPL (§13):

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

There's a very nice answer to the question I meant to aks originally on the differences between those licenses here.

Yet, in practical terms: How does that work cleanly for a service which makes use of different components, which are subject to different licenses which might be incompatible with SSPL? As an example it might feature a project development software like Redmine (license GPLv2) with MongoDB as backend. I definitely would have no permission to relicense the other 3rd-party packages and services which I didn't write myself and I use on a site. Is there any accepted take on this? Or is this (technically) putting the user at a legal risk, even when I provide source for my whole website and service?

Answer 1

Different licenses have different conditions. The GPL triggers requirements when distributing a covered work (in whole or in part, in modified or unmodified form). Additionally, the SSPL triggers requirements when offering the software as a service.

When using an SSPL-covered software as part of a software system, without offering this SSPL-covered software as a service to third parties, then §13 SSPL won't apply. A database that supports a web application – but is not directly accessible to users – is a typical example.

These two licenses do not affect other software (except per §13 SSPL). You can run SSPL- and GPL-licensed programs together, as long as they are clearly separate programs. Their license incompatibility would become an issue only when you trigger §13 SSPL, or when you combine SSPL- and GPL-covered parts into a single program and try to distribute the combined program.

MongoDB is correct in their argument that their switch to the SSPL will not have affected most users. However, it is still a non-Open license that (a) effectively makes certain uses impossible, and (b) has the unusual feature of potentially extending to unrelated software. The risk in the SSPL is that operators of the software must understand the impact of §13, as to not accidentally trigger this trap and land in a situation where compliance is literally impossible.