5 ms·

OSI lost touch with their mission. This SSPL license is clearly an open source license in the full spirit and original intent of open source. It is more aggress

by tinco 3y ago

OSI lost touch with their mission. This SSPL license is clearly an open source license in the full spirit and original intent of open source. It is more aggressively copyleft than AGPL is. Their reasoning[0] for not considering it open source is that due to the requirement that all interfacing software (my words) must also be open source it restricts the possible fields the software can be used in. Reread that sentence! that's exactly the intent of the original GPL license, and follows directly from the philosophy of its progenitor. If the original GPL was proposed today, then following this reasoning the OSI would not have approved it. Imagine today the Nginx project would switch its license from MIT to GPLv2. Just regular old GPLv2. Would the OSI also complain that previous contributors thought they were contributing towards the "greater good" and now their software is embedded in a proprietary product, just because nginx plugins now have to be open source as well? The OSI shouldn't be chasing some vague "greater good". They should be protecting the spirit of open source. Which includes copyleft licenses like GPL, AGPL and SSPL. [0] https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l...

redwood 3y ago
I think you have it right. Unfortunately much of the "OSI is OS" commentariat misunderstands the SSPL which aims to confer freedoms to use with no obligation from there (and even deliver as a public service where the machinery that does so is also made open source and hence free for others to use). If the OSI calls the AGPL open source, surely the SSPL is as well. A lot of people seem to lose the forest through the trees on "free as in freedom" vs "free as in beer" to the extent that copyleft offers a sustainable road to free as in freedom for the community... Unfortunately zealots have shot themselves in the foot without realizing they're doing the strip mining hyperscalers' bidding.
weinzierl 3y ago
If the SSPL is more aggressive than the AGPL why don't companies just adopt the AGPL. This is an honest question. I'm familiar with the AGPL but not with the SSPL and wondered before, why the AGPL is used so rarely.
- redwood 3y ago
  Because the AGPL left more ambiguous the scenarios where the user would be compelled the open source their work that used the AGPL licensed work: this unfortunately led many people and organizations to rule out the use of a AGPL software. Google and Amazon in particular are known to have these carte blanch rules in place. While an open source maximalist might be happy with that ambiguity, if it impedes the use of the software and hence the chance that a broader community of open source will thrive, it arguably backfires... SSPL aims to make explicitly clear that it is in context of building a public service for the software that the copy left provisions of an expectation of open sourcing occur. The theory is that this allows the software to be more widely used and for the community to benefit when a public service open source project is maintained
- bawolff 3y ago
  The goal of these license changes is to prevent people from selling Redis as a service essentially, in order to prevent them competing with the redis company's offerings. If it was AGPL, you would still be allowed to do that.
- blueelephanttea 3y ago
  MongoDB was AGPL. They decided it was not sufficient to prevent an Amazon hosted MongoDB offering so they went down the path of SSPL.
RobotToaster 3y ago
The problem is the entire stack has to be released under the SSPL. Which means if you want to offer it as a service, you can't use it on GNU/linux, since you don't have permission to release it under the SSPL. edited to add: this could easily be remedied by simply requiring the entire stack to be published under either the SSPL or an OSI/FSF approved license. Such a license (somewhat ironically) probably wouldn't be approved by the OSI/FSF, but it would solve the main issue with it. Although I also suspect the people using the SSPL consider this a "feature not a bug" of their psuedo-open-source licence.
- u320 3y ago
  How can it be used at all under SSPL then? There are no operating systems on which Redis runs that uses that license.
  - RobotToaster 3y ago
    You only need to do that if you operate it as a service that you sell or give away to others (rather than just running your own internal redis instance) So yes, this basically prohibits anyone but redis from operating it as a service, unless you write your own operating system for it to run on. (Although presumably they will sell you licences or similar to operate it as a service)
  - aragilar 3y ago
    That's why it's dual licensed.
  - bawolff 3y ago
    That's essentially why people think its not-free. In essence, it pretends to give you the right to do something, but puts impossible to meet requirements so that in pracitise you cannot do the thing. In essence, the license says you cannot use it as SASS software, but they didn't want to outright say that, so they did this instead.
  - cvalka 3y ago
    That's the point! It's impossible to comply with it. If it were an open source license, it'd require every component to be released under an open source license.
