Elasticsearch does not belong to Elastic
drewdevault.com
drewdevault.com
Elastic's changing their license. No contributions are being stripped of their open source license. You always have the last open source licensed version to go back to and fork if you like.
What this author is upset about is that Elastic are no longer providing updates under a license the author feels they are entitled to.
Maybe the author should fork the project and maintain it under an open license themselves?
Turns out, AWS is more user and FOSS-friendly than the "open source company" which created the software in the first place. A surprising twist.
I would say Google's approach of partnering with maintainers instead of competing with them is healthier, though only just.
To wit, it's an "open-source business" providing the open source software people apparently feel very strongly about, not a "community volunteer project without the pressure".
When I think about OSS databases for example I can't think of any widely used ones that don't have at least one commercial entity that provides maintenance and support which funds development.
The incentives and existential threats towards the project are completely different.
You want some guarantee that AWS, Google, or Elastic will treat the OSS community right. That guarantee doesn't exist. People bought in to Elastic's "guarantee" on this front years ago, and that did not pay off. There's no such thing as a model that stands the test of time; there's only today. Does it solve your problems? Is it licensed in a way that preserves the freedom of its users and maintainers? Is there recourse if that changes?
Open source in a business context is built on the premise of several suppliers competing on the same product. I can't help but notice that the increased competition made the product severely less neutered, as Amazon did publish their Elastic distribution as open source just as the model prescribes, and this put pressure on Elastic to reduce some on the limitations from theirs. No Tivoization seemed to have taken place.
While partnering would have been much better for Elastic, I'm not sure Google would have done it better in this case.
Doesn't matter who has contributed to the project - whoever they are they own rights to keep the code base open and licensed open, but they don't own the name or the trademark rights. It would be well within Elastic's rights to change the name on the repo.
Remember the whole Docker/Moby thing?
Don't get me wrong. It would be great if Elastic, Redis and co didn't have to do this (change license) but AWS does pose an existential threat to their business models long term. I'd rather a standardised, so there's less fear around interpretations, more restrictive license than the businesses and _future_ ones becoming unviable.
Important detail: Drew seems to be taking his own medicine and has been doing so for years.
The point of open source wasn't to enable viable business models for companies like Elastic. The ASL is commercial-friendly, but the design of the license wasn't to enable any specific business model. It was to ensure the widest range of freedoms.
A lot is made of the way Amazon is "taking advantage" of the license, but they aren't. They're doing exactly what is allowed, what anyone is allowed.
IMHO, if you're releasing your work under an ASL-like license, then you're making a specific promise to the community about the freedoms related to your code. You're making a promise to all the adopters and contributors. The license is a promise (literally a contract) about what to expect from each other so that we can all contribute on the project together.
When an actor unilaterally changes that agreement, it's understandable some may be upset.
And while I know it's trendy of HN to discount non-profits like Apache as out of touch or old-school, they serve an important function in the open source ecosystem. As a non-profit, Apache doesn't really care too much what Amazon or any big or small tech company does with the code, as long as the original code remains open source and there is a community that can continue to work on it. The continuation of the community is paramount, above and beyond any one company's business model. We want software, particularly internet middleware, to be stable and last for generations.
When we take a long term view for the health of the interview, Elastic's move is great for Elastic, but not for the internet as a whole. Consider where we'll be if/when Elastic collapses. Right now, Elastic has plenty of fans, but we have no guarantee that they will remain competent, competitive, and innovative over time. If their hosted service suffers, their new license ensures that no one else can compete.
The advantage of broadly supported open source projects is that they can out last any one company (e.g. Sun) or any one person, so that we can build a technical commons for the future.
The first is source /must/ be available and /modifiable/; on that all proponents of FOSS are agreed; exactly for the reasons you've stated.
The second is that we want /more/ FOSS software; not less. How we achieve that is essentially where people differ. The issue with big companies which contribute nothing or very little back to the ecosystem is the tragedy of the commons. Eventually, the number of people working on FOSS will dwindle and we won't /have/ FOSS alternatives or communities.
For the record, I don't even think that AWS are the worst offenders. I've worked at places which refused to even contribute bug reports or patches to upstream systems.
It would seem to me that this would lead to less open source, not more.
Here is the clause for reference:
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.
What was being argued was that it was ethically wrong of Amazon to engage in this business without some sort of blessing from (and, one would imagine, revenue sharing with) the original developers. Under that argument, their misdoing isn't releasing too little, but doing the work in the first place.
Something like the AGPL can absolutely be a tool for more FOSS in the world. But I think there was two things being argued here.
Elastic is also not "taking advantage" of the license. Apache License 2.0 can be combined for example with GPLv3 or as in this case Server Side Public License. This is the freedom that Apache License 2.0 provides. Both companies do what they are allowed to do under the license.
You may not like the freedoms that Apache 2.0 provides, but then you should not contribute to projects under that license. GPLv3 does not grant you the freedom to easily change license terms, so probably you should contribute to projects with that license or similar.
> If their hosted service suffers, their new license ensures that no one else can compete.
How does it ensure that no one can compete? If you release the infrastructure code you can compete.
I should perhaps do a bit better clarifying between:
a) The code
b) The community
The issue is more that the open source work had been happening under the support and auspices of Elastic with a certain license. Elastic is relicensing and the rest of the community is within rights to not want to support Elastic's now non-open source fork.
I would love to know whether these quazi-open licenses will be considered successful for the companies that switch to them. There's a short term cost here, in creating market confusion and fragmentation and general uncertainty - the potential benefits can only be realized down the road, a few years once the dust has settled and the offering has enough compelling improvements to what AWS gives. Are those benefits real?
My intuition is that, if you consider yourself in the business of competing against an Amazon hosted version of your own software, you've already lost. Amazon will destroy you in the end, regardless of whether they can directly use your code or whether they need to implement their own alternative (either from scratch or based on a different solution on a different OSS product).
To me, this sort of license change kind of reads as desperation.
So if I understand this right: Elasticsearch was under the Apache 2.0 license, which, contrary to FOSS-licensed (GPL and co.), allows derivatives to be under a different license. Now they changed to a proprietary source-available license, because Amazon.
If that is true, then I don't understand this: Contributors that have contributed to an open-source Apache 2.0 licensed project should have understood, that contributing to such a project means that they don't have the same protections to their work as with a FOSS project and that big companies can just take your contributions and give nothing in return.
The point is not that they couldn't do this, but that it's a dick move which betrays the trust of their community, and is ultimately harmful to the goals of open source.
I understand that a re-licensing to proprietary from upstream it self is really annoying and hurtful to the open-source project itself. However the only distinction of upstream doing this with a CLA and somebody else is that upstream can reuse use the project name, infrastructure, etc.
Or are there any other consequences of upstream doing this vs. someone else?
It could also be the beginning of something new: See OpenOffice vs. LibreOffice.
Yep: the community is built around the upstream project, and has a lot invested in their continued existence as an open source entity. This move will force the community to start from scratch to build a new entity which continues to meet those guarantees - something Elastic plans to capitalize on by capturing more users on its paid offering while the open source community struggles to set up a new entity at the same level of sophistication from scratch.
The community is not without options, but that doesn't change the fact that what Elastic has done is wrong.
Note: HN has been rate limiting me rather strictly today, so I'm losing my ability to keep up with this discussion. Sorry.
Ok, that was what I meant with 'upstream can reuse use the project name, infrastructure, etc.'. Probably a very big 'etc.' here.
So your point is more about that the contributors and the community helped build the brand and recognition of ElasticSearch, which is now, taken away from them.
That is a fair critique, IMO.
However, that Elastic as upstream of the project suddenly disappears for the community, I find is something, that unfortunately, many open source projects have to go through sooner or later.
and the software itself. Elasticsearch accepts patches from the public, albiet accompanied by a signature on the CLA that grants Elastic unfettered rights to do anything they want with the code.
>However, that Elastic as upstream of the project suddenly disappears for the community, I find is something, that unfortunately, many open source projects have to go through sooner or later.
Maybe, but it still doesn't make it right. This wasn't an accident, or the consequence of a company gradually succumbing to attrition. It was deliberately done for the profit motive in an already profitable company, and excused away with gaslighting and misinformation. This is why I chose to criticize them on my blog.
Often when licenses change, the old versions of the repositories, that are still under the old license are still available. Isn't that the case here as well?
Granted, employees of Elastic, might have unknowingly written code that is now under a proprietary license. But code of most other external contributors should still be under the APL2.0, right?
> Maybe, but it still doesn't make it right. This wasn't an accident, or the consequence of a company gradually succumbing to attrition. It was deliberately done for the profit motive in an already profitable company, and excused away with gaslighting and misinformation.
You are blaming a for-profit company for making supposedly for-profit decisions, which is nothing new. If you could show that their actions where dictated by short term greed (which is mismanagement in a for profit company), then this argument would bite more IMO.
A good argument for your critique is also their press release, where they try to explain 'nothing has changed' while in fact the license has.
> This is why I chose to criticize them on my blog.
Of course its a very annoying situation and IMO you are right in criticize them for causing it.
You clearly do not like certain permissive licenses and you should contribute only to projects that have licenses similar to GPLv3.
Take it as a lesson for the future, because this is not the first time that company exercises their rights to the fullest and not the last time.
The author clearly does not like freedoms provided by MIT, Apache, BSD and similar licenses.
No. Copyright prohibits you from changing the license on copyrighted code. Do some licenses allow binary redistribution? Sure. Do Some licenses allow source redistribution? Sure.
Can you include Apache 2.0 licensed code in a GPL project? Yes. But you can't change the original license for the code.
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.
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)
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.
First of all while there are so many contributors the vast majority of commits seem to be by elastic team members.
Secondly, elastic provides a lot more than just the code.
Third, they're a for profit company and have been from the beginning.
So with all of that in mind to me the change seemed perfectly reasonable.
Materially it doesn't really change much for anyone other than Amazon.
Last year CockroachDB did the exact same thing and I don't recall anywhere near the outrage. Perhaps it might be because it's significantly less popular but everyone out on their soap boxes now surely should have been making noise then as well.
Furthermore, a lot of these arguments seem to be very black and white. You either are or aren't open source. Surely there are shades. Surely the OSI definition isn't the only one. Surely being able to contribute, modify and run for your own purposes still counts for something.
It really is the case that everyone wants OSS but no one wants to pay for it.
They should contribute to projects whose licenses do not allow changing terms of the license easily. That's it.
It's just if you try to sell ES as a service, then you gotta provide your changes to the public.
Doesn't this sound a bit like AGPL?
For a non-lawyer that seems very sketchy... I could understand that people would need some legal advice for that, to understand this stuff in detail...
That isn't sufficient to be "Open Source". That's more of "Source Available" or "Shared Source" or something.
So while the source isn’t closed as in “you can’t read it anymore” it is not open as in the typical understanding of the words “open source”.
And before anybody says it - yes, we all know that OSI doesn't have a registered trademark on "Open Source." Doesn't matter. We're talking about a de-facto definition, not de-jure. And among people who actually care about the definition of "Open Source" the OSD is the de-facto definition.
The "license update (that) prohibits making a service that directly sells Elasticsearch" is what makes the new license not Open Source.
Call it whatever you like, but it's not "pragmatic FOSS", it's not "FOSS" at all. It is neither free (by the FSF's definition, which goes back to at least 1986), nor open source (by the definition first published in 1998, derived from the DFSG published in 1997).
> for the real world
The "real world" in which Elastic's revenues, as the article points out, were $427 million last year. And please don't use this cheap rhetorical trick wherein anyone with different priorities must get back to the "real world" (defined loosely as "whatever I say it is").
Source? I don't remember the url, but the other day someone posted a link to an opinion posted by someone at OSI back when Elastic was thinking of getting certification that basically said: "This licence would probably satisify the OSI defintion, but it's a bad license because it's too vague and you should use the AGPL-3 instead".
> but it's a bad license because it's too vague
That has historically[1] been a reason for the free & open source communities to reject licenses; nobody wants cavernous uncertainties about what you can and cannot do under a license's terms.
[0] https://www.elastic.co/blog/license-change-clarification
[1] See, e.g., why the FSF rejected the original Artistic License. https://www.gnu.org/licenses/license-list.en.html#ArtisticLi...
It worked really well, but as our query rate increased, our queries' geographic component, which we would search using Elastic's geohashing, created high CPU usage on our cluster. We soon learned the CPU demands for each query were significantly higher compared to more traditional full-text search queries.
Elastic simply had no way to allow us to optimize for CPU heavy workloads in their hosted product. We talked with their product team and engineers, and they were good, and promised they were working on it, but ultimately my team needed to move to a hosted solution that offered better instance selection so we could optimize for our particular workload while keeping costs under control. So, we moved to AWS. This required navigating some weirdness with request signing, but overall worked great.
While I'm sure the hosting issues have since been addressed, this lesson taught me that the licensing of the software impacts my ability as an engineer to find alternative hosts with a variety of hosting and pricing models, and this move to a more restrictive license will likely add friction for those providers that will reduce the number of companies that will offer hosted Elasticsearch. I think this is a material practical concern.
It does leave an open question about how to fund open source, which is also a practical concern. It's probably another discussion, but I have a hunch that rather than forcing third-parties to open source their hosting stack, it makes more sense for the open-source business to make their hosting stack proprietary (Elastic's already is, IIRC), and provide an awesome developer experience with the hosted product, so hosting providers can compete on the SaaS experience and share the underlying open-source product. Just a hunch, though.
If I fork the commit before license change, rename everything to not clash with trademarks, can I then pick commits from their repo into my still-Apache licensed forks?
EDIT: Can I use SSPL licensed software in my commercial server-side application for free?
And if I remember correctly from some other similar case, picking a commit might create a new version which is then entirely under the new licence.
IANAL either though.
To give the story a bit more context, I always felt that Elastic built on Lucene without giving much back.
And, while Lucene is not the standard for clarity itself, the open source code of Elastic is very hard to understand and it has very few comments, AFAIR. It did not feel like the core team was proudly sharing.
>To give the story a bit more context, I always felt that Elastic built on Lucene without giving much back.
I would love to understand why you have this perspective? Investing in and contributing to Lucene is a core part of the Elasticsearch team. We contribute more to Lucene than any other organization, some of our employees are amongst the top committers, and several of our employees are members of the Lucene PMC. We give back to and [celebrate][0] Lucene openly. We love Lucene.
Disclaimer: I am an engineer on the Elasticsearch team; I welcome any and all feedback.