You can also use SSPL code to develop nuclear weapons and murder drones, as long as you publish the code! Additionally, you can also use SSPL code in a business offering that code as a service... as long as you publish all of the code for that service!
Oh. I've read more about SSPL and I actually like it. I don't see how it's not open source. I guess OSI, Red Hat and Debian know better than me, I'll have to check their reasoning. Though you are right that I don't see how it's fundamentally different from AGPL.
Thanks for correcting me!
>Specifically, this is discriminatory against users of the software that use proprietary software within their stack,
The difference between the AGPL and the SSPL is that while both relate to software which the end user interacts with over a network, the AGPL places no restrictions on what the software is used for, while the SSPL encumbers commercial SAAS.
This is a field of use restriction, and it is indeed the point of the SSPL! But field of use restrictions are disallowed under OSI's Open Source Definition — because it's critically important that Open Source software must be usable for any purpose to avoid uncertainty and exclusion, as explained elsethread [1].
You can't just keep claiming there's a field of use restriction when there isn't. It merely conveys a requirement for open sourcing dependencies required for operating services, an entirely noble copyleft behavior.
Any business which isn't exploiting open source in order to benefit proprietary source won't even be phased by this. It's simply a requirement to open source your stuff, which the OSI would support if supporting open source was actually their mission.
OK, I believe I understand the distinction you're making here.
I had to fight my way through your aspersions about the motivations of the people who take part in OSI license discussions, some of whom I am personally acquainted with. I consider the notion that they are driven by allegiance to Amazon and the like risible, although you don't have to take my word for it (and shouldn't, it's an argument from [negligible] authority).
The idea is that a "field-of-use restriction" should deny a license grant based on field-of-use, as opposed to granting a right to users to obtain source code based on field-of-use. This seems like a technicality when the obvious effect is to cripple commercial competition which some see as illegitimate and advantage certain other parties — something completely at odds with the idea that Open Source software needs to be available for any use, deeply cherished by myself and many other FOSS advocates.
For what it's worth, while I generally support, develop, and use open source software, I think "freedom 0" is somewhat problematic. Beyond the fact that I feel us doing labor to support the common good should not inherently require it be usable for corporate greed (I think a noncommercial license shouldn't be treated as a sin by the open source crowd), I think there's a sort of Paradox of Tolerance issue if you allow proprietary developers to compete directly with open source developers using their own code.
If we aren't able to say "hey, this is for open source use only", companies unburdened by ethics will always have a market advantage over ethical open source companies, and that in the long term will ensure open source doesn't win.