maffulli 3y ago
OSI executive director here: The SSPL was retracted from review (it was years ago) as the discussion on a mailing list stalled and became unproductive. Read the original threads on the list, not just that blog post. Frankly, it was a low point for the organization, the board at the time recognized it and that triggered a structural change[0], too. We've been thinking about how we'd discuss large and controversial licenses in a productive way. We're learning how to drive large, productive, difficult conversations with the process towards the Open Source AI Definition[1] and we hope (soon) to be able to transfer that knowledge to other pressing issues, like complex licenses. [0] https://opensource.org/blog/osi-executive-director https://opensource.org/blog/osi-executive-director [1] https://opensource.org/deepdive https://opensource.org/deepdive
- cipherboy 3y ago
  Does this also extend to the BUSL?
  - maffulli 3y ago
    I don't think anybody would argue that the BUSL is an open source license. OSI has investigated and released a report last year about the business practices similar to what the BUSL uses: https://opensource.org/delayed-open-source-publication https://opensource.org/delayed-open-source-publication
- tinco 3y ago
  Thank you, and it's great that it was recognised a structural change was needed inside and that they attracted you to help implement that. I understand there's deep and long threads on the mailing list, and that there are great flaws with the SSPL. That the communication with MongoDB crashed and left a sour after taste I can imagine. But the fact now is that there's a deeply flawed SSPL out there, OSI's only real public statement is very dismissive of it. It does not address at all the concerns of Elastic or MongoDB, painting them as some sort of bad guys, when in fact their products have always been open source, even when they were so valuable they really didn't need to be. And the companies that drove them away from what OSI considers open source, are OSI's two biggest sponsors! Two sponsors it is worth mentioning, who built their products entirely as proprietary closed software, on top of open source software. So now, wether they meant to or not, OSI has profiled themselves as defenders of proprietary platforms, making no effort to acknowledge the plight of open source companies, and lost credibility to such a degree that now again one the great open source companies has dismissed their approval and went for an unapproved license. If the OSI was really serious about the "greater good", they would have worked with the FSF and helped MongoDB, Elastic and Redislabs defend against proprietary platform companies such as AWS and Google with an AGPLv4 that has the provisions the SSPL introduced without causing the concerns other people raised in this thread with regard to (possibly intentional?) vagueness around what does and does not need to be open sourced. If that had happened, then maybe today Redislabs would have announced their switch to an OSI approved open source license, and the OSI would have retained its legitimacy and reputation. How many great budding open source/open core projects have been inspired by the success of Redis, MongoDB and Elastic, that now will consider the same path as these companies, or worse, that of Hashicorp?
