Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

271–280 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#271
post #164

Earlier quoted context omitted.

elasticsearch had a contributor license agreement in place for about as long as I can think, requiring full copyright assignment for all changes you’d contribute.

That's not accurate: there is a contributor agreement but it does not assign copyright. https://www.elastic.co/contributor-agreement

It is effectively very similar to copyright assignment as it gives Elastic basically the same rights they would have if they were assigned the copyright. The only difference is the contributor also gets those rights, but in reality the rights they keep are not that useful since the rest of the codebase is owned by others.

Re: Licensing changes to Elasticsearch and Kibana

#272

Earlier quoted context omitted.

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. 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…

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

This change only applies if you are offering Elasticsearch and Kibana _directly_ as a service.

It doesn't impact your devops pipeline or your monitoring workload(s).

Link to FAQ: https://www.elastic.co/pricing/faq/licensing

Re: Licensing changes to Elasticsearch and Kibana

#273
post #140

Earlier quoted context omitted.

AWS ES has major problems, have been a pain us for years. Pretty sure they cannot be competitive with a hard fork

My guess, from AWS experience, is that you're right. What specific pain points did you experience?

Other services are great. Aws es is just put together. It goes down, blue green updates take forever, arbitrary disk limits etc.

Re: Licensing changes to Elasticsearch and Kibana

#274
So they'll be source available moving on, like MongoDB. Will keep it in mind.

By the way, I am not a lawyer and I might have misinterpreted the article, but I feel like the AGPL could have accomplished what they wanted to do. Maybe it's not restrictive enough for their needs, but I'm not sure why.

Re: Licensing changes to Elasticsearch and Kibana

#275
post #260

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 websit…

I wonder if non-ElasticCo contributors to Elastic Search who disagree with the SSPL license change can sue to have their contributions removed. Could even be a class action lawsuit if quite a few contributors disagree.

All their contributions up until this point are still under the Apache license, so they'd have no reason to sue, I think. And anyone is of course free to fork that code and call it something else.

Now, it's very likely that many of them will stop contributing for versions 7.11 and up.

Re: Licensing changes to Elasticsearch and Kibana

#276

Earlier quoted context omitted.

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. 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…

How true is this, in practice? I hear software folks say this sort of thing somewhat frequently, but I haven't heard it from a _legal_ person. And my general sense and understanding is that although an FAQ style clarification is not _perfect_, it _does_ carry non-trivial weight. Judges are not totally capricious people making arbitrary decisions: the notion that in a dispute they would just cast aside one party's _cl…

Remember when Google argued that Oracle shouldn’t be allowed to sue over using the Java API because SUN had said it was fine? That’s the same legal argument as the FAQ issue. It’s called equitable estoppel.

Re: Licensing changes to Elasticsearch and Kibana

#277
post #273

Earlier quoted context omitted.

My guess, from AWS experience, is that you're right. What specific pain points did you experience?

Other services are great. Aws es is just put together. It goes down, blue green updates take forever, arbitrary disk limits etc.

Yeah at my last gig we used AWS’ offering. Blue green deployments would hit a race condition and the new cluster would never come up, requiring a ticket to be filed. Important APIs and settings were disallowed.

Horrible service. That’s why it’s ironic that Elastic just shot themselves in the foot with this licensing change. So foolish.

Re: Licensing changes to Elasticsearch and Kibana

#278
post #184
post #64

In my mind, this strongly constrasts with the words [0] of WordPress founder Matt Mullenweg. He says they want to own roughly 5% of the WordPress market, and instead of growing their share of the pie, grow the pie itself. [0] https://fs.blog/knowledge-project/matt-mullenweg/

That's great for Matt, but other companies like Elastic can't afford to go from >50% to 5% of their market.

Well, now organizations like Wikimedia are going to have to drop Elasticsearch everywhere despite it powering wikipedia article search and more. So congrats on both missing the GP’s point and also failing to see how this license change would shrink Elastic’s usage / market anyway

Re: Licensing changes to Elasticsearch and Kibana

#279

Earlier quoted context omitted.

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. 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…

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

Next sentence is

> 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.

and IMO (IANAL) that would put some of the services that offer log ingestion / indexing / querying in legal gray area.

Re: Licensing changes to Elasticsearch and Kibana

#280
post #227

Earlier quoted context omitted.

Let's be clear here: You build something. You release it under a license that says, "do what you want with it, profit with it, I don't care". Then someone comes and builds on top of it, and you call them a thief? For using something you told them they could use without restriction? Related: I find it really bizarre how many in the tech community seem to outright just not believe in capitalism...

SSPL isn't being used as an alternative to permissive licenses (e.g. MIT). It's being used to shore up the holes that AGPL doesn't cover[1], to enable the business model of "free for small guys, paid for by the big guys". People want a license that says something like, "you can only use this if you also contribute to the commons, or if you pay for the privilege not to". SSPL is an attempt to be that. Maybe it doesn't…

I know it’s not competing with permissive licenses. That’s my point. The people here acting like the fact that companies are profiting off of Apache 2.0 licensed code are being unreasonable was my point.

Separately, I think this move will just hurt Elastic Co in the long term. The organization I work for runs a 30 TB elastic cluster and we’re going to have to go drop Elasticsearch because of this change because we’re committed to using free and open source software. What a shame.

Post reply on HN