5 ms·

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

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?
- PeterZaitsev 3y ago
  What I would rather see from OSI is defining Source Available licenses better. MongoDB, Elastic, Now Redis do not really provide the practical freedoms one comes to expect from Open Source software - it is clearly anti competitive by design which is bad for the use who will suffer bad quality and inflated prices as you always do when monopoly is created. Having said that Source Available Licenses are better for end user in many circumstances than old fashioned Proprietary licenses and spliting the world in black and white does not help
  - tinco 3y ago
    I'm not familiar with the Elastic ecosystem, but both MongoDB and Redis have a great plenty of competitors, many of which implement the same wire protocols even, that don't make use of their license at all. So I don't think symmetric competition is affected or even a concern of these companies. Symmetric competition still drives them to improve quality and pressure prices. It's the asymmetric competition from the platforms that's siphoning resources from these companies that could have been spent on improving the core product. I don't understand your point with regards to Source Available licenses. Sure, source available is beneficial to the end user, but what does that have to do with open source licenses and the OSI? Source available licenses are simply irrelevant. If source available licenses need representation there should be a new organisation formed for them, no need to involve the OSI. You could call it the Source Available Initiative.
    - compsciphd 3y ago
      The SSPL is more than just source available. Except for the anti-competitive poison pill in it, its effectively the same as rights granted under the GPL. It's just taking the GPL viral nature to its ultimate extent. As a simple thought experiment outside the cloud space (or in the pre cloud times) on how the GPL is just as "anti-competitive" I can release code as GPL. Lets assume either I am the only contributor to this code or I have a CLA allowing me extra rights to the code. In that case, only I have the right to use that GPLd code in a closed source product. That's fundamentally not any more "anti-competitive" or "discriminatory" than the SSPL. Just like the GPL would have allow you to use my code in your commercial product shipped to customers, as long as you GPLd the entire code base (which many might find untenable), so to the SSPL allows you to use a "service" oriented code base, as long as you open source the entire service structure that delivers your version of the service to the end user. As I wrote above, its mostly a question on values and how one emotionally reacts to those values than simple logic. As the arguments made against the SSPL (or at least a theoretically more perfect SSPL type license, as the emotionally arguments against the SSPL have created an environment where there has been no desire to improve it) really apply just as equally to the GPL.
compsciphd 3y ago
To quote wikipedia on the SSPL Certification with OSI "In 2018, MongoDB submitted the license to the Open Source Initiative (OSI) for approval. The company withdrew its submission in 2019.[19][20] In January 2021, following the re-licensing move by Elastic, OSI released a statement declaring that the SSPL does not comply with its Open Source Definition because it discriminates against specific fields of endeavor,[which?] describing it as a "fauxpen" source license.[7]" wikipedia links to https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l... So it would seem your take is not quite accurate. It's not simply that it was withdrawn, the OSI board of directors has made public statements. I'd note that the argument made above "discriminating against specific fields of endeavor" is not fundamentally different than other viral copyleft licenses. While it has a big poison pill, the whole point of viral copyleft statements is about having a poison pill. The GPL arguably discriminates against fields of endeavor (i.e. closed source code, actually preventing it). The SSPL discriminates against cloud service providers by having a poison pill, which in theory, actually discriminates less, as that field is allowed to use it, just the requirements to use it might be to onerous to be reasonable. But there should be no logical difference if its just about "discriminating against specific fields of endeavor". i.e. it comes down to a value/emotional statement vs a pure logic statement. The value is that cloud providers need to be allowed to use the code without severe restriction, while its ok to prevent closed source products from using the code. It's fine for the OSI to make decisions that are not purely logical, but are simply about trying to protect the values that they want to push, but they should also be honest about it.

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?

PeterZaitsev 3y ago
What I would rather see from OSI is defining Source Available licenses better. MongoDB, Elastic, Now Redis do not really provide the practical freedoms one comes to expect from Open Source software - it is clearly anti competitive by design which is bad for the use who will suffer bad quality and inflated prices as you always do when monopoly is created. Having said that Source Available Licenses are better for end user in many circumstances than old fashioned Proprietary licenses and spliting the world in black and white does not help
- tinco 3y ago
  I'm not familiar with the Elastic ecosystem, but both MongoDB and Redis have a great plenty of competitors, many of which implement the same wire protocols even, that don't make use of their license at all. So I don't think symmetric competition is affected or even a concern of these companies. Symmetric competition still drives them to improve quality and pressure prices. It's the asymmetric competition from the platforms that's siphoning resources from these companies that could have been spent on improving the core product. I don't understand your point with regards to Source Available licenses. Sure, source available is beneficial to the end user, but what does that have to do with open source licenses and the OSI? Source available licenses are simply irrelevant. If source available licenses need representation there should be a new organisation formed for them, no need to involve the OSI. You could call it the Source Available Initiative.
  - compsciphd 3y ago
    The SSPL is more than just source available. Except for the anti-competitive poison pill in it, its effectively the same as rights granted under the GPL. It's just taking the GPL viral nature to its ultimate extent. As a simple thought experiment outside the cloud space (or in the pre cloud times) on how the GPL is just as "anti-competitive" I can release code as GPL. Lets assume either I am the only contributor to this code or I have a CLA allowing me extra rights to the code. In that case, only I have the right to use that GPLd code in a closed source product. That's fundamentally not any more "anti-competitive" or "discriminatory" than the SSPL. Just like the GPL would have allow you to use my code in your commercial product shipped to customers, as long as you GPLd the entire code base (which many might find untenable), so to the SSPL allows you to use a "service" oriented code base, as long as you open source the entire service structure that delivers your version of the service to the end user. As I wrote above, its mostly a question on values and how one emotionally reacts to those values than simple logic. As the arguments made against the SSPL (or at least a theoretically more perfect SSPL type license, as the emotionally arguments against the SSPL have created an environment where there has been no desire to improve it) really apply just as equally to the GPL.

compsciphd 3y ago

To quote wikipedia on the SSPL Certification with OSI "In 2018, MongoDB submitted the license to the Open Source Initiative (OSI) for approval. The company withdrew its submission in 2019.[19][20] In January 2021, following the re-licensing move by Elastic, OSI released a statement declaring that the SSPL does not comply with its Open Source Definition because it discriminates against specific fields of endeavor,[which?] describing it as a "fauxpen" source license.[7]" wikipedia links to https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l... So it would seem your take is not quite accurate. It's not simply that it was withdrawn, the OSI board of directors has made public statements. I'd note that the argument made above "discriminating against specific fields of endeavor" is not fundamentally different than other viral copyleft licenses. While it has a big poison pill, the whole point of viral copyleft statements is about having a poison pill. The GPL arguably discriminates against fields of endeavor (i.e. closed source code, actually preventing it). The SSPL discriminates against cloud service providers by having a poison pill, which in theory, actually discriminates less, as that field is allowed to use it, just the requirements to use it might be to onerous to be reasonable. But there should be no logical difference if its just about "discriminating against specific fields of endeavor". i.e. it comes down to a value/emotional statement vs a pure logic statement. The value is that cloud providers need to be allowed to use the code without severe restriction, while its ok to prevent closed source products from using the code. It's fine for the OSI to make decisions that are not purely logical, but are simply about trying to protect the values that they want to push, but they should also be honest about it.