deleted 3y ago
[deleted]
jimjag 3y ago
How a license which conflicts with the OSD can "clearly (be) an open source license in the full spirit and original intent of open source" is beyond me.
bawolff 3y ago
> OSI lost touch with their mission. Its hardly just the OSI. Debian, redhat, FSF all think this license is bad. > Their reasoning[0] for not considering it open source is that due to the requirement that all interfacing software (my words) must also be open source it restricts the possible fields the software can be used in. Reread that sentence! that's exactly the intent of the original GPL license, and follows directly from the philosophy of its progenitor. When they say "all", they really mean "all". The exact phrase is: " including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available." IANAL, and its not 100% clear, but i think this would prevent for example, using redis on a windows server because windows is not open source. What if the hard drive you are using has non-free firmware? Is that allowed? I don't know, but the fact its even a question seems ridiculous here. In essence, I think this clause is so burdensome, that nobody could realistically comply with it. Thus the license effective disallows that specific purpose. So I agree with OSI's assesment.
jrochkind1 3y ago
This keeps coming up, but I've been around for a while and I'm pretty sure that saying no restrictions on field of use was part of the "full spirit and original intent" of open source. Including the idea that you should be able to pay whoever you want to host a thing, without needing the permission of the authors to do so. While hosted things weren't common back then, the nearest analog is vendors selling you the thing (oh physical media, before widespread internet!), and that was always understood from the start as part of the full spirit and original intent of open source. That anyone could sell you the thing without license from the copyright holder. Readings from RMS one of the originators of the "full spirit and original intent" of open source are also pretty clear here -- that part of the full spirit and original intent is nobody can tell you what to do with the software or limit what you do with it -- including basing your business on it without license from the author. The fact that the OSI definition is what it is is also notable. It's not like the OSI definition/requirements/specification have _changed_, it's stayed the same for 25 years. And it was originally taken from Debian! If it didn't cover the original intent and spirit of open source, why weren't many people upset about it way back then? At what point did OSI "lose touch with their mission"... by... _not_ changing the 25-year-old requirements? The original spirit and intent of open source was never about supporting ways for authors monetize code -- quite the opposite. That doesn't mean you have to agree, you can have _different_ intent and spirit yourself, and it seems many people agree with you. You can think the original intent was always naive and a mistake. Or you can think times have changed and the original intent that may have worked at one point is not longer useful. But what you can't do is retroactively redefine the "original intent and full spirit" of open source.
- tinco 3y ago
  You went for an incorrect reading of my message, and then built an entire argument against that incorrect reading of that message, and then even went on to assume the people who seem to agree with me also follow that incorrect reading. Let me try to make my argument more clear. The spirit and intent of the original GPL is to use restrictions on the use of open source software, in such a way that it can only be modified and distributed and linked to other open source software that has the same provisions. This effectively limits the fields of use to companies that don't make money off proprietary software. This is the original intent of copyleft open source. Here is a quote from RMS himself: " Using a noncopyleft license is weak, and usually an inferior choice, but it's not wrong." In the 2000's however, it turned out that the GPL wasn't copyleft enough, because most software was offered as a networked service, and the GPL didn't affect this field of use strongly enough to effectively have the copyleft effect. So we got the AGPL, which extended the restrictions of copyleft to the networked software industry. And then in the 2010's it turned out that the AGPL wasn't copyleft enough, because big infrastructure builds proprietary platforms around AGPL software, and the restrictions of AGPL don't affect them as much. So that's where SSPL comes from. You might see it differently, but I think the SSPL follows this spirit.

by tinco 3y ago

redwood 3y ago

I think you have it right. Unfortunately much of the "OSI is OS" commentariat misunderstands the SSPL which aims to confer freedoms to use with no obligation from there (and even deliver as a public service where the machinery that does so is also made open source and hence free for others to use). If the OSI calls the AGPL open source, surely the SSPL is as well. A lot of people seem to lose the forest through the trees on "free as in freedom" vs "free as in beer" to the extent that copyleft offers a sustainable road to free as in freedom for the community... Unfortunately zealots have shot themselves in the foot without realizing they're doing the strip mining hyperscalers' bidding.

weinzierl 3y ago

If the SSPL is more aggressive than the AGPL why don't companies just adopt the AGPL. This is an honest question. I'm familiar with the AGPL but not with the SSPL and wondered before, why the AGPL is used so rarely.

redwood 3y ago
Because the AGPL left more ambiguous the scenarios where the user would be compelled the open source their work that used the AGPL licensed work: this unfortunately led many people and organizations to rule out the use of a AGPL software. Google and Amazon in particular are known to have these carte blanch rules in place. While an open source maximalist might be happy with that ambiguity, if it impedes the use of the software and hence the chance that a broader community of open source will thrive, it arguably backfires... SSPL aims to make explicitly clear that it is in context of building a public service for the software that the copy left provisions of an expectation of open sourcing occur. The theory is that this allows the software to be more widely used and for the community to benefit when a public service open source project is maintained
bawolff 3y ago
The goal of these license changes is to prevent people from selling Redis as a service essentially, in order to prevent them competing with the redis company's offerings. If it was AGPL, you would still be allowed to do that.
blueelephanttea 3y ago
MongoDB was AGPL. They decided it was not sufficient to prevent an Amazon hosted MongoDB offering so they went down the path of SSPL.

