I make no claim that the SSPL is as easy to understand as the GPL. It's not. IMO the GPL's domain is such that it's easier for it to capture its intention succinctly. Do you link your software to this library? No? You're in the clear. You do? Then your software has to be released under the GPL.
The SSPL wants one thing: for people who make software available as a service to release their service stack under the SSPL. The problem is that defining "as a service" too narrowly makes it easy to circumvent. Imagine you used a really narrow definition, something along the lines of "running and managing an unmodified version of the software on behalf of someone.” It would be easy to add a single junk feature and get out of that obligation.
Every ambiguity you cite in the license is precisely crafted to thread that needle. Lawyers can certainly debate whether it was done so effectively, but the way I see it, we are looking at competing design goals: 1) embody the above licensing requirements, and 2) be easily comprehensible to laypeople. In a perfect world, these goals would not be in competition, but as we designed the SSPL, it was clear that they are.
The language you cite in your concern here is a good example of that:
>> or offering a service that accomplishes for users the primary purpose of the Software or modified version.
>Does not explicitly mention MongoDB, except by contrast implying that if we offer a service - even one not MongoDB-based - that accomplishes the primary purpose of MongoDB or a fork of it, then we're subject to the new terms.
At first glance, that last phrase "or offering a service that accomplishes for users the primary purpose of the Program or modified version" is an astounding overreach; it seemingly attempts to obligate you to release completely unrelated software under the SSPL just because it provides the licensed software's behavior. But the mere fact of a license's existence cannot obligate you to its terms; you have to use the licensed software. So it follows that the clause only affects you if your "unrelated" software is used to provide the same functionality as the licensed software that you are using in the service. I.e. you wrap the software in a clean-room implementation of a connecting driver and then build an external proxy that offers an identical API to the wrapped software but uses none of its code.
I hope that example at least makes clear that the language used in the SSPL doesn't introduce ambiguity for its own sake, or as a means to drive users to commercial licenses, it is a byproduct of the need to counter real-world means of circumventing its requirements.
>> offering a service the value of which entirely or primarily derives from the value of the Program or modified version,
>Explicitly calls out interacting with MongoDB. My company's website is basically a wrapper around accepting a query from a user, converting that into the appropriate NoSQL query, reformatting the result, and presenting it to the users. Since our web server is more or less an abstraction layer from the underlying database, it sounds like our whole website would be subject to the new terms.
Looking at the example of your company's website, I would say with complete certainty that it is not affected. You are not making that database's functionality available to anyone, and no matter how thin the functional layers are that you put on top of it, the value you provide doesn't derive primarily from the value the database provides.
Now, without implying that the SSPL is so perfectly crafted that it needs no refinement, I'd like to present this thought experiment:
If the area that the SSPL seeks to cover inherently means that its language has to be less straightforward, but if also it is shown to be legally sound and confined to the territory we claim it to be, then is it a worthy endeavor to pursue? If so, what constitutes "shown to be legally sound" etc.?
