5 ms·

> The reason SSPL is not OSI approved is because Amazon pays an entire OSI staff salary a year and the SSPL costs Amazon money. This is slanderous nonsense. S

> The reason SSPL is not OSI approved is because Amazon pays an entire OSI staff salary a year and the SSPL costs Amazon money. This is slanderous nonsense. SSPL is not OSI-approved because field-of-use restrictions are not compatible with the Open Source Definition, clause 6. https://opensource.org/osd#fields-of-endeavor https://opensource.org/osd#fields-of-endeavor > 6. No Discrimination Against Fields of Endeavor > The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. Here's the decision: https://web.archive.org/web/20230411163802/https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003977.html https://web.archive.org/web/20230411163802/https://lists.ope...

ocdtrekkie 2y ago
I've read the arguments, but those arguments apply equally to the AGPL, which would not be approved by the OSI today. SSPL has no field of use restrictions, it simply has restrictions that require viral open sourcing. And there's nothing slanderous about pointing out that, yeah, Amazon pays out a significant portion of the OSI's entire operating budget. (edit: Actually FWIW, Amazon is apparently not currently on the Sponsors page... maybe they didn't renew this year. But they used to be at the top.)
- poincaredisk 2y ago
  >I've read the arguments, but those arguments apply equally to the AGPL How? You can use AGPL code to develop nuclear weapons and murder drones, as long as you publish the code.
  - ocdtrekkie 2y ago
    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!
    - deleted 2y ago
      [deleted]
    - poincaredisk 2y ago
      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, (From wikipedia) That's... the point.
      - rectang 2y ago
        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]. [1] https://news.ycombinator.com/item?id=41691577#41694133 https://news.ycombinator.com/item?id=41691577#41694133
        ocdtrekkie 2y ago
        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.
        rectang 2y ago
        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.
Pannoniae 2y ago
ladies and gentlemen, this is a perfect example of the word-by-word interpretation I was talking about in another subthread:) The SSPL is a perfectly sensible license, the only thing it does wrong is to stop SaaS exploitation of software. As the GP said, the OSI is mostly funded by hyperscalers, it's in their vested interests to keep the status quo. Field-of-use restrictions are certainly a useful tool in fighting open source exploitation, and the blanket disallowal of them just plays into the hands of Amazon and whatnot, allowing them to massively profit off everyone else's work. Also, note that the OSI doesn't even follow their own definition by the letter! I quote, Section 13 is very obviously intended to be a restriction against the field of endeavor of offering the software as a service, and thus not in compliance with OSD #6. I don't see how you can change this while maintaining the intent of your license, which is indeed to specifically encumber vendors other than MongoDB who engage in that field of endeavor. So they are basically arguing that a restriction in the license is intended to stop hyperscalers, not that it actually restricts the usage of software in any field! The conflict of interest is blatantly obvious here...
- rectang 2y ago
  > So they are basically arguing that a restriction in the license is intended to stop hyperscalers, not that it actually restricts the usage of software in any field! Stopping hyperscalers is restricting usage in a field. The primary reason that field-of-use restrictions are part of the OSD is to avoid excluding anyone from the community, and also to avoid fights about whether anyone belongs. Historically, military uses were often excluded in certain licenses — but just what constituted military use could be very hard to determine and potentially could result in endless litigation. Dual-use technology, anyone? The same reasoning applies to hyperscaling. If you allow any restrictions on field of use in "Open Source", then a fundamental guarantee that countless users of OSS have been counting on goes up in smoke. Before, it was software that anyone could use for any purpose. But now, everyone has to wonder, "am I actually allowed to use this Open Source Software"? I firmly agree with these arguments, and I'm glad that the OSI continues to be intellectually and morally consistent in applying them — despite your asserting that they must be corrupt to do so.
xigoi 2y ago
Wouldn’t the GPL also violate this clause because you’re not allowed to use a GPL-licensed program for developing proprietary software?
- froh 2y ago
  the gcc very clearly states it can be used to create proprietary software. always has. the same goes for anything LGPL licensed, but I'd be surprised if you count that as GPL ;-)

ocdtrekkie 2y ago

I've read the arguments, but those arguments apply equally to the AGPL, which would not be approved by the OSI today. SSPL has no field of use restrictions, it simply has restrictions that require viral open sourcing. And there's nothing slanderous about pointing out that, yeah, Amazon pays out a significant portion of the OSI's entire operating budget. (edit: Actually FWIW, Amazon is apparently not currently on the Sponsors page... maybe they didn't renew this year. But they used to be at the top.)

poincaredisk 2y ago
>I've read the arguments, but those arguments apply equally to the AGPL How? You can use AGPL code to develop nuclear weapons and murder drones, as long as you publish the code.
- ocdtrekkie 2y ago
  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!
  - deleted 2y ago
    [deleted]
  - poincaredisk 2y ago
    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, (From wikipedia) That's... the point.
    - rectang 2y ago
      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]. [1] https://news.ycombinator.com/item?id=41691577#41694133 https://news.ycombinator.com/item?id=41691577#41694133
      - ocdtrekkie 2y ago
        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.
        rectang 2y ago
        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.

Pannoniae 2y ago

ladies and gentlemen, this is a perfect example of the word-by-word interpretation I was talking about in another subthread:) The SSPL is a perfectly sensible license, the only thing it does wrong is to stop SaaS exploitation of software. As the GP said, the OSI is mostly funded by hyperscalers, it's in their vested interests to keep the status quo. Field-of-use restrictions are certainly a useful tool in fighting open source exploitation, and the blanket disallowal of them just plays into the hands of Amazon and whatnot, allowing them to massively profit off everyone else's work. Also, note that the OSI doesn't even follow their own definition by the letter! I quote, Section 13 is very obviously intended to be a restriction against the field of endeavor of offering the software as a service, and thus not in compliance with OSD #6. I don't see how you can change this while maintaining the intent of your license, which is indeed to specifically encumber vendors other than MongoDB who engage in that field of endeavor. So they are basically arguing that a restriction in the license is intended to stop hyperscalers, not that it actually restricts the usage of software in any field! The conflict of interest is blatantly obvious here...

rectang 2y ago
> So they are basically arguing that a restriction in the license is intended to stop hyperscalers, not that it actually restricts the usage of software in any field! Stopping hyperscalers is restricting usage in a field. The primary reason that field-of-use restrictions are part of the OSD is to avoid excluding anyone from the community, and also to avoid fights about whether anyone belongs. Historically, military uses were often excluded in certain licenses — but just what constituted military use could be very hard to determine and potentially could result in endless litigation. Dual-use technology, anyone? The same reasoning applies to hyperscaling. If you allow any restrictions on field of use in "Open Source", then a fundamental guarantee that countless users of OSS have been counting on goes up in smoke. Before, it was software that anyone could use for any purpose. But now, everyone has to wonder, "am I actually allowed to use this Open Source Software"? I firmly agree with these arguments, and I'm glad that the OSI continues to be intellectually and morally consistent in applying them — despite your asserting that they must be corrupt to do so.

xigoi 2y ago

Wouldn’t the GPL also violate this clause because you’re not allowed to use a GPL-licensed program for developing proprietary software?

froh 2y ago
the gcc very clearly states it can be used to create proprietary software. always has. the same goes for anything LGPL licensed, but I'd be surprised if you count that as GPL ;-)