Elasticsearch and Kibana are now business risks | Hacker News Reader

Elasticsearch and Kibana are now business risks

anonymoushash.vmbrasseur.com

94 pointsvmbrasseur22 comments

The main thread on this is https://news.ycombinator.com/item?id=25776657. It was off the front page for a while because of the flamewar detector but I've turned that off (false positive).

I've merged most of the comments thither. The ones that only make sense in the current article's context should probably stay here.

> By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. It’s not a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal

This seems to be an issue of people not being able to figure out what the license actually would imply if challenged in court.

I think this is a fair argument, at that point, even a full on proprietary license where you ha e to pay to use ElasticSearch and Kibanna might be seems as less risky by business lawyers.

Now, I'm not a lawyer, but this makes me wonder how is "law" supposed to handle scenarios like this? Is law at a point that even reading the license terms that you agree with isn't good enough to know what you're agreeing too?

Isn't law supposed to be about agreeing to things ahead of time so there is no surprises? So what's failing here?

I think there is a breakdown between how lawyers (and, perhaps courts - but none of this is really tried in court so that remains to be seen) interpret what software engineers mean when they say things because there is a lot of nuance to capture.

One can imagine the client going to their lawyers and spending a hefty amount of money for them to produce the SSPL license in a good spirit, but coming out with something like this which is ambiguous and weighted in favor of the SSPL provider (Elasticsearch, etc.) because when there is ambiguity lawyers tend to prefer ambiguity in favor of their client, not the other party.

She's saying it's not a stretch to interpret it in such a way. So there wouldn't be any surprises. This is the paragraph he's talking about:

> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

IANAL, but I agree with the assessment that this means all the way to the bare metal. If you're running te Elastic on Windows or some other proprietary OS, this will be a problem for you.

In any case, that's not the problematic part of the SSPL, everyone runs on open source infrastructure anyway. The real problematic part is this paragraph:

> 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 Program or modified version.

This one needs a judge to set the boundaries. The last sentence is long and a bit complex, but the vague part is this: "offering a service the value of which entirely or primarily derives from the value of the Program or modified version". A charitable reading suggests the intent is to target only those services that offer no value but the value of Elastic itself. For example if you run a website that let's a user sort through a bunch of documents that are stored in Elastic, then the "primary" value probably lies in the documents that you have gathered for your users. But the line is not so clear when the user supplies the documents as well. I'm pretty sure in that last case there is no way a judge would not conclude the primary value is that of Elastic.

So yeah, that's a business risk, is your business just a clever packaging of Elastic, or is Elastic just the icing on the value you're delivering to your customers? Would a judge agree with that assessment? Better have your expensive IT staff explain that to your expensive lawyer team.

He is not a he. He is a she.

Ah my apologies.

That does seem a little concerning. You're right, it seems that there can be a debate on the case where you are a SaaS, for someone to say that the value of your SaaS is all in its use of ElasticSearch, in which case you'd need to release all your code publicly and open source, so basically make your entire SaaS open source as well under SSPL.

So it seems like a copyleft license in some way, where usage of Elastic could result in you having to publish your source under SSPL as well. But it's extreme in that it's not just your changes to the ElasticSearch source, but your entire stack.

Honestly, I feel maybe ElasticSearch just doesn't want proprietary companies using it anymore. Either those need to use their ElasticSearch managed service or the Amazon one, or they need to themselves become an SSPL open source solution.

This seems like someone with a ideological bone to pick. You don't need to opensource your software that uses their products.

They link this article of their's at the bottom:

https://anonymoushash.vmbrasseur.com/2019/06/07/the-problem-...

This tells you everything about their stance:

"If these companies actually cared about the projects, they would have invested the resources to build stronger communities around them. They would have reached out to Amazon, encouraged them to contribute back to the projects, and helped them to do so."

They're very pro AWS.

> They're very pro AWS.

The author point of view is unbelievable. It's AWS here that's basically "stealing" others work to resell it. But to the author Elastic should have reached out AWS and encouraged them to contribute back. The author didn't even consider that AWS should have stepped up way earlier and offered to contribute/pay back themselves.

What? For years I've been trying to get my teams to start using Elasticsearch and Kibana.

For any project that relies on logging data and events, ES is a godsend. You can log file system changes with filebeat, process logs from a distributed system, transform logs, monitor hardware, etc. etc. and it's fast. I love it.

This license just makes it impossible for me to recommend it now. I don't care if it's supposed to strangle some corpos, it's now a no-go for small startups.

EDIT: It seems that I might be wrong about this? The article is just alarmist bs?

I think you misunderstood the article. Only businesses like AWS that exploit FOSS to repackage it for profit should be concerned by this license.

