It seems more likely that people were using Elastic because it works well and is free, not because it's open source. Still, companies are indeed their own best friends first and friends of their customers and employees second.
Any license which restricts a user's ability to use the software how they wish is no open source license. And the OSI has so far supported this; the SSPL is not an OSI approved license, despite being submitted for approval by MongoDB then retracted a year later.
That's the thing though. The only thing (from my naive understanding) that SSPL limits is a business (Like Amazon) from offering Elasticsearch as a service. If an organization (Like Amazon) wanted to use Elasticsearch internally (to say, power some part of their shopping platform), they are free to do so with this license.
It's essentially protecting Elastic's business model, which quite honestly, should be the bare minimum offered by any open source product.
Furthermore, if you change a project which is open source, to a licensing model which is not, it's a dick move.
It's not important if the needs of the business are "reasonable", we could argue about that but it's beside the point. Open source has no relationship with the requirements of your business. It has a specific meaning, and if you betray those principles, you betray the people who trusted you on those terms.
https://www.wikiwand.com/en/Source-available_software
> Any license which restricts a user's ability to use the software how they wish is no open source license.
Then is AGPL not open source? It has requirments/restrictions on modified privative usage/distribution.
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.
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.
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.
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".
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.
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.
> 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.
Sorry, you are simply wrong on this matter. It's not a subjective issue, it s a statement of fact that these licenses are not open source. There was a recent attempt to change this within the OSI, which badly failed.
>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.
Correct. That doesn't mean that they can choose to change the license anyway. That means that changing the license is not right in the first place.
Under Apache 2.0 and as they did retaining the contributions as Apache 2.0 they can though. As far as I have seen there havent been any legal challenges to the licensing change on this comment section.
> That means that changing the license is not right in the first place.
This is a non sequitur though, the premise that precedes it (that "they can't change the license (legally or under the terms of Apache 2.0)") is false.
> That doesn't mean that they can choose to change the license anyway.
Do you have anything else to add?
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.
So from my PoV it is overall more lax than AGPL. (Definitely more lax for non ElasticSearch-as-a-Service providers)