4 ms·

> AGPL does not restrict how you use the software, rather, it requires that you offer the same freedoms to your users as the original license offered to you. Y

> AGPL does not restrict how you use the software, rather, it requires that you offer the same freedoms to your users as the original license offered to you. You can sell AGPL'd software. But doesn't SSPL allow you to offer ElasticSearch-as-a-Service as long as you contribute the source code that makes it work? Many have commented on how that requirement is a no-go for AWS however they are not a priori forbidden by the license from doing so.

ddevault 6y ago
Elastic explicitly addresses the question of open source in their FAQ: https://www.elastic.co/pricing/faq/licensing#does-this-mean-that-elasticsearch-and-kibana-are-no-longer-open-source https://www.elastic.co/pricing/faq/licensing#does-this-mean-... Mongo has tried to get the OSI to approve it, but ultimately withdraw the license. The precise semantics of how much or how little the license diverges from the requirements of open source is an interesting topic for another time. For one, no other license, copyleft or otherwise, extends your obligations to software which is not actually a derivative work, which if nothing else requires a novel interpretation of the OSD. For now, though, I'd rather focus on the conclusion: this license does not qualify as open source, and that betrays those who choose to use or contribute to Elastic on the basis of its open source nature. They didn't get on board with the project in order to see how a dubious new license would hold up under scrutiny. This change was made for dubiously-justified commercial reasons on the false presumption that Elastic has the sole right to exploit Elasticsearch (and Kibana) for profit, software that they have shared ownership over (including in terms of copyright) with the broader community. They were allowed to do this, by the letter of the law, but it is fucked up regardless.
- fabianhjr 6y ago
  > For one, no other license, copyleft or otherwise, extends your obligations to software which is not actually a derivative work, which if nothing else requires a novel interpretation of the OSD. Copyfarleft[1] has been discussed for almost a decade now and has spinoffs like Copyfair[2]. > The precise semantics of how much or how little the license diverges from the requirements of open source is an interesting topic for another time. There is definitely a gray area there but the comment I originally replied to naively equated open source with the more permissive licenses. > They were allowed to do this, by the letter of the law, but it is fucked up regardless. I am not convinced that "it is fucked up". [1]: http://wiki.p2pfoundation.net/Copyfarleft http://wiki.p2pfoundation.net/Copyfarleft [2]: http://wiki.p2pfoundation.net/Copyfair http://wiki.p2pfoundation.net/Copyfair
  - ddevault 6y ago
    >Copyfarleft[1] has been discussed for almost a decade now and has spinoffs like Copyfair[2]. But not in the context of open source. At no point have any of these licenses made a successful bid for qualification under the OSD.
    - fabianhjr 6y ago
      The only criticism I would levy is that those licenses haven't been polished by time nor copyright-license-experienced lawyers. Their recognition from FSF/OSI is not their goal and and argumnt can be made that copyfarleft / copyfair pushes the boundaries of open/free/libre source software so they might not pursue recognition from the get go.
      - ddevault 6y ago
        I don't think that these licenses are relevant. If we can agree that they are not open source, then we can agree to the point I'm trying to make: changing from an open-source to a non-open-source license is a significant change which, when done without the consent of the community, is wrong.
        fabianhjr 6y ago
        I don't agree that they are not open source, I only agreed that it is a gray area and even on the previous comment mentioned that it is "pushing the boundaries". For eg, I maintain an "awesome-copyfarleft" list: https://github.com/LibreCybernetics/awesome-copyfarleft https://github.com/LibreCybernetics/awesome-copyfarleft > changing from an open-source to a non-open-source license is a significant change which, when done without the consent of the community, is wrong. I don't think consensus is possible and even a 2/3 supermajority on a license change seems out of reach. I can imagine some are pushing for permissive licenses like MIT/BSD, others for GPL/AGPL, others to remain as Apache 2.0, etc.
        ddevault 6y ago
