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).
Licensing changes to Elasticsearch and Kibana
351–360 of 378 posts
Re: Licensing changes to Elasticsearch and Kibana
#352Earlier 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
Non-elastic pull requests are merged, as I mentioned in [1].
Re: Licensing changes to Elasticsearch and Kibana
#353Earlier 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"
Rather at the "expense" of Amazon AWS
Re: Licensing changes to Elasticsearch and Kibana
#354Earlier 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…
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
#355Earlier 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?
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
#356Earlier 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…
Re: Licensing changes to Elasticsearch and Kibana
#357Earlier 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".
Re: Licensing changes to Elasticsearch and Kibana
#358Earlier 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…
Re: Licensing changes to Elasticsearch and Kibana
#359Earlier 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"
Re: Licensing changes to Elasticsearch and Kibana
#360Earlier 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?