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

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.