[btown]

This is incredibly user-hostile, and if you read this expecting this is an open-source release, consider yourself clickbaited.

Want to contribute to the open-source version of Elasticsearch? Want to ensure you're running an open-source database without running a custom EULA past your legal department?

Well, make sure that after 6.3 is released, you don't accidentally download the default distribution, or browse the official Github repository, or clone from Github, as all of those will have components subject to an as-yet-unreleased, non-OSI-approved EULA (see the final paragraph in https://www.elastic.co/products/x-pack/open), which may have clauses that trigger liability to Elastic if you accidentally flip a switch or look at the wrong thing. (I am not a lawyer, this is not legal advice, but I shouldn't have to be to know if I can use software freely, and I can only guess worst-case scenarios because the terms aren't released.)

If Elastic were truly committed to transparency, they would release the terms of their new EULA immediately, provide a way to access the head of the open-source portion of the repository without accepting the EULA, and make it clear what the pricing ramifications are if one opts into certain flags or reads certain files in a commercial capacity. (Pricing requires a custom quote, but a quick Google search suggests that the lowest tier in which REST and node-to-node communications are encrypted begins in the tens of thousands of dollars - not the kind of thing you want to take lightly.)

Now more than ever, it's important that projects like https://github.com/floragunncom/search-guard , a free and open-source (Apache 2.0) alternative to some of these X-Pack components, are supported, and that the word is spread around them. (EDIT: Yes, they have commercial components, but those are in a separate repository, so you avoid any entanglements. Why isn't Elastic doing the same?)

And hopefully, if Elastic doesn't maintain a fully-OSS repo, someone will create and maintain a friendly fully-OSS fork that can be combined with third-party software to carry on the legacy of this otherwise excellent database in the right way.

[tylerhannan]

One of the awesome things about our products is that people care deeply about them. There is one thing, in particular, I want to address.

'If Elastic were truly committed to transparency, they would release the terms of their new Eula immediately...'

We are working on it. This change is not one that was taken lightly and we have to ensure we have the right language for when we do release the license, etc. We will put it online as soon as we are able.

We are committed to transparency and, also, we are committed to our users.

Yes, we are asking for a fair bit of trust...and I hope we continue to prove ourselves worthy of that trust.

<disclaimer: I work at Elastic in Developer Relations>

[Xylakant]

Sorry if the following sounds like a personal rant: it is.

You're saying that people care deeply about your product. In reverse, I don't get a feeling you care much about the community around your products. Since you're working at developer relations, I'd like to point out that you're still funneling people to your IRC channels via https://www.elastic.co/community, but once people arrive there, they barely get any help from elastic people. Despite multiple requests, the channels are still not logged or searchable, so questions get asked over and over again. I'm a long-time lurker there and especially questions about how to contribute to the projects end up in silence. People asking how to work on tickets (in the tickets) as part of a university course or as part of a Gsoc assignment: silence.

There's barely anyone offering guidance on how to contribute to the open source project beyond "you'll need to sign the CLA." The CLA is contributor-hostile. Anything people touch as part of their work cannot be contributed unless they get legal involved - a show stopper for many. The CLA, at least in some versions required full copyright assignment and indemnification - I, personally, can say that it stopped me from providing any kind of fixes or improvements.

I used to run the Berlin elasticsearch usergroup which started out before elastic, the company, even existed. At some point it used to be one of the largest ES UGs world-wide, still, any kind of support from elastic beyond personal support from some developers: nonexistant. Heads up and infos for feature announcements so that we could prep a talk fitting the announcement: Not there. Sending a speaker for an announcement? Impossible. At some point, elastic even tried to charge us for the privilege of running a UG. The best offer we received was an offer to pay for pizza. We did get a honorable mention at the first elasticon, IIRC.

> Yes, we are asking for a fair bit of trust...and I hope we continue to prove ourselves worthy of that trust.

Good luck. I've heard these words before. Any kind of interaction with elastic, the company, that I had as a community member was borderline hostile. I wish things would improve, but I've pretty much lost faith.

[kawsper]

I have lost faith as well, but in my case it might just be that Elastic are working on too many integrations, or that Rails is just not a priority for them, but the official elasticsearch-rails gem is set to support ES6.0 by Q2 or Q3 in 2018[0], remember that Elasticsearch 6.0 was released November, 2017.

[0] https://github.com/elastic/elasticsearch-rails/issues/756

[rdsubhas]

On the other hand,

Their discourse community is very active. ElasticSearch people help out there a lot. They are people in the end, and they can't be everywhere. They are spread thin and they do their best. Open source doesn't mean super human. Lack of resources doesn't mean "hostile". If you think not being able to respond is hostile, then wait till you really see the hostile part of the world.

For everything ElasticSearch does, this is a very critical and negative outlook.

[Xylakant]

> They are people in the end, and they can't be everywhere.

I agree, but they mention IRC as an official contact and support channel. Either do that and then support it, or don't. But you can't say "you can get help on IRC" and then not be there, that just does not work. People do actually come to the channel and expect answers and they do treat volunteers there like they're paid support staff - an expectation that is understandable given that it's listed on the official page.

> Lack of resources doesn't mean "hostile".

No, but I didn't say so. I said the interactions were borderline hostile. I won't recount the episodes here, though, but generally they were about asking us to go out of our way to organize things and then drop the ball. If you ask me to do stuff for you for free, then you'd better follow through. Lack of resources is no longer an excuse then.

[mayya]

yes, indeed. Discourse would be a good place to ask questions. We can't answer all questions, especially long "did I design my domain indexes correctly", but we strive to help and answer questions about Elastic.

[telchar]

Since I have an ear here, I have to say I hope the EULA doesn't require arbitration in Delaware like the Basic license does. These sort of terms make this a no-go for us - same as when Atlassian required mandatory arbitration in (New Zealand?); out lawyers refused to let us use JIRA because of that, and other clauses in their license.

I'm about to uninstall x-pack for the same reason. Hopefully we can use the 6.3 release, but it will depend on the terms.

[jeeyoungk]

Agreed. I can't believe how combining Apache and non-apache licensed source code in a single repository is a good thing.

[nkoothrappahli]

If you look for real FOSS ES security i recommend Search Guard https://github.com/floragunncom/search-guard . This is a ASL2 licensed repo which provide all kinds of basic security for Elasticsearch including SSL/TLS. So the content in this repo are real fully "open source".

Then there is a second non-FOSS repository https://github.com/floragunncom/search-guard-enterprise-modu... which contains all the enterprise/advanced stuff. The code is open but not "open source".

So FOSS and and non-FOSS/proprietary are well separated. I don't understand why elastic mix and merge FOSS and non-FOSS code in the same repo with a weird mixed license applicable for special folders. This all makes no sense to me.

And there are several other FOSS projects which provide x-pack like functionalities described here https://sematext.com/blog/x-pack-alternatives/ like elastalert for alerting or sentinl for reporting.

If one is really comitted and addicted to FOSS then i believe its better to go with the FOSS x-pack alternatives and support and contribute to them.

Just my 2c.

[softwaredoug]

So a developer could make substantive contributions to XPack, but still owe Elastic money when they deploy to prod?

[nkoothrappahli]

Thats exactly why it will not work

[lnx01]

Here is the EULA: https://www.elastic.co/eula