Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

351–360 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#351
post #24

Earlier quoted context omitted.

>Personally, I'd rather see a more aggressive AGPL where REST calls are considered linking and trigger virality That's why I never understood the point of SSPL. Is this exactly what AGPLv3 is supposed to be for?

IANAL I believe AGPL expands the definition of distribution not of linking. So if GCC was AGPL and I made a web page where you could upload source code and then download the binary, that would count as "distributing" GCC and thus I would have to make the changes I made available (because privately made change to GPL code do not have to be shared if the binaries aren't shared).

Yes, I think I get it. For example if your creating an AGPLv3 server application, the client I guess must be AGPLv3 too. I just don't understand the point of SSPL even though it looks completely FOSS license to me (maybe just OSI has its own agenda to freely let big cloud companies just use popular FOSS projects without annoying restrictions that would hurt them financially).

Re: Licensing changes to Elasticsearch and Kibana

#352
post #346

Earlier quoted context omitted.

As things stand: Yes, to both your questions.

there is this twitter user that claims that non-elastic employees can't contribute[1]. I wish somebody could summarise this romance between AWS vs Elastic for simpler people because I can't catch up :( [1] https://twitter.com/_msw_/status/1349939801445658624

I didn't say that non-Elastic employees could not contribute. I said that they cannot become maintainers.

Non-elastic pull requests are merged, as I mentioned in [1].

[1] https://twitter.com/_msw_/status/1349814591501475840

Re: Licensing changes to Elasticsearch and Kibana

#353
post #34

Earlier quoted context omitted.

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…

This "We need it for survival" is bullshit. With Elastic being public company you can see their revenue growing 60% last year.... with Apache 2.0 license. It is not the case what we've been loosing revenue for years due to AWS competition and this is the last action of the last resort. This is simply about speeding up the growth at expense of your users which is of course sugarcoated as "it is good for you"

> speeding up the growth at expense of your users

Rather at the "expense" of Amazon AWS

Re: Licensing changes to Elasticsearch and Kibana

#354
post #161
post #155

Earlier quoted context omitted.

I feel this way about all similar licensing changes (Redis, Elastic among many others). It's basically a large company vs much larger company fight, and the losers are the thousands of individual contributors not affiliated with either one who have worked for free and can no longer use their work in the way they want. Moves like this are definitely eroding trust in open source in the long term.

There's a fair amount of hyperbole in that statement. Most of the above products (Redis, Elasticsearch, MongoDB, etc.) don't have "thousands of individual contributors" and are developed primarily by employees of the backing companies. Second, external contributors can use it in their work in any way that they want so long as it's not in offering Elasticsearch-as-a-service. They can even use for offering Elasticsearc…

The quantity of the individual contributors seems to be the only stretch you seem to be able to point out, yet you go further to trying to defend the SSPL license as limiting a very narrow set of applications - despite lawyers and open source advocates almost unanimously having said the license text itself is ambiguous enough to cover a much larger set of use cases.

If you are not a lawyer and if this is not legal counsel, I'd suggest you leave your personal interpretations of a license that is broadly considered to be less permissive than advertised outside of civil discussion.

>There are certainly valid criticisms of this decision, but

Why the but? Obviously this decision hurts AWS but it also hurts a much broader group than them.

Re: Licensing changes to Elasticsearch and Kibana

#355
post #318

Earlier quoted context omitted.

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

do you feel that the sspl is ambiguous on this point? if so, why?

After rereading the relevant section a few times, no, I think SSPL is fine for our use.

EDIT: I should say for our current primary usecase. It does look like this would make it awkward for us to expose grafana to clients, but that's a narrow case and/or one that I suspect you'd intend to be in-scope for virality.

Re: Licensing changes to Elasticsearch and Kibana

#356
post #38
post #32

Earlier quoted context omitted.

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.

I don't think it's really that different. Elastic did that same thing about three years ago when they made all of their enterprise-only features source-available ( https://www.elastic.co/blog/doubling-down-on-open ). Timescale also made their enterprise features free of charge, but that's a business decision rather than a question of licensing. It's because their revenue model is based completely on their managed clo…

Is this an elastic employee throwaway? How is going from a more permissive license to less permissive one "not really that different" than the inverse?!

Re: Licensing changes to Elasticsearch and Kibana

#357
post #253

Earlier quoted context omitted.

Everyone wants to open source their code until someone else makes a billion dollars of it. Everyone wants censorship resistant end to end encryption until terrorists use it. Everyone wants software patents to not exist until they get issued a really good one. This is a classic case of trying to put the genie back in the bottle.

Number 2 and 3 are false. Edit: I want e2e encryption but not censorship resistant, not when it starts getting used for inciting to violence. Search for eg "WhatsApp lynch mobs" or "Facebook Myanmar genocide".

It seems unclear what you mean by 2 and 3 being false - plenty of folks want those things.

Re: Licensing changes to Elasticsearch and Kibana

#358
post #244

Earlier quoted context omitted.

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.

It's only a "problem" for the 0.001-% who choose to view it that way. There's decades worth of large/serious/complex open source projects that have totally been monetised by other companies without the founders/maintainers feeling ripped off and butthurt about it. Linux, GNU, Apache, Perl, Python, PHP, Rails, WordPress, and many many more projects at least as important and complex as Elasticsearch. We don't hear Linu…

Almost all the examples you give are GPL. That is the only license that protects the freedom of your software. Any 'permissive' license can be converted to 'private'. Too bad nobody really understood that for the past 20 years.

Re: Licensing changes to Elasticsearch and Kibana

#359
post #34

Earlier quoted context omitted.

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…

This "We need it for survival" is bullshit. With Elastic being public company you can see their revenue growing 60% last year.... with Apache 2.0 license. It is not the case what we've been loosing revenue for years due to AWS competition and this is the last action of the last resort. This is simply about speeding up the growth at expense of your users which is of course sugarcoated as "it is good for you"

I wish comms were more honest about this, they'd earn more trust than just telling the community SSPL is now an OSS license despite what OSI has shot back about it, and that this is some type of necessary evil.

Re: Licensing changes to Elasticsearch and Kibana

#360
post #323

Earlier quoted context omitted.

I don't think it's reasonable to attribute motive to the contributors in this way. Changes like this protect the elastic enterprise, whether they align with the motives of contributors would have to be evaluated on a per-contributor basis. I've made several contributions to ELK, and my only motive has been that it's useful open source software, and I want to make it more useful. I personally don't care who profits of…

that's one of the things that bugs me, old contributions like yours have the apache license, can they modify without your approval?

Legally, I’m sure their contributor license agreement gives them the full rights to do that. Which was my understanding at the time. I’ve contributed to lots of projects that have them, and I likely will again in the future.
Post reply on HN