RobotToaster 3y ago

The problem is the entire stack has to be released under the SSPL. Which means if you want to offer it as a service, you can't use it on GNU/linux, since you don't have permission to release it under the SSPL. edited to add: this could easily be remedied by simply requiring the entire stack to be published under either the SSPL or an OSI/FSF approved license. Such a license (somewhat ironically) probably wouldn't be approved by the OSI/FSF, but it would solve the main issue with it. Although I also suspect the people using the SSPL consider this a "feature not a bug" of their psuedo-open-source licence.

u320 3y ago
How can it be used at all under SSPL then? There are no operating systems on which Redis runs that uses that license.
- RobotToaster 3y ago
  You only need to do that if you operate it as a service that you sell or give away to others (rather than just running your own internal redis instance) So yes, this basically prohibits anyone but redis from operating it as a service, unless you write your own operating system for it to run on. (Although presumably they will sell you licences or similar to operate it as a service)
- aragilar 3y ago
  That's why it's dual licensed.
- bawolff 3y ago
  That's essentially why people think its not-free. In essence, it pretends to give you the right to do something, but puts impossible to meet requirements so that in pracitise you cannot do the thing. In essence, the license says you cannot use it as SASS software, but they didn't want to outright say that, so they did this instead.
- cvalka 3y ago
  That's the point! It's impossible to comply with it. If it were an open source license, it'd require every component to be released under an open source license.

maffulli 3y ago

OSI executive director here: The SSPL was retracted from review (it was years ago) as the discussion on a mailing list stalled and became unproductive. Read the original threads on the list, not just that blog post. Frankly, it was a low point for the organization, the board at the time recognized it and that triggered a structural change[0], too. We've been thinking about how we'd discuss large and controversial licenses in a productive way. We're learning how to drive large, productive, difficult conversations with the process towards the Open Source AI Definition[1] and we hope (soon) to be able to transfer that knowledge to other pressing issues, like complex licenses. [0] https://opensource.org/blog/osi-executive-director https://opensource.org/blog/osi-executive-director [1] https://opensource.org/deepdive https://opensource.org/deepdive

cipherboy 3y ago
Does this also extend to the BUSL?
- maffulli 3y ago
  I don't think anybody would argue that the BUSL is an open source license. OSI has investigated and released a report last year about the business practices similar to what the BUSL uses: https://opensource.org/delayed-open-source-publication https://opensource.org/delayed-open-source-publication
tinco 3y ago
Thank you, and it's great that it was recognised a structural change was needed inside and that they attracted you to help implement that. I understand there's deep and long threads on the mailing list, and that there are great flaws with the SSPL. That the communication with MongoDB crashed and left a sour after taste I can imagine. But the fact now is that there's a deeply flawed SSPL out there, OSI's only real public statement is very dismissive of it. It does not address at all the concerns of Elastic or MongoDB, painting them as some sort of bad guys, when in fact their products have always been open source, even when they were so valuable they really didn't need to be. And the companies that drove them away from what OSI considers open source, are OSI's two biggest sponsors! Two sponsors it is worth mentioning, who built their products entirely as proprietary closed software, on top of open source software. So now, wether they meant to or not, OSI has profiled themselves as defenders of proprietary platforms, making no effort to acknowledge the plight of open source companies, and lost credibility to such a degree that now again one the great open source companies has dismissed their approval and went for an unapproved license. If the OSI was really serious about the "greater good", they would have worked with the FSF and helped MongoDB, Elastic and Redislabs defend against proprietary platform companies such as AWS and Google with an AGPLv4 that has the provisions the SSPL introduced without causing the concerns other people raised in this thread with regard to (possibly intentional?) vagueness around what does and does not need to be open sourced. If that had happened, then maybe today Redislabs would have announced their switch to an OSI approved open source license, and the OSI would have retained its legitimacy and reputation. How many great budding open source/open core projects have been inspired by the success of Redis, MongoDB and Elastic, that now will consider the same path as these companies, or worse, that of Hashicorp?

