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

51–60 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#51

Post by dhd415 »

shawnz wrote: post #50
dhd415 wrote: post #48

Earlier quoted context omitted.

Since the entire Elasticsearch codebase is now under SSPL, there's no more distinction between the former Apache-2 code and the x-pack code.

There are still proprietary modules only available under the Elastic License just as before. However it seems that they will be moving the free modules which were previously only licensed under Elastic License to be licensed under SSPL instead. At least, that is what this graph seems to be indicating to me. https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce...

You're right -- it's only the free "X-pack Basic" code that will now be available under SSPL. But that does mean that all Elasticsearch distributions will now include the former "X-pack Basic" features.

Re: Licensing changes to Elasticsearch and Kibana

#52

Post by freedomben »

eloff wrote: post #34
arpinum wrote: post #12

"protection against public cloud providers offering open source products as a service without contributing back". I have no issue with whatever license they choose, but let's be honest, its not about contributing back to these projects, its inserting a poison pill clause that they know cloud providers can't meet. Specifically, by contributing back they mean, per the license: "If you make the functionality of the Prog…

What do you expect them to do though? If they want to be viable as a business they need to place some restrictions so they can have a monopoly on some aspect in order to derive profit. If they're not viable as a business, they die and nobody benefits from that. It's this kind of all or nothing criticism that has made me rethink open source. I'm releasing a product this year, and it's going to start under a proprietar…

It's a vocal minority that slings the hate. There are tons of people that appreciate open source with exceptions to prevent managed offerings by cloud providers as long as self-hosting to support your own stuff is allowed (including ability to customize/extend/patch).

I for one will (with a few exceptions) only pay for a product that is open source (at least enough so that I can self-host for my own product if I want should things change). Vendor lock-in is a serious problem and concern for many, and open source is how you address that concern. The best example is GitLab, which gets a ton of money from me that would otherwise go to GitHub (which I like better) if GH were open source.

By going proprietary you avoid the vocal minority on the internet, but you also (silently) shrink your potential customer pool. Especially with the AWS/Parler stuff, there are even more people that want the option to self-host in case they get de-platformed if the Overton Window continues to shift.

May I ask what your product is? Just curious :-)

Re: Licensing changes to Elasticsearch and Kibana

#53

Post by nopzor »

npiit wrote: post #22
nopzor wrote: post #2

wow, this is super interesting, but i can't say i'm surprised by this move. the landscape has really evolved over the last few years for companies trying to build a business around open source. at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. all of our peers (eg. mongodb, elastic, redis, confluent, cockroach,…

I thought Grafana was doing great with its managed offerings. Personally I'd prefer you consider BSL before SSPL since it's usually clearer to most people.

at grafana labs, we are still pretty torn on what our go forward licensing regime should be.

bsl is interesting, but license proliferation and familiarity is a big factor to consider.

now that both elastic and mongo are both using sspl, it is more appealing. i think tsl from timescale is also a great and well thought out license.

Re: Licensing changes to Elasticsearch and Kibana

#54

Post by robcowart »

nkw wrote: post #29

So how is Elastic going to fare if Lucene makes a similar switch?

That can't really happen. While Elasticsearch was previously released under the Apache 2.0 license, it was still "owned" by Elastic.

Lucene on the other hand, is "owned" by the Apache Software Foundation (ASF). While companies can build products based on Lucene, which they release under their own choice of License, they cannot change the Lucene license itself. Only the ASF can do that.

Another example of this is Kafka. It was developed at LinkedIn, who transferred control to the ASF. When the LinkedIn employees who originally created Kafka, left to form Confluent, they had no control over the licensing of Kafka. They could only decide on the License for the Kafka add-ons that they provide. Eventually (about a year ago) they forked Kafka to create "Confluent Server", which is released under their proprietary license. Kafka itself however remains open source under Apache 2.0 license, still controlled by the ASF.

Re: Licensing changes to Elasticsearch and Kibana

#55

Post by shawnz »

dhd415 wrote: post #51
shawnz wrote: post #50

Earlier quoted context omitted.

There are still proprietary modules only available under the Elastic License just as before. However it seems that they will be moving the free modules which were previously only licensed under Elastic License to be licensed under SSPL instead. At least, that is what this graph seems to be indicating to me. https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce...

You're right -- it's only the free "X-pack Basic" code that will now be available under SSPL. But that does mean that all Elasticsearch distributions will now include the former "X-pack Basic" features.

That seems to be what they are suggesting by making the "free" box in the 3rd column span both the "free" and "free/basic" tiers of the previous columns.

Unless they plan to make those modules paid which were previously free, which I doubt

Re: Licensing changes to Elasticsearch and Kibana

#56

Post by yjftsjthsd-h »

a_imho wrote: post #8

The article loads for ~10 sec, shows for a split second and then the screen becomes empty. I'm using a moderately old browser (FF 61.0.1) but come on, how hard it is to display some text?

That's not even an ESR version - forget pages breaking, running Firefox 61 in 2021 is a security nightmare.

Re: Licensing changes to Elasticsearch and Kibana

#57

Post by dhd415 »

nopzor wrote: post #53
npiit wrote: post #22

Earlier quoted context omitted.

I thought Grafana was doing great with its managed offerings. Personally I'd prefer you consider BSL before SSPL since it's usually clearer to most people.

at grafana labs, we are still pretty torn on what our go forward licensing regime should be. bsl is interesting, but license proliferation and familiarity is a big factor to consider. now that both elastic and mongo are both using sspl, it is more appealing. i think tsl from timescale is also a great and well thought out license.

Interesting. I got the impression from the recent announcement that Grafana Labs had something of a revenue sharing model with the new AWS managed offering of Grafana. Given that, I wouldn't think the SSPL restrictions would be as important.

Re: Licensing changes to Elasticsearch and Kibana

#58

Post by mfreed »

LukeEF wrote: post #32
nopzor wrote: post #2

wow, this is super interesting, but i can't say i'm surprised by this move. the landscape has really evolved over the last few years for companies trying to build a business around open source. at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. all of our peers (eg. mongodb, elastic, redis, confluent, cockroach,…

As far as I can tell, Timescale is not like the others, their shift was to make the formerly proprietary enterprise only code source available. Remarkably they went MORE open rather than less (as it the case for all the others). You have to give them respect for approaching things differently.

Thanks for the clarification, Luke.

For a bit more background for the HN community:

When we initially launched the Timescale License in Dec 2018, we didn't relicense any of our Apache-2 code -- that was and has always remained licensed under the Apache 2 license. Instead, we effectively were "pre-announcing" that some future advanced features (yet to be developed) would instead be released under the Timescale License or under a paid-only commercial license (although still source-available).

Fast forward to September 2020 and Timescale 2.0, and we (i) made some aspects of the Timescale License more permissive (e.g., "right to repair", "right to improve"), and (ii) moved all the previously enterprise (paid-only) features to be available for free under the Timescale License. Hope that helps!

https://blog.timescale.com/blog/building-open-source-busines...

Re: Licensing changes to Elasticsearch and Kibana

#59

Post by shawnz »

andlarry wrote: post #49
shawnz wrote: post #37

Earlier quoted context omitted.

Agreed, if their hosted cloud services and premium features aren't viable as a business, and 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.

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.
Post reply on HN