Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

Post reply on HN
Print view View original

321–330 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#321

Post by CameronNemo »

deknos wrote: post #316
xvilka wrote: post #61

Luckily there are faster and smaller alternatives in Rust for the ElasticSearch - Toshi[1], Meili[2] and Sonic[3]. In the age of Rust there is no need to use JVMs overhead. [1] https://github.com/toshi-search/Toshi [2] https://github.com/meilisearch/MeiliSearch [3] https://github.com/valeriansaliou/sonic

though there would be vector as logstash/fluent replacement, there's no kibana (even a basic version) which one could use with these components.

Could honestly be a good thing. Kibana encourages admin by GUI in a way that creates a big mess of the cluster.

Re: Licensing changes to Elasticsearch and Kibana

#322

Post by CameronNemo »

philtar wrote: post #319
Illniyar wrote: post #304

Everytime an open source project changes it's license to protect against cloud services not "paying their dues" a lot of people say it doesn't matter because the company will only go after the cloud providers, the big players, and if you just use it internally it won't affect you. I think people forget that these companies might be bought in the future by Oracle.

Then oracle will change it to whatever license they want regardless of what the original license was.

Elastic does require a CLA.

Re: Licensing changes to Elasticsearch and Kibana

#323

Post by joking »

AmericanChopper wrote: post #151
victor106 wrote: post #45

Earlier quoted context omitted.

This. I feel so much for the hundreds of open source developers who toil everyday only to have AWS make so much money out of it, to make the largest shareholder the richest man on earth, while contributing nothing back to any of the open source projects. This has to be fixed or we will see less and less developers open sourcing quality products

I don't think it's reasonable to attribute motive to the contributors in this way. Changes like this protect the elastic enterprise, whether they align with the motives of contributors would have to be evaluated on a per-contributor basis. I've made several contributions to ELK, and my only motive has been that it's useful open source software, and I want to make it more useful. I personally don't care who profits of…

that's one of the things that bugs me, old contributions like yours have the apache license, can they modify without your approval?

Re: Licensing changes to Elasticsearch and Kibana

#324

Post by nuker »

__blockcipher__ wrote: post #315
nuker wrote: post #307

Earlier quoted context omitted.

> If I'm spending $100k/mo on my logging stack, and it's falling over frequently I do the same and AWS ES works fine. I did try Elastic, performance was bad. They run it in containers internally!

Have you never been burned by those awful blue-green deployments? Of course, my company was willing to pay $100k/mo to log every SQL query in existence but wasn't willing to pay for AWS support (of course it would have required paying something like 1% of our TOTAL aws spend, not just aws elasticsearch, although we could have probably created a subaccount or something)...so maybe the experience is different if your t…

Guys did benchmarks, AWS ES was as fast as hand rolled one, Elastic was few times slower. Searching in Kibana had substantial delay.

Yea, I got bit once by one stuck blu-green. Root cause was zero free disk space, I now keep it at 25%

And we do pay for tech support, im in luck here :)

Re: Licensing changes to Elasticsearch and Kibana

#325

Post by ForHackernews »

__blockcipher__ wrote: post #203
ForHackernews wrote: post #80

Sounds good to me. This is clearly targeted at big cloud providers who have been free-riding for years on the work of open source projects.

Does not sound good to me, for the reasons that others have mentioned. But just to be clear: if a big cloud provider uses their software to make money, that's great. That's the point of a non-restrictive license. Yet now Elastic isn't content with competing in the market with its own managed offering (ironic because their offering is way better than AWS' anyway). Instead, they want to call themselves open source whil…

If companies want to make the software available under a license that allows me to use it for free, examine the source code, make changes, and release those changes to the community for others to use -- everything except taking their software and re-selling it directly, then I'm 100% fine with that.

I don't care about not being allowed to compete directly with Elastic using their own product against them.

Re: Licensing changes to Elasticsearch and Kibana

#326

Post by MaxBarraclough »

Graphguy wrote: post #130
MaxBarraclough wrote: post #103

Earlier quoted context omitted.

