Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

291–300 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#291
post #253

Earlier quoted context omitted.

I highly doubt elastic intended to offer it for free to the cloud providers from the start. They wanted to offer it for free to end users. This is why I expect new products will now start with these more restrictive licenses.

Everyone wants to open source their code until someone else makes a billion dollars of it. Everyone wants censorship resistant end to end encryption until terrorists use it. Everyone wants software patents to not exist until they get issued a really good one. This is a classic case of trying to put the genie back in the bottle.

Number 2 and 3 are false.

Edit: I want e2e encryption but not censorship resistant, not when it starts getting used for inciting to violence. Search for eg "WhatsApp lynch mobs" or "Facebook Myanmar genocide".

Re: Licensing changes to Elasticsearch and Kibana

#292

> The SSPL allows free and unrestricted use and modification, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL. That doesn't sound like something incompatible with Open Source Initiative standards for "open source". And it sounds like something existing OSI-approved licen…

I can answer that.

The OSI doesn't approve any license that "discriminates on fields of endeavor", which means you are not allowed to prevent cloud providers from competing with you with your own product.

Premium sponsors of the OSI include AWS, Google and Microsoft.

Re: Licensing changes to Elasticsearch and Kibana

#293
post #59

Earlier quoted context omitted.

You can run the SSPL'd code, you can view the SSPL code, if you change the SSPL code then contribute back if you distribute your changes. If you run a service providing the SSPL code, contribute the management layer back as well. It gets more code into the open, where's the disconnect?

I am not concerned with the code of other users' management layers. I am concerned with being able to use the code of this product in the way I want to use it. Copyleft is not important to me, I see permissive licensing as being a bigger priority for freedom.

> they don't have any intention to develop this software without a profit, then they shouldn't have positioned themselves as a free-and-open-source product in the first place.

If something satisfies the four freedoms [0], it is free software.

[0] https://www.gnu.org/philosophy/free-sw.html.en

Re: Licensing changes to Elasticsearch and Kibana

#294
post #244

Earlier quoted context omitted.

I wouldn't be so sure about that. Thinking "is this software going to be resold by Amazon" is not high up on the priority list for someone who is just working on a hobby project/releasing that project under a permissive license. Sure, this is a non problem for 99.99+% of the population and it's a relatively new "problem", but it's fair to retroactively change the license because it's within their rights.

It's only a "problem" for the 0.001-% who choose to view it that way. There's decades worth of large/serious/complex open source projects that have totally been monetised by other companies without the founders/maintainers feeling ripped off and butthurt about it. Linux, GNU, Apache, Perl, Python, PHP, Rails, WordPress, and many many more projects at least as important and complex as Elasticsearch. We don't hear Linu…

> staying on 7.10 safely and keeping an eye out to see who's gonna fork it and at least keep up security work on it under Apache 2.0 moving forward

I wonder how many companies would be willing to pay $100 a month for their elastic search to continue to receive security updates... in theory the right individual could make a decent living simply forking the various OSS projects that have since gone noSS, applying security fixes, and collecting money from the companies build on them.

Re: Licensing changes to Elasticsearch and Kibana

#295
post #279

Earlier quoted context omitted.

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

There's quite a cottage industry of SIEMS that wrap ELK, so I'm curious how this'll shake out...

I do empathize with the desire to safely open their code for all/most users and their attempt to use SSPL to do it. For Graphistry, we ended up going proprietary for our core GPU visual analytics and went open for more generic infra and client codes, e.g., launched one of the Apache Arrow languages and our popular Python/Jupyter lib. I'm still looking forward to the day we can open our core as well (all our $B/$T partners ask us to, and yet ;-)). Encouragingly, our users are increasingly preferring the marketplace + saas versions, so I remain optimistic about an SSPL-ish license. That 90%+ of ES users go with SSPL is promising!

Re: Licensing changes to Elasticsearch and Kibana

#296
post #292

> The SSPL allows free and unrestricted use and modification, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL. That doesn't sound like something incompatible with Open Source Initiative standards for "open source". And it sounds like something existing OSI-approved licen…

I can answer that. The OSI doesn't approve any license that "discriminates on fields of endeavor", which means you are not allowed to prevent cloud providers from competing with you with your own product. Premium sponsors of the OSI include AWS, Google and Microsoft.

Thanks. What about the SSPL is considered discriminating against a field of endeavor?

The AGPL is OSI-approved, and as I understand it also has a requirement "that if you provide the product as a service to others, you must also publicly release any modifications". (Possibly not "as well as the source code of your management layers", but that addition doesn't seem to post any additional problems related to "restrictions of fields of endeavor", I could see a future AGPL adding it, it seems somewhat the spirit of the AGPL).

What are the parts of SSPL that differ from AGPL in a way that OSI woudln't aprpove?

(The requirement about 'fields of endeavor' can be debated and is one of the currently more debated ones in OSI, but i my memory it goes way back in time to the early days of open source, I think you can probably find Stallman arguing for it before OSI even existed, I don't think it's there for some kind of nefarious reasons inserted by OSI sponsors. But certainly one can disagree with it.)

(Here's Stallman against fields of endeavor restrictions from 2013, definitely not pre-dating OSI, but I think this does go way back, and I don't think anyone thinks Stallman's opinions are bought by corporate sponsors, and Stallman is obviously quite influential in ideas about what open source is. https://web.archive.org/web/20130509151342/https://www.gnu.o...)

Re: Licensing changes to Elasticsearch and Kibana

#297

Earlier quoted context omitted.

Elastic contributes massively to Lucene, so this is a false dichotomy

Would Elastic be in a position to "close source" / "re-license" their code if Lucene itself wasn't permissively licensed? Your argument's putting the cart before the horse.

No, offering your code under Apache/MIT is a bell you can't unring. You can stop offering future changes under the license, but everything up to the point where you change the license is available forever.

Re: Licensing changes to Elasticsearch and Kibana

#298
post #59

Earlier quoted context omitted.

I am not concerned with the code of other users' management layers. I am concerned with being able to use the code of this product in the way I want to use it. Copyleft is not important to me, I see permissive licensing as being a bigger priority for freedom.

> they don't have any intention to develop this software without a profit, then they shouldn't have positioned themselves as a free-and-open-source product in the first place. If something satisfies the four freedoms [0], it is free software. [0] https://www.gnu.org/philosophy/free-sw.html.en

How does SSPL satisfy GNU's "freedom 0", to run the program for any purpose?

Re: Licensing changes to Elasticsearch and Kibana

#299

Earlier quoted context omitted.

Some observations: (1) It's interesting how much of the reasoning/argumentation for these restrictive licenses ultimately comes down to a more articulate form of "but that's not fair!". I also wonder how much the implicit beliefs that "unrestrained capitalism is a bad thing", "markets naturally lead towards monopolies", "antitrust law is legitimately necessary", etc are impacting peoples' reasoning here. (2) If they…

> 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 consider that a very deserving cause.

Re: Licensing changes to Elasticsearch and Kibana

#300
post #275
post #260

Earlier quoted context omitted.

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.

> All their contributions up until this point are still under the Apache license, so they'd have no reason to sue, I think

Ah right - makes sense.

Post reply on HN