SSPL is not a free license - Per Open Source Definition

Posted Sep 6, 2025 15:09 UTC (Sat) by immibis (subscriber, #105511)
In reply to: SSPL is not a free license - Per Open Source Definition by jjs
Parent article: Rug pulls, forks, and open-source feudalism

"interacts with" is completely different from "is distributed with"

SSPL is not a free license - Per Open Source Definition

Posted Sep 6, 2025 15:52 UTC (Sat) by pbonzini (subscriber, #60935) [Link]

"Interacts with" is not included in the license. Backup or monitoring software does not interact with the database, it's only used in the same system.

The discrimination against fields of endeavor is also at least plausible. The AGPL instead only extends the circumstances under which you shall provide the sources.

SSPL vs AGPL / Free Software / OSD / DFSG on what must be included

Posted Sep 6, 2025 18:38 UTC (Sat) by jjs (guest, #10315) [Link] (4 responses)

If I have a system tool that I use to monitor my SSPL licensed software, If I bundle my software into a distribution disk, all of it has to be Open Source, per the SSPL. Therefore, that tool needs to be released as Open Source, per the SSPL.

But, with AGPL, I can bundle a monitoring tool that interacts with my software only through defined APIs with my software, because, in accordance to the OSD, I don't need to have everything on the distribution Open Source. Only my "Corresponding Source Code" for my project.

OSD (https://opensource.org/osd) Clause 9:
"
9. License Must Not Restrict Other Software

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

AGPL (https://www.gnu.org/licenses/agpl-3.0.en.html) Clause 5:
"A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate."

Again, note here that I'm using the monitoring tool that connects via an API, that I am using to make the software service work for me to provide service to you. AGPL specifically excludes things that interact through an defined API (see clause 13 in the link above).

Check out clause 13 under https://webassets.mongodb.com/_com_assets/legal/SSPL-comp... where you can see the changes MongoDB made to the AGPL. My monitoring tool is specifically included in their license. So under the AGPL, I can use a commercial monitoring tool with my software and not have to provide it if I provide my program. Under SSPL, I have to provide it under an Open Source License. As a company, this puts restrictions on them that Free Software (OSD/Debian Free Software Guidelines/OSD) specifically forbid from being included.

SSPL vs AGPL / Free Software / OSD / DFSG on what must be included

Posted Sep 7, 2025 17:25 UTC (Sun) by immibis (subscriber, #105511) [Link] (3 responses)

> But, with AGPL, I can bundle a monitoring tool that interacts with my software only through defined APIs with my software

That - linking without linking - is exactly what the SSPL is meant to prevent.

Words have definitions. Definitions matter. Guidelines matter. But wanting doesn't mean having.

Posted Sep 8, 2025 2:40 UTC (Mon) by jjs (guest, #10315) [Link] (1 responses)

And is one of the reasons it fails - it contaminates unrelated software (guideline 9 of the OSD and guideline 9 of the Debian Free Software Guidelines - https://www.debian.org/social_contract#guidelines). As pointed out by someone else, since it specifically includes "hosting software" and if you host it on Microsoft Windows, you would be mandated to release the source code for MS Windows, which you don't own. Same with a backup program - suddenly I have to include my commercial backup software that I purchased from a commercial vendor under a commercial, non-free license.

"linking without linking" - Repeat that phrase a few times - "Doing A without doing A".

Linking in software has specific meaning. From CMU (https://csapp.cs.cmu.edu/2e/ch7-preview.pdf) "Linking is the process of collecting and combining various pieces of code and data into a single file that can
be loaded (copied) into memory and executed. Linking can be performed at compile time, when the source
code is translated into machine code, at load time, when the program is loaded into memory and executed
by the loader, and even at run time, by application programs."

How does a commercial backup software "link" to the software? If so, it does so with every piece of software on every system it backs up. How does a commercial monitoring software that uses defined APIs "link" to the software? How does running the software in a container on Microsoft Windows cause Windows to "Link" to the software? Per Section 13 of the SSPL, they all need to be distributed with the SSPL code. Define how each of them links, per the definition from CMU, to the software.

If I wrote the monitoring software BEFORE I encountered the SSPL software, made no changes to it, or even purchased it, I cannot redistributed the SSPL software (even unchanged) on a disk without including my monitoring software (which I have may not have the right to redistribute, because I didn't write it and control the license). Even though many programs may do the exact same thing. Even if I include some other program that does the exact same thing but is Open Source, I can't distribute because that software is not what I'm using. F/LOSS software does not contaminate other, unrelated software. SSPL does.

Short answer as to how they "link" (per the CMU definition above) - they don't.

Don't get me wrong. MongoDB owns the software. They can license it however they want. But that a) doesn't mean anyone else has to use that license, and b) that just because they want it to be considered an Open Source License that it is one.

BTW - still awaiting answer to:
"But they are a corrupt institution." (referring to OSI).

That's a serious allegation - feel free to provide verifiable evidence of that (and no, the fact that they have corporate sponsors doesn't make them corrupt. If it did, every non-profit in the world would be considered corrupt).

From Wex (https://www.law.cornell.edu/wex/corruption): "Corruption is the dishonest, fraudulent, or criminal use of entrusted authority or power for personal gain or other unlawful or unethical benefits. "

From the law dictionary of corruption (https://thelawdictionary.org/corruption/): "Illegality; a vicious and fraudulent intention to evade the prohibitions of the law. The act of an official or fiduciary person who unlawfully and wrongfully uses his station or character to procure some benefit for himself or for another person, contrary to duty and the rights of others."

I'd be very interested in seeing the verifiable evidence you have that they have committed such acts. I imagine legal authorities would be interested as well.

Corruption?

Posted Sep 8, 2025 5:17 UTC (Mon) by smurf (subscriber, #17840) [Link]

You can be corrupt, in the sense of violating the principles you're ostensibly holding up (in exchange of material or other gains), without actually going beyond the confines of your country's legal code.

That being said, I don't think OSI is. They may not always do what you and me would like them to do, their ideas about the free-ness of AI models are ample proof of that, but this by itself is neither necessary nor sufficient.

SSPL vs AGPL / Free Software / OSD / DFSG on what must be included

Posted Sep 8, 2025 10:00 UTC (Mon) by Wol (subscriber, #4433) [Link]

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

> That - linking without linking - is exactly what the SSPL is meant to prevent.

Which means that the SSPL is not a *COPYRIGHT* licence. The GPLv2 set out to be a *copyright* licence, which meant that it did not talk about anything other than copying, distribution and *LINKING*, because copyright only extends as far as derivation. And derivation is a legal concept, not anything the FSF/GPL have jurisdiction over.

The GPL v3 (and other licences) added patent law into the mix, which I personally think was a mistake.

The SSPL is now trying to add other stuff - over which it has absolutely no legal jurisdiction - into the mix. This effectively results in a licence where compliance is impossible, because it is demanding actions over which it has no lawful authority, and which (as other people have pointed out) are quite likely to be illegal.

Cheers,
Wol