Luckily there are faster and smaller alternatives in Rust for the ElasticSearch - Toshi[1], Meili[2] and Sonic[3]. In the age of Rust there is no need to use JVMs overhead.
[1] https://github.com/toshi-search/Toshi
Licensing changes to Elasticsearch and Kibana
61–70 of 378 posts
Re: Licensing changes to Elasticsearch and Kibana
#62Earlier quoted context omitted.
I thought Grafana was doing great with its managed offerings. Personally I'd prefer you consider BSL before SSPL since it's usually clearer to most people.
at grafana labs, we are still pretty torn on what our go forward licensing regime should be. bsl is interesting, but license proliferation and familiarity is a big factor to consider. now that both elastic and mongo are both using sspl, it is more appealing. i think tsl from timescale is also a great and well thought out license.
I like Grafana and I wish you the best. Source-available to me is basically FOSS unless I want a free ride off your hard work.
Re: Licensing changes to Elasticsearch and Kibana
#63Earlier quoted context omitted.
I'm wondering how this affects the distribution of x-pack. From what I'm reading, the new Free model probably includes it and we have to turn it off if we don't want it? I wish there was still an x-pack free distribution in this model.
Since the entire Elasticsearch codebase is now under SSPL, there's no more distinction between the former Apache-2 code and the x-pack code.
Yes, I understand that, but what I would like is a distribution without any x-pack code. I don't want to have to figure out how to turn off and remove x-pack. What I'm concerned about is that it's another vector for security vulnerabilities that I don't need.
Re: Licensing changes to Elasticsearch and Kibana
#64In my mind, this strongly constrasts with the words [0] of WordPress founder Matt Mullenweg. He says they want to own roughly 5% of the WordPress market, and instead of growing their share of the pie, grow the pie itself.
Re: Licensing changes to Elasticsearch and Kibana
#65I hope that SSPL becomes the standard for companies so that at least it becomes a known entity instead of a proliferation of bespoke licenses: like if CockroachDB moved to it as well. Personally, I'd rather see a more aggressive AGPL where REST calls are considered linking and trigger virality and I believe that would meet the definition of open source by the OSI while preserving the value of the commercial version.
>Personally, I'd rather see a more aggressive AGPL where REST calls are considered linking and trigger virality
Please don't compare a license to a virus. In any case, my understanding is that the AGPL does cover this and is why it exists. If it didn't cover this it would be useless.
Re: Licensing changes to Elasticsearch and Kibana
#66Earlier quoted context omitted.
contributing back can mean monetarily. i’m sure elastic would be willing to sell a commercial license to a cloud provider if the deal makes sense.
Thats fine, but then don't title the blog post "Doubling down on open", make it "Creating a more profitable business model".
Those aren’t necessarily contradictory titles. Large OSS projects require funding, or they run a serious risk of stagnation. If there are massively profitable corporations using OSS and contributing nothing back, or even actively competing with the project, then a more profitable business model may be the best thing an OSS project can do to ensure its longevity.
Re: Licensing changes to Elasticsearch and Kibana
#67In my mind, this strongly constrasts with the words [0] of WordPress founder Matt Mullenweg. He says they want to own roughly 5% of the WordPress market, and instead of growing their share of the pie, grow the pie itself. [0] https://fs.blog/knowledge-project/matt-mullenweg/
Is this because the Wordpress market is huge (almost every website)? Whereas Elastic, Mongo, etc market share is not as huge?
Re: Licensing changes to Elasticsearch and Kibana
#68Luckily there are faster and smaller alternatives in Rust for the ElasticSearch - Toshi[1], Meili[2] and Sonic[3]. In the age of Rust there is no need to use JVMs overhead. [1] https://github.com/toshi-search/Toshi [2] https://github.com/meilisearch/MeiliSearch [3] https://github.com/valeriansaliou/sonic
Adding Typesense to the list as an easier-to-use alternative to ElasticSearch: https://github.com/typesense/typesense
One thing to point out though is that Typesense, MeiliSearch (and Algolia) are designed for Instant Search experiences, and so hold the entire index in memory. So for petabyte scale data (like logs) it might be wasteful (and expensive) to store that size of data in memory. This is where ElasticSearch shines and of course comes with it the overhead of managing it.
Re: Licensing changes to Elasticsearch and Kibana
#69There are some small-scale ES search-as-a-service providers that serve small and medium businesses.
There are also service providers whose core service is something entirely different and just use ES as the backend for their search APIs.
While the target is AWS (and I think what they are doing to service providers like Elastic and MongoDB is terrible), I think this will also adversely affect overall ES usage by many other companies.
Re: Licensing changes to Elasticsearch and Kibana
#70Earlier 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…
It's a vocal minority that slings the hate. There are tons of people that appreciate open source with exceptions to prevent managed offerings by cloud providers as long as self-hosting to support your own stuff is allowed (including ability to customize/extend/patch). I for one will (with a few exceptions) only pay for a product that is open source (at least enough so that I can self-host for my own product if I want…
> It's a vocal minority that slings the hate.
That's usually the case.
> at least enough so that I can self-host for my own product ... Vendor lock-in is a serious problem
I'm leery of vendor lock-in myself. Self-hosted will be the only way to run my product in the beginning, and the cloud service will follow when it's popular enough to make sense.
> May I ask what your product is? Just curious :-)
I haven't published the website yet (it will be at https://flowstate.dev), but it's a framework/runtime for building backend APIs using SQL and JavaScript. It lets you run SQL queries from the browser, among other things. Which sounds crazy, but it actually works well. Once I have a hosted cloud service it becomes a backend-as-a-service platform kind of like Parse or Firebase.
I'm not against open-sourcing it down the road, but it can't be an OSI license, and I'll wait until it's big enough that I'm less worried about competitors just lifting my source code. I know copyright laws protect against that, but that only matters if you have the resources to litigate.
I do want my users to be able to dig into the source if the documentation is lacking, and also to patch/modify it if they need to - so I need some kind of source-visible license down the road. I think I would also add a clause that if the company goes under or gets acquired and shutdown then all source code gets published under the Apache 2 license.