A couple of misconceptions about open distro that Amazon seems to be advertising to overstate what they are doing:
1) It's not a fork. There's no such thing as an Amazon specific fork of the Elasticsearch git repo in the opendistro github account. There are no Amazon specific patches to Elasticsearch.
2) Instead, Amazon redistributes a vanilla OSS build of Elastic. As is and unmodified. Producing these builds is and always has been a feature of the elasticsearch build scripts. With every release they produce OSS binaries and OSS docker containers (both without the closed source plugins) in addition to the ones that include their x-pack components. All Amazon does is take those builds and bundle their own OSS plugins.
3) What is and is not open source is clearly documented in the Elastic repository. There is zero ambiguity here (legal or otherwise) unlike what Amazon implies in their marketing. If it's in the x-pack directory, it may be closed sourced (some plugins are OSS). If that bothers you, use the before mentioned OSS builds. Everything outside the x-pack directory is OSS. OSS here qualifies as Apache 2.0 licensed or compatible. It's that simple.
The OSS plugins that amazon provides are of course nice if you need them. Less nice is that they seem to be perpetually several releases behind Elastic with both the plugins and opendistro. So if you use this, you are running with known & fixed bugs that may or may not affect you. You could argue that Amazon maybe does a lot of testing. If so, those tests don't appear to be part of their OSS repos. The other explanation is of course that they only update their cloud service a couple of times a year and simply ignore bug-fixes or even patch releases to what they shipped, other fixes and improvements that happen upstream, etc. Or even any documentation for that (refer to the Elastic official release notes and documentation for what was actually fixed). If these bugs happen to affect you, you are on your own. The release notes are "whatever Elastic said a few months ago". Refer to the Amazon release notes here if you don't believe me: https://opendistro.github.io/for-elasticsearch-docs/version-.... The last few releases were basically "bump the version number" and absolutely nothing else that Amazon considered worth reporting.
So, if you are comfortable running that in production use it at your own peril. I'd argue it's probably better to take the latest Elastic oss build, fork the amazon plugins you actually need (if any) and simply bump the version numbers to match the current elastic version. Amazon seems to do little more than that between releases; so you are not really missing out on any meaningful QA, support, or other stuff Amazon implies they are doing that they are clearly not doing.
> 3) What is and is not open source is clearly documented in the Elastic repository. There is zero ambiguity here (legal or otherwise) unlike what Amazon implies in their marketing. If it's in the x-pack directory, it may be closed sourced (some plugins are OSS). If that bothers you, use the before mentioned OSS builds. Everything outside the x-pack directory is OSS. OSS here qualifies as Apache 2.0 licensed or compatible. It's that simple.
While this statement is true, it is not clearly documented in their actual documentation! For many years the pricing model around X-Pack was incredibly opaque and the documentation did everything possible to encourage you to use it while keeping the warnings around licensing issues were buried deep in the appendices.
I certainly didn't read elasticsearch's source tree when learning how to operate it -- I started in the docs like most everyone else.
Also, your super responsible sysadmins probably aren't pulling elastic's source code to run on your servers, they're using the distro packages (which do mix free and non-free) which is also what the docs tell you to do.
They've long addressed all of that. There are helpful x-pack tags on the documentation for features that aren't in the OSS release. Check here for example on the documentation page for index life cycle management: https://www.elastic.co/guide/en/elasticsearch/reference/curr...
The pricing model for their platinum features is indeed opaque (as in most small companies can't afford this, and you'd have to talk to a sales rep to find out). Those features are also clearly marked. X-pack features are free to use. Also, if you try to use these features without the proper license key, it won't work for obvious reasons. There's zero risk of using this accidentally without first agreeing to some license.
Also, each single source file includes details on how it is licensed. There's zero chance of a developer not seeing that if they are preparing some code patch. This is intentional; it's not optional to document stuff like this if you are serious about enforcing your copyright; which of course they are.
Sysadmins pulling elasticsearch from a linux distro repo of course happens. Presumably they'd be getting an OSS build and not bundle proprietary components because they tend to care about not shipping proprietary code. If you go to the Elastic download pages, there are convenient links to both.
1) It's not a fork. There's no such thing as an Amazon specific fork of the Elasticsearch git repo in the opendistro github account. There are no Amazon specific patches to Elasticsearch.
2) Instead, Amazon redistributes a vanilla OSS build of Elastic. As is and unmodified. Producing these builds is and always has been a feature of the elasticsearch build scripts. With every release they produce OSS binaries and OSS docker containers (both without the closed source plugins) in addition to the ones that include their x-pack components. All Amazon does is take those builds and bundle their own OSS plugins.
3) What is and is not open source is clearly documented in the Elastic repository. There is zero ambiguity here (legal or otherwise) unlike what Amazon implies in their marketing. If it's in the x-pack directory, it may be closed sourced (some plugins are OSS). If that bothers you, use the before mentioned OSS builds. Everything outside the x-pack directory is OSS. OSS here qualifies as Apache 2.0 licensed or compatible. It's that simple.
The OSS plugins that amazon provides are of course nice if you need them. Less nice is that they seem to be perpetually several releases behind Elastic with both the plugins and opendistro. So if you use this, you are running with known & fixed bugs that may or may not affect you. You could argue that Amazon maybe does a lot of testing. If so, those tests don't appear to be part of their OSS repos. The other explanation is of course that they only update their cloud service a couple of times a year and simply ignore bug-fixes or even patch releases to what they shipped, other fixes and improvements that happen upstream, etc. Or even any documentation for that (refer to the Elastic official release notes and documentation for what was actually fixed). If these bugs happen to affect you, you are on your own. The release notes are "whatever Elastic said a few months ago". Refer to the Amazon release notes here if you don't believe me: https://opendistro.github.io/for-elasticsearch-docs/version-.... The last few releases were basically "bump the version number" and absolutely nothing else that Amazon considered worth reporting.
So, if you are comfortable running that in production use it at your own peril. I'd argue it's probably better to take the latest Elastic oss build, fork the amazon plugins you actually need (if any) and simply bump the version numbers to match the current elastic version. Amazon seems to do little more than that between releases; so you are not really missing out on any meaningful QA, support, or other stuff Amazon implies they are doing that they are clearly not doing.