5 ms·
Why write emotionally charged letter instead of one backed with facts? Amazon is claiming [1][2] that Elastic has been intentionally unclear about what part of
by amirathi 8y ago
Why write emotionally charged letter instead of one backed with facts? Amazon is claiming [1][2] that Elastic has been intentionally unclear about what part of Elastic stack is open source vs proprietary. It would best serve Elastic if they respond to that with facts.
If the claims are true, and done intentionally, it's a really bad move on part of Elastic. The ambiguity around licensing hurts all their users and not just Amazon.
[1] "Unfortunately, since June 2018, we have witnessed significant intermingling of proprietary code into the code base. While an Apache 2.0 licensed download is still available, there is an extreme lack of clarity as to what customers who care about open source are getting and what they can depend on. For example, neither release notes nor documentation make it clear what is open source and what is proprietary."
[2] "Individual code commits also increasingly contain both open source and proprietary code, making it very difficult for developers who want to only work on open source to contribute and participate"
- cik 8y agoI couldn't agree more with Amazon. We build something on Elastic - and trying to work with them to get licensing was at best a major PITA. In ~2017 Elastic decided they wanted to go Enterprise Only. They started to charge $100k for x-pack, though one could get a dev license for $50K. We quickly built a SQL parser for Elastic, an alerting engine, some other bits. These are all bits that just went poof yesterday when Amazon released opendistro - and I couldn't be happier. Sure we'll have to slice out a bunch of code, but at the end of the day it didn't have value to our core business. I just wish Elastic as a company was easier to deal with. We'd be months ahead if not for them - and ultimately just worked around them. This is in spite of MY using Elastic for ~9 years now.
- jillesvangurp 8y agoThis he said, she said style debate is indeed unproductive. If I read this correctly, Amazon tried to get a special deal from Elastic basically in order to produce a competing service. Elastic declined to cooperate and now Amazon is exercising their rights under the Apache license. So, far so good. It's the provocative website that makes it seem like there's some huge conspiracy by Elastic that provoked Shay Banon's response. And not the fact that Amazon are doing what they are doing (i.e. redistribute the OSS parts of Elasticsearch), Elastic seems to have little problems with this because their license allows this and as Shay points out others have done this as well. Amazon's complaints boil down to two things: 1) Elastic distributes a version of their software that includes non OSS components. You don't have to use these but you can. Actually Elastic offers rpms containing only the apache licensed components on their download page: https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html https://www.elastic.co/guide/en/elasticsearch/reference/curr.... So this is maybe a bit less true than Amazon is portraying here. This would be what you'd install on a server if you are self hosting. Likewise there are OSS docker images from Elastic. They also have oss docker images. Elastic does this because up-selling this stuff is how they make money. Amazon's beef seems to be that it would be awfully nice for them if they could offer an alternate distribution more prominently without all this stuff so that they give that to their own customers. 2) Their repository contains some well documented directories that contain non Apache licensed source code for these components. As far as I know this is pretty well documented and if you are modifying files in a directory, presumably you know what you are doing. This is because they want to develop most of this stuff in the open and be able to accept pull requests against both their OSS and non OSS stuff. This seems pragmatic and preferable to producing binary distributions with some components from private repositories. For reference, here's the text of the license file (https://github.com/elastic/elasticsearch/blob/master/LICENSE.txt https://github.com/elastic/elasticsearch/blob/master/LICENSE...): "Source code in this repository is variously licensed under the Apache License Version 2.0, an Apache compatible license, or the Elastic License. Outside of the "x-pack" folder, source code in a given file is licensed under the Apache License Version 2.0, unless otherwise noted at the beginning of the file or a LICENSE file present in the directory subtree declares a separate license. Within the "x-pack" folder, source code in a given file is licensed under the Elastic License, unless otherwise noted at the beginning of the file or a LICENSE file present in the directory subtree declares a separate license. The build produces two sets of binaries - one set that falls under the Elastic License and another set that falls under Apache License Version 2.0. The binaries that contain `-oss` in the artifact name are licensed under the Apache License Version 2.0." So, you might not agree with this arrangement but you can get or build pure OSS quite easily and many people do. And it is hard to argue against Apache 2.x here. The license pretty much makes it obvious how stuff is licensed. This is unsurprising. Any confusion here would be a legal bug; this stuff needs to be unambiguous and it seems to be. BTW. I think it is great that Amazon is providing their own distribution for their customers. It would be awfully nice though if they'd update it to the current version and not ship already fixed bugs. They have a history of doing this with Elasticsearch; probably because they are not on speaking terms with Elastic apparently. Contrary to the popular belief, this is not a fork. It's a binary distribution. Probably really convenient if you use their hosted version. Otherwise, get the latest and greatest from upstream. Also refer to the Elastic website for documentation because Amazon does not bother with this either. And go to their discussion forums and stackoverflow for free support and options for getting payed support, etc. Once you figure out that they are not doing a half bad job of that, go check out elastic cloud and use that. It's easier, better, faster, and cheaper and you can get it with AWS billing. Or if you prefer on other clouds or your own cloud. And yes, I have used both elastic cloud, aws elasticsearch and have done self hosting as well.
- ldubost 8y agoWhile as an open source software and company creator I highly connect to the emotional content of his response and feel the pain for Elastic when it comes to the competition by Amazon, I do agree that he does not address the factual issues at hand and uses badly the word "open" for stuff that is "shared source". One aspect Elastic is also not directly attacked on and therefore not addressing is the choice of features that are not free and the price point. Elastic's business model is quite smart. You can easily develop on top of elastic, however once you have done it and want to go to production some key features are missing and they are not cheap. Particularly securing your cluster data is one of the features in xpack which is problematic not to have. I'm pretty sure you can search for open ports 9200 over the internet or company intranets and find unwanted unprotected data. And it's not cheap as you need to go for Gold subscription if I'm correct. I would be surprised nobody has proposed a pull request with competing code. Elastic has and is investing a lot as open source and they do need a good business model that allows investment in the core open source code. The thing is I'm not sure it's missing here. Elastic.co is quite healthy. It's hard to know if it would be without this business model, but anyway there is little chance they would do differently given Elastic.co is VC backed. In the end the real fight is between the big money players, not about whether Elastic the software is sustainable. The reality is that given the community, it would very probably be even without the "xpack" package. Now it's not sure Elastic.co would be able to aggressively invest in both oss and non oss as much and therefore compete with Amazon. OSS is tough. When you go for it, you should go in it for OSS, not for the company, because keeping the company at the level of the OSS success is hard both for small and big OSS projects. Ludovic Dubost (XWiki)
- bragh 8y agoYou can put a reverse proxy in front of it to provide at least basic authentication measures and force HTTPS. Better than nothing at least. But the main problem is that unsecured clusters by default have caused a lot of reputation loss to the brand. When every few months news hit about yet another unsecured Elasticsearch cluster that leaked huge amounts of data, it is getting harder and harder to explain to the less informed how that is the fault of those people who did not even bother running a reverse proxy, not the fault of Elasticsearch itself.
- 8y ago