Those posts are a mere re-statement of the conclusion, not the reasoning that led to it. 1. The OSI definition applies to the license itself, not the company's

Those posts are a mere re-statement of the conclusion, not the reasoning that led to it. 1. The OSI definition applies to the license itself, not the company's motivations for its use, so that point is irrelevant. 2. I do not see how point 9 amounts to a restriction, for four reasons: a. The "other software" is packaged together as a service by the company offering the service, not by the SSPL. The SSPL, in other words, recognizes what already exists. It does not create a new thing. b. The example given by OSI relates to other unrelated programs simply sharing the same media. The SSPL targets programs that are bound together to provide a service. GPLs already recognize linking, for instance, so how does this not apply as a different kind of linking? It's merely happening at the next layer up. c. Open source is not a restriction - it is the opposite of a restriction. The entire point of free software licenses is to, as the preamble of the GPLs say, "guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users". It beggars belief that integration of a program into a packaged product, modified for and made available over the network, should override that protection. If the SSPL is not "open source" for this reason, then neither is the AGPL. d. Legal ambiguity is not a reflection on the open-source-ness of the license. All FOSS licenses are "ambiguous" until tested in court multiple times.