It seems it has neither the OSI's blessing as an Open Source licence, nor the FSF's blessing as a Free Software licence. Can anyone comment on why not, given that the AGPL has the blessing of both organisations? edit Here's an informative StackExchange comment. [0] Apparently it's a good deal stricter than the AGPL, and introduces much more legal uncertainty. [0] https://opensource.stackexchange.com/a/7523/

https://opensource.org/LicenseReview122018

Good link, thanks. I don't think there's a equivalent response from the FSF, perhaps it was never submitted for FSF approval.

Re: Licensing changes to Elasticsearch and Kibana

#327

Post by koffiezet »

xvilka wrote: post #61

Luckily there are faster and smaller alternatives in Rust for the ElasticSearch - Toshi[1], Meili[2] and Sonic[3]. In the age of Rust there is no need to use JVMs overhead. [1] https://github.com/toshi-search/Toshi [2] https://github.com/meilisearch/MeiliSearch [3] https://github.com/valeriansaliou/sonic

JVM overhead is overrated. And I say that as someone who's not particularly fond of the JVM. Elasticsearch is one of those projects where the JVM is not the issue.

Of all the projects you mention however, only Toshi addresses clustering, and as an experimental feature.

If you're using it for logfiles, the only real alternative I know is Grafana's loki.

Re: Licensing changes to Elasticsearch and Kibana

#328

Post by ignoramous »

confiq wrote: post #320
Xylakant wrote: post #236

Earlier quoted context omitted.

Opendistro is primarily a set of plugins for the stock APL ES distribution, not a fork of elasticsearch proper.

I've just checked, you are right! Correct me if I'm wrong, AWS ES service still uses ES free licence but they've re-written the plugins so they won't use ES and pay ES fee? With new licence, AWS won't be able to use ES as SaaS?

As things stand: Yes, to both your questions.

Re: Licensing changes to Elasticsearch and Kibana

#329

Post by ForHackernews »

ignoramous wrote: post #136
Bombthecat wrote: post #112

Earlier quoted context omitted.

Wait? Would even my devops pipeline fall under it? Or my monitoring? Deployment and management in kubernetes for example?

SSPL is a malicious source-available license, if there ever was one: https://news.ycombinator.com/item?id=18301116 I reserve special hate for Commons Clause [0] too but SSPL is downright offensive . A reminder that F/OSS works very well for a lot of reasons [1]. The number one of which is if you want to commodize your product's complement [2][3]. Don't be a knob and F/OSS your core product if you plan to make billion…

HN: "Hey, you're not using an FLOSS license!"

Also HN: Don't be a knob and F/OSS your core product if you plan to make billions or whatever.

They're doing exactly you want: picking a non-free license for their core product, and you're still mad at them.

Re: Licensing changes to Elasticsearch and Kibana

#330

Post by Xylakant »

jakear wrote: post #299
Xylakant wrote: post #189

Earlier quoted context omitted.

> 2) If they can't actually compete and provide superior value to whatever managed offering Amazon can scrounge together, that's actually their fault. The sad-funny thing is that elastics hosted cloud offering is clearly superior to AWS’ hosted elasticsearch in pretty much all regards.

Seems like you know a thing or two about this — are all the reports I see about companies leaking tons and tons of data through improperly configured elastic search instances something using the aws’s offering would fix (or even ES’s hosted offering)? I don’t really know much about the field, but if AWs’s single contribution were to be “we made it really hard to screw up the configuration and leak all your data”, I’d…

> Seems like you know a thing or two about this — are all the reports I see about companies leaking tons and tons of data through improperly configured elastic search instances something using the aws’s offering would fix (or even ES’s hosted offering)

The primary issue that leads to that is that the stock open source elasticsearch distribution (APL licenced) does come with no security at all. It even used to be the case that even the most basic security was a plugin that required a paid license. That changed only after AWS released the opendistro set of plugins with a free plugin to add security - after that, elastic offered a basic (free as in beer, but still non-free as in freedom) license that would include security. Additionally, the early ES versions would bind to all IPs by default, so just starting the server would make it available from outside. If you weren't expecting that and no firewall was protecting you, your ES cluster would be available from the outside with not authentication.

Both AWS and elastics hosted offering come with a configured security plugin, so that at least makes it harder to leak data. Obviously, even with authentication you can still leak credential or such.

Post reply on HN