rezonant 6y ago
Not forbidden, but SSPL goes beyond AGPL in a key way by defining the source that must be released as wider, including any code necessary to offer the covered code as a service, such as user interfaces, backup mechanisms, provisioning etc. That might indeed be more than AWS is willing to do
- 015a 6y ago
  Its also worth saying, at least in Mongo's case, AWS's managed offering (DocumentDB) is not, in any way except the API, MongoDB. Internally its based on Aurora. But, by my understanding, the SSPL also covers MongoDB's API, so this is why DocumentDB has not attained anything higher than 3.6 compatibility (and even its 3.6 compatibility is ish, but that's not for legal reasons by my understanding). Amazon definitely doesn't want to open source Aurora. Not only is it a massive moat for their cloud, its an extremely powerful database, but there's enough evidence to conclude that its so internal-AWS-reliant that it would be almost useless to anyone not running on AWS.
- fabianhjr 6y ago
  And by the other hand it is more lax on what must be open source in case of non-ElasticSearch-as-aService usage. So from my PoV it is overall more lax than AGPL. (Definitely more lax for non ElasticSearch-as-a-Service providers)
015a 6y ago
It does, in theory. But in practice, there are zero options for managed hosting of MongoDB 4.0+ outside of Atlas that I'm aware of (and we looked, everywhere). By my understanding, from speaking with some sales/product engineers at third-party companies which previously hosted MongoDB or currently host 3.6, the terms of the SSPL are so vague that its effectively a card that reads "you can host MongoDB, but if you become a threat to Mongo's business, we'll find a reason to sue you, and we'll win". So, no one does managed hosting anymore, or they're still on 3.6 with no intention of upgrading. Its possible that, if a hosting provider were to try and meet the terms of the SSPL, and succeed in doing that, and get some kind of validation of that success from Mongo or Elastic, then some form of precedent could be reached and that would increase confidence in the SSPL being defensible from a vendor standpoint. But, that never happened with Mongo. Maybe it'll happen with ES, given ES is far more popular.
- fabianhjr 6y ago
  Another possibility is that those managed hosting providers could obtain another license for Mongo. (Dual licensing between (A)GPL and a commercial license does happen, for example with Qt framework)

ddevault 6y ago

Elastic explicitly addresses the question of open source in their FAQ: https://www.elastic.co/pricing/faq/licensing#does-this-mean-that-elasticsearch-and-kibana-are-no-longer-open-source https://www.elastic.co/pricing/faq/licensing#does-this-mean-... Mongo has tried to get the OSI to approve it, but ultimately withdraw the license. The precise semantics of how much or how little the license diverges from the requirements of open source is an interesting topic for another time. For one, no other license, copyleft or otherwise, extends your obligations to software which is not actually a derivative work, which if nothing else requires a novel interpretation of the OSD. For now, though, I'd rather focus on the conclusion: this license does not qualify as open source, and that betrays those who choose to use or contribute to Elastic on the basis of its open source nature. They didn't get on board with the project in order to see how a dubious new license would hold up under scrutiny. This change was made for dubiously-justified commercial reasons on the false presumption that Elastic has the sole right to exploit Elasticsearch (and Kibana) for profit, software that they have shared ownership over (including in terms of copyright) with the broader community. They were allowed to do this, by the letter of the law, but it is fucked up regardless.

