Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

141–150 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#141

Earlier quoted context omitted.

Of course, they should "encourage" Amazon not to steal their product and business model. Right. It is not possible to steal something from someone who deliberately and freely offers that thing to you.

And they (ElasticSearch) rightfully excluded what they feel is taking advantage of them in an exploitative manner. I am quite sure they are open to a reciprocal licensing agreement with AWS et al.

They are welcome to do that if they feel that way. But it's not theft for people to use software under the terms of the license you offer it to them under, and it's a fucking stupid accusation to make.

Re: Licensing changes to Elasticsearch and Kibana

#142

Earlier quoted context omitted.

And they (ElasticSearch) rightfully excluded what they feel is taking advantage of them in an exploitative manner. I am quite sure they are open to a reciprocal licensing agreement with AWS et al.

They are welcome to do that if they feel that way. But it's not theft for people to use software under the terms of the license you offer it to them under, and it's a fucking stupid accusation to make.

I agree, the sentiment was more akin to "taken advantage of" rather than "getting robbed".

Re: Licensing changes to Elasticsearch and Kibana

#143
I'm glad that the SSPL is becoming more of a standard for this sort of "open source minus AWS" software. One of the benefits of standard open source licenses is that it's easier for companies to give blanket permission, "you can use software that's MIT licensed". Hopefully it becomes easier for companies to just pick whether they say "we allow the use of SSPL'd software" or "we do not allow the use of SSPL'd software" instead of making all the software engineers have discussions with lawyers to get work done.

Re: Licensing changes to Elasticsearch and Kibana

#144
post #119

Are there any known instances where a company offering Mongo or another SSPL-licensed app as a service has complied with section 13 by releasing the “Service Source Code” of everything supporting the service? If not, that basically confirms the OSI's rejection of the SSPL as an open source license -- If that provision is too onerous to be followed, it might as well say "you can't offer this as a service".

You could say the same about the GPL - the practical effect is almost never to make a company release their previously-proprietary source code, the practical effect is to make companies not use it in the first place. Which is fine, as long as it's clear what the rules are, and the rules seem clear enough to me.

Re: Licensing changes to Elasticsearch and Kibana

#145
post #113

Earlier quoted context omitted.

This. I feel so much for the hundreds of open source developers who toil everyday only to have AWS make so much money out of it, to make the largest shareholder the richest man on earth, while contributing nothing back to any of the open source projects. This has to be fixed or we will see less and less developers open sourcing quality products

It's not open source though.

Yes, it is not. But who cares? What I care about as a user is repairability:

* can I inspect source and build it myself?

* can I fix it?

* can I share modifications with others?

Many of the new "cloud protection licenses" offer this, yet they are (by definition) not opensource.

Re: Licensing changes to Elasticsearch and Kibana

#146

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?

Yes. That's the intent, that if you have some code (such as your devops pipeline) which is used to provide some service to an end user, the end user is able to use/modify/redistribute that code to provide the same service without you being able to obstruct what they do.

Re: Licensing changes to Elasticsearch and Kibana

#147
post #119

Are there any known instances where a company offering Mongo or another SSPL-licensed app as a service has complied with section 13 by releasing the “Service Source Code” of everything supporting the service? If not, that basically confirms the OSI's rejection of the SSPL as an open source license -- If that provision is too onerous to be followed, it might as well say "you can't offer this as a service".

In principle this should not be a big problem. See how Red Hat successfully works with GPL code.

I think the big issue is that all Sass Providers considered themselves free from such pesky license details like copyleft, because they don't distribute software.

I think the biggest problem with the SSPL is its vagueness when it comes to liabilities and its broad reach when it comes to contagion. In principle, a copyleft license that covers service providers is long due, but it better be a good and practical one.

Re: Licensing changes to Elasticsearch and Kibana

#148

I wonder how many people contributed to Elastic which do not work for Elastic.co ? Those folks have reasonably counted on having fruits of their labor to be available under Apache 2.0 and now they only get to use them with SSPL restrictions

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.

Re: Licensing changes to Elasticsearch and Kibana

#149

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…

Isn't it equally true that if they moved to being entirely proprietary but free-of-charge software, or if they had a "all rights reserved but you can look at the source if you want" license, or whatever, there would be no impact on most customers either?

If so, why bother leaning into the word "open"? Just call it freeware.

Re: Licensing changes to Elasticsearch and Kibana

#150

It's just a change to make sure that those who resell ES as a service share their code. We use AWS's ES. And, as far as I'm concerned they already open-source their version. SSPL is actually helping the open-source community here

We use AWS's ES. And, as far as I'm concerned they already open-source their version.

Unfortunately for you, there's a decent chance that AWS freezes their support at a version before this license change, and never offers upgrades. As far as I know, AWS has never agreed to offer services based on code under the SSPL license.

Post reply on HN