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

241–250 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#241

Post by sokoloff »

cheph wrote: post #129
Areading314 wrote: post #82

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…

The problem is, SSPL is heavily based of GPL, using the same concepts, and inheriting similar problems. GPL does not clearly define where the boundaries of a program is, but there is a fair bit of basis in the GPL FAQ and other writings from the FSF that suggesting that in their opinion, if I write a program B, that specifically depends on program A, then program A and B is part of the same program, regardless of whe…

I think it’s more complex than that. If your program B is, as an example, a formatting-in-HTML wrapper around program A (say gnu grep), then you can ship B in binary-only, non-GPL form that calls A, so long as the end user can replace A with a later version or their own patched version of A and B continue to work. (This preserves the freedom of the user with respect to A.)

In that case, B specifically depends on A (for filtering functionality), yet is still (likely, IANAL) considered a mere aggregate as I read things.

Re: Licensing changes to Elasticsearch and Kibana

#242

Post by paxys »

fiberoptick wrote: post #14

I wonder where this leaves the AWS-sponsored Open Distro for Elasticsearch? ( https://opendistro.github.io/for-elasticsearch/ ) Seems to me that they have no choice but to hard fork off of the last Apache-licensed release of Elasticsearch et al

They'd have to re-license Open Distro to SSPL instead of Apache 2.0 to remain complaint, but I don't know if Amazon would be willing to do that. Considering they have to solve the hosted Elasticsearch problem anyways, I think either a fork or a one-off deal with Elastic is on the horizon.

Re: Licensing changes to Elasticsearch and Kibana

#243

Post by freeone3000 »

halbritt wrote: post #171
matthewowen wrote: post #131

Earlier quoted context omitted.

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…

In my experience, corporate lawyers don't really understand the distinction and will opt for the route of least risk, which generally entails a commercial relationship with the company. Unfortunately, neither Mongo nor Elastic really offer useful commercial relationships. That is, pay them a sum and be free to use the widely adopted open-source version of their thing. The overhead to those relationships for what they…

Mongo absolutely offers this. A company I worked for had a contract with them -- these terms are hugely expensive, to the point it was worth switching to the AWS version when we had no AWS services.

Re: Licensing changes to Elasticsearch and Kibana

#244

Post by isatty »

matthewmacleod wrote: post #134
veselin wrote: post #127

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.

I highly doubt anybody chooses an explicitly free and open source license without intending to offer their software to users under the terms of that license.

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.

Re: Licensing changes to Elasticsearch and Kibana

#245

Post by treis »

signal11 wrote: post #207
treis wrote: post #152

Earlier quoted context omitted.

I'm not sure if people are really confused about this or sowing FUD. Using Elasticsearch to search your own webapp is not providing Elasticsearch as a service. It's using Elasticsearch to provide functionality in your application. Providing Elasticsearch as a service means allowing people to upload their own data and giving them an Elasticsearch instance to search it. There's some grey area where it's a question if y…

> ...if you provide a way to upload logs and then search them that's Elasticsearch as a service Yes, and if you let your internal company blogging platform ping a service upon every new post, which then feeds that post into Elastic so blog posts across your company are searchable? I suspect one way to avoid this would be “buy a commercial license” (or use Amazon’s fork if you’re so minded), but if you’re using Elasti…

How does making a blog searchable count as offering Elastic search as a service?

Re: Licensing changes to Elasticsearch and Kibana

#246

Post by nanagojo »

confiq wrote: post #175
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

> https://github.com/valeriansaliou/sonic This is actually very interesting project. Do we have some benchmark that sonic works on huge scale with lot of data?

I assume you find their own benchmarks not conclusive enough? https://github.com/valeriansaliou/sonic#how-fast--lightweigh...

they also claim

> It is used to index half a billion objects on a $5/mth 1-vCPU SSD cloud server (as of 2019)

Re: Licensing changes to Elasticsearch and Kibana

#247

Post by yjftsjthsd-h »

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

> around what is best for our own licensing strategy

As a user (self hosted for internal monitoring): if you must change, please, please make it completely unambiguous what the scope is. I really want to avoid having an argument with my team about whether we're using grafana to "provide our service".

Re: Licensing changes to Elasticsearch and Kibana

#248

Post by jrumbut »

ender341341 wrote: post #195
matthewowen wrote: post #131

Earlier quoted context omitted.

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…

> Judges are not totally capricious people making arbitrary decisions: the notion that in a dispute they would just cast aside one party's _clear and well documented intent_ to narrow the scope of the burden they place on another is... well, it doesn't seem all that credible to me. My (non-lawyer) experience tells me the same, judges don't like people who try to argue one thing to a judge while clearly documenting on…

It raises question of how binding is publishing an FAQ? If I sent them an email with that question and they sent me an answer, if they tried to sue me over the issue that email will be a significant piece of evidence in my favor (I imagine).

But what if they only sent me a link to the FAQ or I just silently relied on it to be accurate?

Re: Licensing changes to Elasticsearch and Kibana

#249

Post by tick_tock_tick »

LukeEF wrote: post #30
LukeEF wrote: post #28

I can understand the motivation - AWS' approach, particularly to elastic, has been pretty awful, and migrating away from Apache/GPL/MIT is like a coming of age for the big databases (Mongo, Cockroach, Elastic...) - but calling the article 'Doubling Down on Open' stretches credibility. Be honest, treat us like adults and cut all the 'we're doing this to remain open' crap. You are a public company who wants to increase…

Special mention for this paragraph: 'we expect that a few of our competitors will attempt to spread all kinds of FUD around this change. Let me be clear to any naysayers. We believe deeply in the principles of free and open products, and of transparency with the community.' Get your offense in early and try not to mention open source!

We support these principles just not enough to actually support them......

Re: Licensing changes to Elasticsearch and Kibana

#250

Post by remram »

VoxPelli wrote: post #224
remram wrote: post #222

Earlier quoted context omitted.

BSL doesn't let you use software "in production" at all. So you wouldn't be able to offer search on your website with Elasticsearch at all, whether you could be construed to be reselling it or not, and whether your whole stack is opensource or not. Also the SPDX identifier for it is BUSL since BSL was already taken by the Boost Software License.

Not true that it doesn’t allow production usage, it just doesn’t do it by default. The intention is that it’s up to the one using the BUSL to specify to which degree production usage is allowed: “The Licensor may make an Additional Use Grant, above, permitting limited production use.” Eg. Sentry allows all non-SaaS production deployments of their BUSL licensed code, which is pretty much the same goal as here, but wit…

I see. It's a really wide range of licenses then.
Post reply on HN