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

221–230 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#221

Post by jnwatson »

__blockcipher__ wrote: post #176
unethical_ban wrote: post #139

Earlier quoted context omitted.

You are being too cynical. Their argument is, more charitably: "We built this, we released it for free. Our business model is professional support and hosted services. In order for us, the creators of this software, to continue building it, we cannot allow megacorporations to freely spin up a loss-leading competitive service and cut us out."

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…

The problem is that nobody buys AWS ElasticSearch because of quality. They buy it because they already have AWS approved as a vendor and a blank check to spend on it.

Re: Licensing changes to Elasticsearch and Kibana

#222

Post by remram »

VoxPelli wrote: post #180

Seems like there’s no talk on why they picked SSPL over BSL? I like BSL because it always eventually transitions to an ordinary open source license. So over time all BSL licensed code will actually be open source. That seems to not be the case with SSPL? Good post on BSL: https://perens.com/2017/02/14/bsl-1-1/

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.

Re: Licensing changes to Elasticsearch and Kibana

#223

Post by confiq »

ahachete wrote: post #214
confiq wrote: post #168

Earlier quoted context omitted.

I assume if you run ES in your own datacenter or you use SaaS, you will be fine! I guess they target AWS but not AWS users...

If you'd install ES via deb or rpm or whatever packages from your Distro, this will affect you, as they will be sooner than later removed. If there's a policy for open source-only usage, you will definitely be affected. If there will be a diminished number of contributors (which won't like to contribute if it is not open source) and ecosystem (that will stop developing/growing being a proprietary project), you will b…

I'm not sure that if I use ES in my datacenter I would be effected as long as it's internal tool for analysing data.

I'm not lawyer but this is what I understand from their statement.

Re: Licensing changes to Elasticsearch and Kibana

#224

Post by VoxPelli »

remram wrote: post #222
VoxPelli wrote: post #180

Seems like there’s no talk on why they picked SSPL over BSL? I like BSL because it always eventually transitions to an ordinary open source license. So over time all BSL licensed code will actually be open source. That seems to not be the case with SSPL? Good post on BSL: https://perens.com/2017/02/14/bsl-1-1/

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 with BUSL the code will be actually open source eventually whereas here it will stay in this extended AGPL-like license forever?

Re: Licensing changes to Elasticsearch and Kibana

#225

Post by floatingatoll »

Bombthecat wrote: post #112
ignoramous wrote: post #98

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?

No. None of the things you describe involve both providing service to third-parties and modifying SSPL-licensed ElasticSearch code. You are operating the code purely for your own benefit, and you are not patching SSPL-licensed code, and therefore nothing from this discussion is applicable to your described use case. (I'm not your lawyer, etc.)

Re: Licensing changes to Elasticsearch and Kibana

#227

Post by cthor »

__blockcipher__ wrote: post #199
pietrovismara wrote: post #115

Earlier quoted context omitted.

In practice it would only affect corporate thieves, so I think it's actually necessary to protect the open source ecosystem.

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 do that job well, but don't confuse it as competing with permissive licenses.

[1]: https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up.h...

Re: Licensing changes to Elasticsearch and Kibana

#228

Post by slimsag »

dhd415 wrote: post #219
slimsag wrote: post #204

Earlier quoted context omitted.

It can be, they just chose not to (with ulterior motives or not, I cannot say.) For my side project, I am using a dual-licensed MIT/Apache (your choice) but with an exclusion which prohibits companies like AWS from offering it alone as a service. Here's a copy of the (quite human-readable) license: https://gist.github.com/slimsag/2164520b9e249fbae4e08e2bdf6e...

I think a more charitable interpretation of Elastic's motives in the re-licensing would be to view them the same as your motives for your side project -- allow free use to anyone except those wanting to offer it as a hosted service. You say that you've licensed your side project with MIT and Apache2 but with an exclusion. In other words, it's neither MIT nor Apache2 and it's unclear how your exclusion would hold up l…

That's all fair and I agree!

But I think it's unfortunate that companies end up with licenses like SSPL which are lengthy, not legible to non-lawyers (see this thread) and more importantly ambiguous in favor of the SSPL-software-provider. It's only natural, that's what lawyers are hired to do, after all! But I think there are other options (be ambiguous in favor of the opposing party, or build upon existing licenses)

Re: Licensing changes to Elasticsearch and Kibana

#229

Post by floatingatoll »

latortuga wrote: post #135
edoceo wrote: post #101

Earlier quoted context omitted.

Yea I read that as if E/K is used to power your backend analytics for your dev team we're OK but using for client facing reports, a key feature of your application, is blocked.

Even worse, Elasticsearch is a great product for adding "search" to your webapp. I don't see how integrating it doesn't run afoul of: 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...

If you aren't modifying the ElasticSearch source code, then you don't need to care about any of this conversation at all.

If you add search to your webapp using ElasticSearch, you typically would not be modifying it, and so any source distribution burden that could possibly be compelled from you in a worst-case scenario would be for the unmodified source code that you freely downloaded from a public website. No local modifications? No violation of terms. End of line.

While that's a slight risk of having more burden than not having to provide that source code, it's not like it contains anything proprietary, because you probably aren't modifying it anyways — and once you divulge that source, it's proof that you not only did not violate terms, but could even request legal fees.

So whether or not this search usage would qualify, which can only be definitively decided in a court of law, your actual risk of harm and exposure is none whatsoever — unless you have proprietary patches to ElasticSearch and you aren't already sharing them openly in a GitHub fork. (I'm not your lawyer, etc.)

Re: Licensing changes to Elasticsearch and Kibana

#230

Post by Aeolun »

jnwatson wrote: post #221
__blockcipher__ wrote: post #176

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…

The problem is that nobody buys AWS ElasticSearch because of quality. They buy it because they already have AWS approved as a vendor and a blank check to spend on it.

Yeah, so they’re not really competing with Elastic right? If I already have an AWS environment I’m never going to use an Elastic hosted service, since it’d be outside my VPC.

I really don’t understand how that business model works.

Post reply on HN