fabianhjr 6y ago
> For one, no other license, copyleft or otherwise, extends your obligations to software which is not actually a derivative work, which if nothing else requires a novel interpretation of the OSD. Copyfarleft[1] has been discussed for almost a decade now and has spinoffs like Copyfair[2]. > The precise semantics of how much or how little the license diverges from the requirements of open source is an interesting topic for another time. There is definitely a gray area there but the comment I originally replied to naively equated open source with the more permissive licenses. > They were allowed to do this, by the letter of the law, but it is fucked up regardless. I am not convinced that "it is fucked up". [1]: http://wiki.p2pfoundation.net/Copyfarleft http://wiki.p2pfoundation.net/Copyfarleft [2]: http://wiki.p2pfoundation.net/Copyfair http://wiki.p2pfoundation.net/Copyfair
- ddevault 6y ago
  >Copyfarleft[1] has been discussed for almost a decade now and has spinoffs like Copyfair[2]. But not in the context of open source. At no point have any of these licenses made a successful bid for qualification under the OSD.
  - fabianhjr 6y ago
    The only criticism I would levy is that those licenses haven't been polished by time nor copyright-license-experienced lawyers. Their recognition from FSF/OSI is not their goal and and argumnt can be made that copyfarleft / copyfair pushes the boundaries of open/free/libre source software so they might not pursue recognition from the get go.
    - ddevault 6y ago
      I don't think that these licenses are relevant. If we can agree that they are not open source, then we can agree to the point I'm trying to make: changing from an open-source to a non-open-source license is a significant change which, when done without the consent of the community, is wrong.
      - fabianhjr 6y ago
        I don't agree that they are not open source, I only agreed that it is a gray area and even on the previous comment mentioned that it is "pushing the boundaries". For eg, I maintain an "awesome-copyfarleft" list: https://github.com/LibreCybernetics/awesome-copyfarleft https://github.com/LibreCybernetics/awesome-copyfarleft > changing from an open-source to a non-open-source license is a significant change which, when done without the consent of the community, is wrong. I don't think consensus is possible and even a 2/3 supermajority on a license change seems out of reach. I can imagine some are pushing for permissive licenses like MIT/BSD, others for GPL/AGPL, others to remain as Apache 2.0, etc.
        ddevault 6y ago

rezonant 6y ago

Not forbidden, but SSPL goes beyond AGPL in a key way by defining the source that must be released as wider, including any code necessary to offer the covered code as a service, such as user interfaces, backup mechanisms, provisioning etc. That might indeed be more than AWS is willing to do

015a 6y ago
Its also worth saying, at least in Mongo's case, AWS's managed offering (DocumentDB) is not, in any way except the API, MongoDB. Internally its based on Aurora. But, by my understanding, the SSPL also covers MongoDB's API, so this is why DocumentDB has not attained anything higher than 3.6 compatibility (and even its 3.6 compatibility is ish, but that's not for legal reasons by my understanding). Amazon definitely doesn't want to open source Aurora. Not only is it a massive moat for their cloud, its an extremely powerful database, but there's enough evidence to conclude that its so internal-AWS-reliant that it would be almost useless to anyone not running on AWS.
fabianhjr 6y ago
And by the other hand it is more lax on what must be open source in case of non-ElasticSearch-as-aService usage. So from my PoV it is overall more lax than AGPL. (Definitely more lax for non ElasticSearch-as-a-Service providers)

015a 6y ago

It does, in theory. But in practice, there are zero options for managed hosting of MongoDB 4.0+ outside of Atlas that I'm aware of (and we looked, everywhere). By my understanding, from speaking with some sales/product engineers at third-party companies which previously hosted MongoDB or currently host 3.6, the terms of the SSPL are so vague that its effectively a card that reads "you can host MongoDB, but if you become a threat to Mongo's business, we'll find a reason to sue you, and we'll win". So, no one does managed hosting anymore, or they're still on 3.6 with no intention of upgrading. Its possible that, if a hosting provider were to try and meet the terms of the SSPL, and succeed in doing that, and get some kind of validation of that success from Mongo or Elastic, then some form of precedent could be reached and that would increase confidence in the SSPL being defensible from a vendor standpoint. But, that never happened with Mongo. Maybe it'll happen with ES, given ES is far more popular.

fabianhjr 6y ago
Another possibility is that those managed hosting providers could obtain another license for Mongo. (Dual licensing between (A)GPL and a commercial license does happen, for example with Qt framework)