deleted 3y ago

[deleted]

jimjag 3y ago

How a license which conflicts with the OSD can "clearly (be) an open source license in the full spirit and original intent of open source" is beyond me.

bawolff 3y ago

> OSI lost touch with their mission. Its hardly just the OSI. Debian, redhat, FSF all think this license is bad. > Their reasoning[0] for not considering it open source is that due to the requirement that all interfacing software (my words) must also be open source it restricts the possible fields the software can be used in. Reread that sentence! that's exactly the intent of the original GPL license, and follows directly from the philosophy of its progenitor. When they say "all", they really mean "all". The exact phrase is: " including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available." IANAL, and its not 100% clear, but i think this would prevent for example, using redis on a windows server because windows is not open source. What if the hard drive you are using has non-free firmware? Is that allowed? I don't know, but the fact its even a question seems ridiculous here. In essence, I think this clause is so burdensome, that nobody could realistically comply with it. Thus the license effective disallows that specific purpose. So I agree with OSI's assesment.

jrochkind1 3y ago

This keeps coming up, but I've been around for a while and I'm pretty sure that saying no restrictions on field of use was part of the "full spirit and original intent" of open source. Including the idea that you should be able to pay whoever you want to host a thing, without needing the permission of the authors to do so. While hosted things weren't common back then, the nearest analog is vendors selling you the thing (oh physical media, before widespread internet!), and that was always understood from the start as part of the full spirit and original intent of open source. That anyone could sell you the thing without license from the copyright holder. Readings from RMS one of the originators of the "full spirit and original intent" of open source are also pretty clear here -- that part of the full spirit and original intent is nobody can tell you what to do with the software or limit what you do with it -- including basing your business on it without license from the author. The fact that the OSI definition is what it is is also notable. It's not like the OSI definition/requirements/specification have _changed_, it's stayed the same for 25 years. And it was originally taken from Debian! If it didn't cover the original intent and spirit of open source, why weren't many people upset about it way back then? At what point did OSI "lose touch with their mission"... by... _not_ changing the 25-year-old requirements? The original spirit and intent of open source was never about supporting ways for authors monetize code -- quite the opposite. That doesn't mean you have to agree, you can have _different_ intent and spirit yourself, and it seems many people agree with you. You can think the original intent was always naive and a mistake. Or you can think times have changed and the original intent that may have worked at one point is not longer useful. But what you can't do is retroactively redefine the "original intent and full spirit" of open source.

tinco 3y ago
You went for an incorrect reading of my message, and then built an entire argument against that incorrect reading of that message, and then even went on to assume the people who seem to agree with me also follow that incorrect reading. Let me try to make my argument more clear. The spirit and intent of the original GPL is to use restrictions on the use of open source software, in such a way that it can only be modified and distributed and linked to other open source software that has the same provisions. This effectively limits the fields of use to companies that don't make money off proprietary software. This is the original intent of copyleft open source. Here is a quote from RMS himself: " Using a noncopyleft license is weak, and usually an inferior choice, but it's not wrong." In the 2000's however, it turned out that the GPL wasn't copyleft enough, because most software was offered as a networked service, and the GPL didn't affect this field of use strongly enough to effectively have the copyleft effect. So we got the AGPL, which extended the restrictions of copyleft to the networked software industry. And then in the 2010's it turned out that the AGPL wasn't copyleft enough, because big infrastructure builds proprietary platforms around AGPL software, and the restrictions of AGPL don't affect them as much. So that's where SSPL comes from. You might see it differently, but I think the SSPL follows this spirit.