If you use it internally to store and analyze metrics/logs/whatever, than you're fine as you where before.

Edit: The problem is the article itself that does a very bad job in explaining the problem. I think it's better to read directly from elastic: https://www.elastic.co/blog/licensing-change

The "Why change" section explains it pretty well.

I for sure didn't misunderstand the article itself, it says multiple times that everyone using it should be concerned. It seems like the article isn't very good though.

You're right, I clarified in my edit that the article is misleading.

And Elasticsearch isn't even exploites very good by AWS. It always feels clunky to add it to a serverless architecture.

Would be cool if they would create their own solution with on-demand pricing.

> businesses like AWS that exploit FOSS to repackage it for profit

Exploit is questionable.

A true open-source project like PostgreSQL only benefits from Amazon and Google offering it as a paid, hosted solution. It makes it easier to adopt, sell to decision-makers, and gain more user and developer mindshare over alternatives.

If you are concerned with "competitors" offering your open-source project to more users, then perhaps being open source was just a poorly chosen marketing tactic that backfired.

> A true open-source project like PostgreSQL only benefits from Amazon and Google offering it as a paid, hosted solution

I've been using PostgreSQL for a long time and I'm not clear how the open-source project benefits from being resold by planet-scale cloud providers.

Can we have references for claims like this?

> A true open-source project like PostgreSQL only benefits from Amazon and Google offering it as a paid, hosted solution

And like, how?

For a project to be exploited by tech corps usually the project itself needs to be already relevant and widely used across the industry. That's why it doesn't really need any publicity from AWS and that's why AWS "steals" it, their customers won't have to learn a new tool but can re-use their knowledge. Lower entry barrier = more customers.

> If you are concerned with "competitors" offering your open-source project to more users, then perhaps being open source was just a poorly chosen marketing tactic that backfired.

How free-markety of you.

Now imagine that Elastic took your suggestion. They never made the elastic suite FOSS in the first place but only sold it as a closed source product.

1) It would have never got widely used in the industry

2) We would have never got a free open source tool that helped kick-start many other companies.

You could say the same about Mongo. Imagine what impact it would have had on the startup world if Mongo wasn't a FOSS project.

That's why it is fundamental to protect FOSS projects from corporate exploitation, in order to protect the whole tech eco-system.

"1) It would have never got widely used in the industry"

Agreed.

"2) We would have never got a free open source tool that helped kick-start many other companies."

Disagreed. A different open source tool would have gotten the attention and that would have helped kickstart many other companies. Pretty much every open source tool or library has equally open source alternatives, sometimes even just as popular alternatives.

Elasticsearch is no exception, and its alternatives are about to get a surge in popularity.

"You could say the same about Mongo. Imagine what impact it would have had on the startup world if Mongo wasn't a FOSS project."

More startups would have used Postgres instead... Which probably they should have done anyway. Mongo only started to become usable for anything but raw streams of data, IMO, not long before it became source available. And even nowadays, I would still recommend Postgres (or any relational database) over Mongo for 95% of startups, even if it still were open source.

That said, I know that that is not the case with Elasticsearch, which probably is the best among its alternatives.

Areading314 3 minutes ago | unvote [–]

This is an alarmist headline. The SSPL license to which they are switching only requires your code to be open sourced if you are providing Elasticsearch itself as a service. This change is directed at cloud providers who take open source software and then provide them as a service for payment without contributing to the project. If you are using Elasticsearch on your backend to build search-enabled products or websites, then this does not apply to you.

So basically AWS needs to start coughing up money

Here's the actual language from SSPL

> If you make the functionality of the Program or a modified version available to third parties as a service... (license conditions apply)

> “The Program” refers to any copyrightable work licensed under this License.

IANAL, but that seems pretty cut and dry referring to making an Elasticsearch or Kibana service, not like a GPL kind of "anything that touches this gets the license"

Also, to add

> Every IP lawyer to whom I’ve showed the text of the SSPL has been rather alarmed before they even reach the end of it.

I've had a different experience with IP lawyers and these licenses where they ask "Are you going to build X as a service". We say "No." Then they say "well there's nothing to worry about"

I thought this was going to be about how Elastic in their need to grow seem likely to build products that leverage their underlying tech. So if you have a product built with Elastic tech that is in an interesting niche for Elastic to attack you run the risk of competing directly with the organization on whose tech your product is built.

Products that Elastic has built that leverage their tech

https://www.elastic.co/enterprise-search

https://www.elastic.co/google-custom-search-engine-alternati...

And I guess in a way Kibana is also such a product.

Reply on news.ycombinator.com