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

131–140 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#131

Post by matthewowen »

ignoramous wrote: post #98
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…

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…

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 _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.

Of course by the time you get to that point in a legal dispute you're already in some trouble.

But IDK, I'm just a software person speculating. Is there a legal person interested in giving their "not legal advice" perspective on this?

Re: Licensing changes to Elasticsearch and Kibana

#132

Post by j1elo »

PeterZaitsev wrote: post #76

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

I raised precisely this concern a week ago: https://news.ycombinator.com/item?id=25631073

my intention there was (and still is) to learn how other HNers think of this. In there I got the response about how the precise version to which people contributed, was and will always be Open Source, regardless of what happens to future derivations of that code.

I'm not sure I bought that reasoning, though... you put it better with that "fruits of their labor". Maybe not the writing, but the spirit of the permissive FOSS licenses is not to end up being swapped into a non-FOSS alternative...

The previous FOSS license did indeed permit any future change in licensing; I would like to learn if that kind of choice might actually become a deterrent and an added reason for a lower number of external contributors, or not.

Re: Licensing changes to Elasticsearch and Kibana

#133

Post by fabianhjr »

pietrovismara wrote: post #95

Honestly, every relevant FOSS project should adopt a similar license to prevent exploitation from corporations.

There is some discussion on the P2P Foundation regarding copyfarleft/copyfair/copyjustright however in my experience even the most popular copyfarleft isn't as adopted. ( https://wiki.p2pfoundation.net/Copyfarleft )

I have been gathering resources regarding copyfarleft licensing and projects here: https://github.com/LibreCybernetics/awesome-copyfarleft

Re: Licensing changes to Elasticsearch and Kibana

#134

Post by matthewmacleod »

veselin wrote: post #127
matthewmacleod wrote: post #116

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.

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.

Re: Licensing changes to Elasticsearch and Kibana

#135

Post by latortuga »

edoceo wrote: post #101
Nican wrote: post #97

Earlier quoted context omitted.

Also not a lawyer, but I find the language in the license pretty interesting and ambiguous choice of words. > [...] where obtaining access to the Elastic Software or the features and functions of the Elastic Software is a primary reason or substantial motivation for users of the SaaS Offering to access and/or use the SaaS Offering It seems like you can still offer Kibana to end customers, but I wonder where the cutof…

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...

Re: Licensing changes to Elasticsearch and Kibana

#136

Post by ignoramous »

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?

SSPL is a malicious source-available license, if there ever was one: https://news.ycombinator.com/item?id=18301116

I reserve special hate for Commons Clause [0] too but SSPL is downright offensive.

A reminder that F/OSS works very well for a lot of reasons [1]. The number one of which is if you want to commodize your product's complement [2][3]. Don't be a knob and F/OSS your core product if you plan to make billions or whatever.

[0] https://news.ycombinator.com/item?id=17814386

[1] http://dtrace.org/blogs/bmc/2004/12/16/the-economics-of-soft...

[2] https://www.gwern.net/Complement

[3] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

Re: Licensing changes to Elasticsearch and Kibana

#137

Post by ahachete »

> This change in source code licensing has no impact on the overwhelming majority of our user community

How come? If you switch open source to proprietary software (as much source-available as it may be), there's a significant impact: a % of users won't use proprietary software; those who may will not find this software packaged on package managers; derivatives and companion projects may stop being developed. Where's the "no impact"?

Re: Licensing changes to Elasticsearch and Kibana

#138

Post by fabianhjr »

matthewmacleod wrote: post #116
veselin wrote: post #107

Earlier quoted context omitted.

The author says in the end that the problem is not Amazon. Then links to a post where he suggests that companies maintaining the open source should have "invested the resources to build stronger communities around them. They would have reached out to Amazon, encouraged them to contribute back to the projects, and helped them to do so." Of course, they should "encourage" Amazon not to steal their product and business…

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.

Re: Licensing changes to Elasticsearch and Kibana

#139

Post by unethical_ban »

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…

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."

Re: Licensing changes to Elasticsearch and Kibana

#140

Post by CSDude »

nopzor wrote: post #20
binarymax wrote: post #19

Earlier quoted context omitted.

It means that any “derivative work” will need to also open the management layer under SSPL. The management layer is AWS, so this puts OpenDistro in a tight spot. I’m not sure forking would work - as Elasticsearch evolves Amazon would not be able to copy features anymore. In the search space, this would be a very hard pill to swallow.

they’d still be able to innovate their own fork, but they will no longer be able to pull future upstream elastic code into it. so it becomes more of a hard fork. if elastic continues to innovate it will be difficult for open distro to remain competitive with it.

AWS ES has major problems, have been a pain us for years. Pretty sure they cannot be competitive with a hard fork
Post reply on HN