311–320 of 378 posts
Honestly, every relevant FOSS project should adopt a similar license to prevent exploitation from corporations.
Every project can choose it at the beginning if they choose. But it will tremendously hurt adoption and community.
Earlier quoted context omitted.
Also, why is SSPL not open source? As far as I can tell, it mostly just seems like the APGL, but taken to 11. I can definitely appreciate why it's a problematic license, but I don't think "not open source" is its problem.
It seems it has neither the OSI's blessing as an Open Source licence, nor the FSF's blessing as a Free Software licence. Can anyone comment on why not, given that the AGPL has the blessing of both organisations? edit Here's an informative StackExchange comment. [0] Apparently it's a good deal stricter than the AGPL, and introduces much more legal uncertainty. [0] https://opensource.stackexchange.com/a/7523/
Elastic obviously does not publish their own management infrastructure code under SSLP, so the reason for this license to exist is to make the playing field uneven as opposed to all the other free software licenses.
Basically, they can benefit from your code on top of and around ES, while you can't from theirs. This is actually the result of dual licensing but with other free licenses, at least the symmetry is maintained for the core product.
I am not making a judgement call here, just explaining what the distinction is.
Earlier quoted context omitted.
I know it’s not competing with permissive licenses. That’s my point. The people here acting like the fact that companies are profiting off of Apache 2.0 licensed code are being unreasonable was my point. Separately, I think this move will just hurt Elastic Co in the long term. The organization I work for runs a 30 TB elastic cluster and we’re going to have to go drop Elasticsearch because of this change because we’re…
Good luck with a lot of wasted work power because you are sad that "big Corp" can't exploit anymore "small software house". Please, this is ridiculous. Anyway, I'm sure many others like me are sympathetic to the cause and will support companies like elastic that take this kind of decision. I don't think elastic will miss you.
So, I hope you enjoy taking the holier-than-thou stance. It must be nice up there.
Earlier quoted context omitted.
And guess what, when a corporation uses Elasticsearch in a serious way they will inevitably end up contributing back. It's actually easier to just get a change merged upstream rather than to manage a whole fork, unless the upstream is really hard to get patches merged with. The whole narrative of "company X is offering Elasticsearch as a service and not contributing back!" is ridiculous. First of all, the whole point…
>First of all, the whole point of free software is that somebody somewhere is going to be making money with that software, and that's okay, regardless of contribution. No, the point of free software is that users of the software have the freedom to use the software, redistribute the software, modify the software, and redistribute modified versions of the software. Someone making money using those abilities is inciden…
Earlier quoted context omitted.
Exactly! I've used AWS' service, it's awful. Elastic's is better, and price is comparable or better in fact. But the point is they don't even have to compete on price if quality is superior! If I'm spending $100k/mo on my logging stack, and it's falling over frequently (which in AWS-land means multiple days of back and forth, opening tickets etc), I'd way rather pay $120k/mo for something that actually works.
> If I'm spending $100k/mo on my logging stack, and it's falling over frequently I do the same and AWS ES works fine. I did try Elastic, performance was bad. They run it in containers internally!
Of course, my company was willing to pay $100k/mo to log every SQL query in existence but wasn't willing to pay for AWS support (of course it would have required paying something like 1% of our TOTAL aws spend, not just aws elasticsearch, although we could have probably created a subaccount or something)...so maybe the experience is different if your tickets actually get answered.
What was bad about performance in particular? You were just seeing less throughput per dollar spent or what?
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 [2] https://github.com/meilisearch/MeiliSearch [3] https://github.com/valeriansaliou/sonic
Earlier quoted context omitted.
Or they could, you know, just respect the new license and publish their changes and part of their "secret sauce". I bet it would be anyway tightly coupled to other AWS internal services so nobody would get hurt in the process. Edit: fixed typo
what layers would they have to show? All of them up to bare metal? This is madness, should you be able to show your UEFI firmware? Should the server's out-of-band-mangement firmware be available as well? The license is plain vague.
Anyway I agree that the license is too generic and can use some more details but IMO it should basically cover all the automatism you explicitly create to manage the software you are selling access to. I mean, there is no need to publish the secret sauce for EC2 because it exists anyway and it's publicly available anyway.
To sum it up, I'm not against the spirit of the license but I agree the implementation should be better.
wow, this is super interesting, but i can't say i'm surprised by this move. the landscape has really evolved over the last few years for companies trying to build a business around open source. at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. all of our peers (eg. mongodb, elastic, redis, confluent, cockroach,…
> 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".
Everytime an open source project changes it's license to protect against cloud services not "paying their dues" a lot of people say it doesn't matter because the company will only go after the cloud providers, the big players, and if you just use it internally it won't affect you. I think people forget that these companies might be bought in the future by Oracle.
Earlier quoted context omitted.
what do you mean by "hard-fork" ? I thought that open distro is "hard-fork" but licence stayed apache https://github.com/opendistro-for-elasticsearch/
Opendistro is primarily a set of plugins for the stock APL ES distribution, not a fork of elasticsearch proper.
Correct me if I'm wrong, AWS ES service still uses ES free licence but they've re-written the plugins so they won't use ES and pay ES fee?
With new licence, AWS won't be able to use ES as SaaS?