Licensing changes to Elasticsearch and Kibana
elastic.co
elastic.co
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 the cost of development to your competitors so you can increase your market share. That's it .
Maybe that is too cynical, but I recently went through a license shift (GPL to Apache) with TerminusDB and we were clear that honesty about motivation was the best formula for comms.
I feel so much for the hundreds of open source developers who toil everyday only to have AWS make so much money out of it, to make the largest shareholder the richest man on earth, while contributing nothing back to any of the open source projects. This has to be fixed or we will see less and less developers open sourcing quality products
* can I inspect source and build it myself?
* can I fix it?
* can I share modifications with others?
Many of the new "cloud protection licenses" offer this, yet they are (by definition) not opensource.
That's your opinion, of course. IMO, there's a type of magic that happens when software is under a truly non-restrictive license. You get a level of quality and reliability in the software that is unmatched by what you get with any proprietary equivalent.
Unfortunately, most people don't really believe in FOSS. And that's okay. But boy am I getting frustrated with these companies that are happy to preach about how "open source" is amazing, until someone else is making some profit with their software and then suddenly the (extremely vague) restrictive licenses start rolling out.
I remember reading (alas, I can't find my source) a spokesperson for the OSI admitting to the existence of licenses that meet the OSD that they don't want to be OSI-approved because they don't add enough value versus the cost of proliferation of licenses that are substantially similar.
[1] https://www.debian.org/intro/free
But I read them and couldn't find anything addressing fields of endeavor. GNU's "four essential freedoms", which imho are a little naive in retrospect, don't say anything about this. They say anyone should be able to "sell copies", but SSPL doesn't disallow this either.
Debian obviously didn't address it either. They clarify: " They can even try to sell it. In practice, it costs essentially no money to make electronic copies of software. Supply and demand will keep the cost down."
I.e. they only allowed it because they thought the free market will take care of it, and didn't imagine how cloud provides will become monopolies of access.
"As a result, you can buy a Debian release on several CDs for just a few USD." - Lol.. that's like trying to apply lessons from the bible to modern life.
Just to broaden the discussion, "fields of endeavor" doesn't just mean cloud services, but also whether you can prevent your software from being used in weapons, or other such morally objectionable applications.
"The freedom to run the program as you wish, for any purpose."
That clearly includes purpose of running the progam as a cloud service and profiting from selling it SaaS-style to third parties.
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 off the codebase, I think anybody should be free to. I personally would object to anybody trying to lock down how it can be used, and would see any attempt to do so as running completely counter to my personal motivations as a past contributor.
Which is exactly what I see Elastic doing here.
This x 10000. I couldn't agree more, thanks for putting that so clearly.
Frankly, I think a number of people in the Open Core movement have a psychological hangup around profit. They feel that if a company - particularly a large corporation - is making money using their software without "contributing back", that that should not be allowed. Well, if you don't want to allow it, fine, but don't pretend you're in the business of releasing free software - you're not. You want to be in the business of proprietary software, since only proprietary software lets you say "hey I don't want Jeff to profit off of my work without paying my for a proprietary license".
Substitute AWS for "a software developer" and see if you feel the same way.
> I feel so much for the hundreds of open source developers who toil everyday only to have other software developers make so much money out of it... while contributing nothing back to any of the open source projects. This has to be fixed...
I'm also happy to see small start-ups rise faster by using my software.
But if those theoretical start-ups, whose business wouldn't exist without my software, grew to dozens of employees, made millions of dollars, and still I wouldn't see a nickel.. That's when I would start to wonder, why am I doing this for free?
Incidentally, the bigger the company, the less likely it is to contribute back.
To conclude, that sounds like false equivalency to me. It does matter who is using it for free and profiting.
AWS does / did contribute patches to Elasticsearch.
The problem Elasticsearch has is, AWS shares none of the gigantic profits it makes from its Elasticsearch Service, which is a double whammy because it cannibalizes Elastic's own SaaS offering.
> To conclude, that sounds like false equivalency to me. It does matter who is using it for free and profiting.
You mean to say, Facebook must share a % of its WhatsApp profits with ejabberd, or ejabberd otherwise is right to SSPL their software?
Or, Google pay Oracle a share of the spoils because it is an "app container layer" on top of Java/JVM? And that Oracle is okay to switch to SSPL otherwise in search of those dollars?
Or, okay if CnFdn SSPLs k8s?
Also, if it matters whoever profits contributes back monetarily, may be the right way to do so would be via a Foundation. Using the Commons Clause or SSPL is not the answer, in my eyes.
See also: http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...
That's a meaningless statement, since it could just as well mean that they contributed back 2 hours of work.
> * is okay to switch to SSPL ???
Yes, absolutely. Why not?
The article you linked doesn't mention anything about foundations. But let's agree not every open-source project can become one.
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."
(1) It's interesting how much of the reasoning/argumentation for these restrictive licenses ultimately comes down to a more articulate form of "but that's not fair!". I also wonder how much the implicit beliefs that "unrestrained capitalism is a bad thing", "markets naturally lead towards monopolies", "antitrust law is legitimately necessary", etc are impacting peoples' reasoning here.
(2) If they can't actually compete and provide superior value to whatever managed offering Amazon can scrounge together, that's actually their fault. AWS' managed elasticsearch offering is absolutely terrible, speaking from experience. They block access to important APIs like `reroute`, any minor cluster change results in a whole blue-green deployment which very frequently hits a race condition that prevents the newer cluster from ever coming up healthy, requiring a ticket to be filed that takes multiple days to respond to if you don't have premium support, etc.
So functionally the idea that AWS is going to fleece them because they'll offer a just-as-good service for cheaper has not been the case. Elastic co's managed offering is simply far superior.
---
Ultimately, Elastic has shown that they don't actually want to release FOSS. They want to release proprietary software, and that's why the (in hindsight very easy to foresee) usecase of a cloud provider offering a managed service angers them so much. They don't really breathe the FOSS mindset, because a true non-restrictive license (BSD, Apache 2.0 etc) means that a company can absolutely use your software to make money and that's okay.
Anyway, Elasticsearch is incredible software and the Elastic team has made something truly incredible. I just wish they had a vision for monetization that aligned with their open-source beginnings. It's clear that they don't, and the sooner they stop pretending they're offering a free or open-source solution here, the better.
The sad-funny thing is that elastics hosted cloud offering is clearly superior to AWS’ hosted elasticsearch in pretty much all regards.
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.
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?
Yea, I got bit once by one stuck blu-green. Root cause was zero free disk space, I now keep it at 25%
And we do pay for tech support, im in luck here :)
The primary issue that leads to that is that the stock open source elasticsearch distribution (APL licenced) does come with no security at all. It even used to be the case that even the most basic security was a plugin that required a paid license. That changed only after AWS released the opendistro set of plugins with a free plugin to add security - after that, elastic offered a basic (free as in beer, but still non-free as in freedom) license that would include security. Additionally, the early ES versions would bind to all IPs by default, so just starting the server would make it available from outside. If you weren't expecting that and no firewall was protecting you, your ES cluster would be available from the outside with not authentication.
Both AWS and elastics hosted offering come with a configured security plugin, so that at least makes it harder to leak data. Obviously, even with authentication you can still leak credential or such.
I really don’t understand how that business model works.
If AWS didn't take the work of Elastic those customers might have used Elastic's services instead.
How can AWS offering the same thing not be competing against Elastic's offering?
It's similar to bundling tactic of Microsoft, and other big vendors. By bundling MS Teams with other things, no one has to "buy" Teams, they already get it for "free" (well, it's no extra cost beyond what they would be paying for Office or whatever already), so why "buy" Slack when you have a similar chat tool for "free".
I have no issue with whatever license they choose, but let's be honest, its not about contributing back to these projects, its inserting a poison pill clause that they know cloud providers can't meet.
Specifically, by contributing back they mean, per the license: "If you make the functionality of the Program or a modified version available to third parties as a service, you must make the *Service Source Code* available via network download to everyone at no charge, under the terms of this License."
Lucene is licensed under the permissive Apache license which is why Elastic is able to release proprietary paid modules that link with it.
Now they are closing the same holes that they themselves used to create their product. Contributing back is definitely the last thing on their minds.
Red Hat (my employer currently) is typically in the same boat here and it drives me crazy how people don't think about that before criticizing.
People love to say, "Red Hat couldn't exist without <project>" which is true, but what they don't realize is that a ton (sometimes all) of the development of that upstream project is done by Red Hat employees. Without that a lot of projects may not even exist.
There are no doubt "open source" companies that take more than they give, but it's a little more nuanced and complicated than people make it out to be.
The whole narrative of "company X is offering Elasticsearch as a service and not contributing back!" is ridiculous. 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. Second of all, in practice companies like Elastic will always exaggerate the extent to which corporations aren't "contributing back".
What they really mean is Amazon isn't contributing financially to Elastic Co. That's what they're pissed about, and that's why they clearly wish they were actually in the business of proprietary software (which they now are)
The thing is "really hard to get patches merged" is a fuzzy barrier. There are many, many example of what most would consider reasonably maintainers where companies just don't contribute back. Even in breach of GPL.
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 incidental to the actual goal.
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 proprietary license. Because it seems you're damned if you do and damned if you don't. At least commercial closed source products don't attract this kind of criticism.
It gets more code into the open, where's the disconnect?
If something satisfies the four freedoms [0], it is free software.
Nonetheless I don't agree with the GNU's claim that copyleft doesn't reduce freedoms. Of course a permissive license provides more freedoms: it's right there in the name
But this issue isn't really about permissive vs copyleft licensing anyway: Had Apache used a copyleft license with Lucene, Elasticsearch would have never existed.
Lucene is a library, you can hardly offer it as SaaS. It's gluework.
On the other hand, Elastic is much more enduser software, which is much more routinely abused for SaaS hosting by larger corporations.
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 should things change). Vendor lock-in is a serious problem and concern for many, and open source is how you address that concern. The best example is GitLab, which gets a ton of money from me that would otherwise go to GitHub (which I like better) if GH were open source.
By going proprietary you avoid the vocal minority on the internet, but you also (silently) shrink your potential customer pool. Especially with the AWS/Parler stuff, there are even more people that want the option to self-host in case they get de-platformed if the Overton Window continues to shift.
May I ask what your product is? Just curious :-)
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.
Rather at the "expense" of Amazon AWS
Edit: Not a lawyer!
- no impact on the overwhelming majority of our user community
- no impact on our cloud customers or self-managed software customers
Also, this helped calm my nerves: https://www.elastic.co/pricing/faq/licensing
> [...] 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 cutoff line for "substantial motivation" ends.
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...Providing Elasticsearch as a service means allowing people to upload their own data and giving them an Elasticsearch instance to search it.
There's some grey area where it's a question if you're providing an application with a search feature or just hosting Elasticsearch. Like if you provide a way to upload logs and then search them that's Elasticsearch as a service. But if you provide an automated upload, is that enough?
For my side project, I am using a dual-licensed MIT/Apache (your choice) but with an exclusion which prohibits companies like AWS from offering it alone as a service. Here's a copy of the (quite human-readable) license:
https://gist.github.com/slimsag/2164520b9e249fbae4e08e2bdf6e...
But I think it's unfortunate that companies end up with licenses like SSPL which are lengthy, not legible to non-lawyers (see this thread) and more importantly ambiguous in favor of the SSPL-software-provider. It's only natural, that's what lawyers are hired to do, after all! But I think there are other options (be ambiguous in favor of the opposing party, or build upon existing licenses)
Yes, and if you let your internal company blogging platform ping a service upon every new post, which then feeds that post into Elastic so blog posts across your company are searchable?
I suspect one way to avoid this would be “buy a commercial license” (or use Amazon’s fork if you’re so minded), but if you’re using Elastic’s open source offerings — I’d be careful about licensing anything under SSPL, whatever your intentions are.
If you add search to your webapp using ElasticSearch, you typically would not be modifying it, and so any source distribution burden that could possibly be compelled from you in a worst-case scenario would be for the unmodified source code that you freely downloaded from a public website. No local modifications? No violation of terms. End of line.
While that's a slight risk of having more burden than not having to provide that source code, it's not like it contains anything proprietary, because you probably aren't modifying it anyways — and once you divulge that source, it's proof that you not only did not violate terms, but could even request legal fees.
So whether or not this search usage would qualify, which can only be definitively decided in a court of law, your actual risk of harm and exposure is none whatsoever — unless you have proprietary patches to ElasticSearch and you aren't already sharing them openly in a GitHub fork. (I'm not your lawyer, etc.)
That seems a very pessimistic / overly conservative interpretation to me. They are clearly shooting for people selling Elastic itself as a hosted service here. Your client facing report being "Elastic Software or the features and functions of the Elastic Software" is unlikely to fall into "reasonable interpretation" space IMHO.
> 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 a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal. There are those who will point to the FAQ for the SSPL and claim that the license isn’t interpreted in that way because the FAQ says so. Unfortunately, when you agree to a license you are agreeing to the text of that license document and not to a FAQ. If the text of that license document is ambiguous, then so are your rights and responsibilities under that license... This ambiguity puts your organisation at risk.
See also: http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...
Or my monitoring? Deployment and management in kubernetes for example?
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/
Also HN: Don't be a knob and F/OSS your core product if you plan to make billions or whatever.
They're doing exactly you want: picking a non-free license for their core product, and you're still mad at them.
1. Avarice: They rode the FOSS wave and gained industry mindshare for a conveniently long time. Now, after making (well deserved) millions on the back of it, they turn to an absurd license to basically say, fuck you, looser, I need my billions.
2. Hypocrisy: Spinning the whole thing as "doubling down on Open" with a source-available license. One must be so delusional to call out "naysayers" as spreading FUD about SSPL when the fact remains that SSPL is a landmine.
3. Short-termism: It is all fun and games till Elasticsearch is wealthy and healthy. Once some PE firm takes over when they get pushed into a corner, I can see them doing Oracle-esque law suites even if it isn't their current intention.
If their core product was Elasticsearch, they could have SSPLd it from the start. I'd be curious to see where they'd have ended up then. I'd absolutely not have been upset in this scenario.
The current scenario is what we are in, lets see how it pans out.
It doesn't impact your devops pipeline or your monitoring workload(s).
Link to FAQ: https://www.elastic.co/pricing/faq/licensing
https://news.ycombinator.com/item?id=25782849
https://news.ycombinator.com/item?id=25784581
The ambiguity is the problem. Yes, the FAQ/A Developer/A Company has said they really mean (A), but the license text, which is the legally binding part, is ambiguous. Even if a judge supports the freest reading of the license, you have to go through the time and resources to get in front of a judge.
For FOSS, this means the majority of projects that run on a scattering of donations + developer free time are dead in the water the first time someone tries to hit them with a Cease and Desist or similar.
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?
Btw, note how MPLv2 FAQ page clearly points out that the FAQ doesn't give anyone a license to freely interpret the license itself:
> ...while this FAQ is intended to be accurate and helpful, it is not the license, and may not cover important issues that affect you and your specific situation. As a result, reading the FAQ should not serve as a substitute for reading the license itself, or for seeking legal advice from a lawyer.
The overhead to those relationships for what they do offer is significant.
Nah.
Choosing something else - at least if you can do it before getting locked in.
Didn't go well.
I wouldn't even ask for a legal review of this new Elastic License, if I thought I could tear it out for less than 2 dev-months of effort.
SOLR?
My (non-lawyer) experience tells me the same, judges don't like people who try to argue one thing to a judge while clearly documenting on their website the opposite isn't going to go well, but as others pointed out that doesn't make it a smart choice to depend on, or that corporate lawyers will agree is worth the risk.
But what if they only sent me a link to the FAQ or I just silently relied on it to be accurate?
It is much cheaper if both sides are willing to stipulate that they are in agreement with what the terms mean. Then you can get to fact finding and settlement talks with less upfront cost.
As a business person, I'd prefer to avoid the legal expense and risk to find out the hard way later on. Who knows who'll manage ElasticCo 5 years down the line and whether their motivation may be to milk their IP through litigation. Do you really want to be the guinea pig? The smart business move would be to either license explicitly OR stick to the Apache 2.0 version and plan a migration off ElasticSearch
Google did zero offers back it was still unclear who would save Sun, most likely hoping that they would just sink away.
Eventually Oracle and IBM came into the picture, and still radio silence from Mountain View.
So yeah, they get what they deserve.
As for links, the press of the day.
> If you make the functionality of the Program or a modified version available to third parties as a service... (license conditions apply)
> “The Program” refers to any copyrightable work licensed under this License.
IANAL, but that seems pretty cut and dry referring to making an Elasticsearch or Kibana service
> 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, offering a service the value of which entirely or primarily derives from the value of the Program or modified version.
and IMO (IANAL) that would put some of the services that offer log ingestion / indexing / querying in legal gray area.
I do empathize with the desire to safely open their code for all/most users and their attempt to use SSPL to do it. For Graphistry, we ended up going proprietary for our core GPU visual analytics and went open for more generic infra and client codes, e.g., launched one of the Apache Arrow languages and our popular Python/Jupyter lib. I'm still looking forward to the day we can open our core as well (all our $B/$T partners ask us to, and yet ;-)). Encouragingly, our users are increasingly preferring the marketplace + saas versions, so I remain optimistic about an SSPL-ish license. That 90%+ of ES users go with SSPL is promising!
> 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, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
From what I understand the big question is, where is the line on if value is derived primarily from "the Program", and what exactly constitutes modifying the program.
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.
So to later turn around and say "hey we never envisioned Amazon et all turning around and selling Elasticsearch as a service" is looking at it backwards. When you release something under Apache 2 (or a similar non-restrictive license) you're intentionally telling people to do what they want with it.
Anyway, my thoughts on these kinds of situations is that it usually implies there's some disconnect between how Elastic Co wants to make money versus how they actually are making money.
---
There's a related issue of open source maintainers/devs feeling "exploited". Now while having users submitting issues with unfortunate tone/wording that implies that you're obligated as the maintainer to spend your time fixing their issues is frustrating, it's also part of the game. I'm getting really frustrated with the whole "it's not fair that company X is using my free software without contributing back". That's literally what you agreed to have happen when you released under a non-restrictive license!
If you want a restrictive license, that's fine, but don't release under Apache 2 or BSD and then turn around and act shocked when people use your free software for free. It is unreasonable to put something out there for free and then suddenly expect money for it. That doesn't mean that companies shouldn't be contributing back to software they rely on - that's a no-brainer as far as I'm concerned - but it does mean that nobody should be surprised when someone does choose to "consume" software without contributing back.
Elastic are of course entirely entitled to change the license to whatever they feel like, including closing the source entirely for future development. But they made the choice at an earlier stage to release the code under a permissive licence - that was a choice to allow others to do what they want with the software, not just “what you want so long as it doesn’t infringe on our business model”. They are free to change their mind on that, but it’s not like it’s an unexpected, unfair, or unpredictable outcome.
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 Linus or Stallman, or Larry or Guido or Rasmus or DHH or Mullenweg complaining about hosting companies profiting off their work.
I get that newer projects are structured differently, and that companies like Redis Labs and Mongo and Elastic are paying salaries to engineers to develop their software - which is _way_ different to the examples I cited above. But just because they've chosen that, doesn't mean they're "right" or entitled to succeed working that way. The optimist in me hopes some of them will, and perhaps this will be a route to the world getting "open source" software written that the old Apache project's model perhaps could never have achieved. I certainly don't think that's a given though.
The pessimist in me feels bait-n-switched, and is wondering how to plan on staying on 7.10 safely and keeping an eye out to see who's gonna fork it and at least keep up security work on it under Apache 2.0 moving forward. We don't "sell Elasticsearch as a service", but we use it enough that I don't want to ask for legal budget to mitigate the risk of upgrading away from the Apache 2.0 licensed version. I don't trust SSPL enough to want use anything licensed that way, and I doubt I'll be very happy with Elastic License either if I spend enough time to read/understand it properly...
I wonder how many companies would be willing to pay $100 a month for their elastic search to continue to receive security updates... in theory the right individual could make a decent living simply forking the various OSS projects that have since gone noSS, applying security fixes, and collecting money from the companies build on them.
This is a classic case of trying to put the genie back in the bottle.
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".
NLP locally in the phone -- an AI that slightly understand what the user writes -- and if it's (I'm oversimplifying) like "kill all ...", then the AI bricks the phone.
Otherwise it's e2e as usual.
(But I guess I'd taken Elastic's approach and switched to SSPL)
About 2: i replied here: https://news.ycombinator.com/item?id=25798359
I am quite sure they are open to a reciprocal licensing agreement with AWS et al.
Trying to determine what offering as a service is or implies is a bit difficult. If Discord used it to enable full text search, does they need to release their management layers too? Why or why not? How excited to defend your rationalization/decision to the court are you, if some disagreement arises?
The ask, that companies open source their management layer, concerns me because it's unclear in many circumstances what does & doesn't need to go into that box. A management layer is often a rather sprawling piece of software. Trying to disentangle & release the Elastic Search or Kibana management layer from the other management /deployment/control systems could be quite onerous.
I do think the intent is not "bad", but it's so hard & murky, there's so much peering into the crystal ball to guess whether, some day in the future, a once "open source" company that may, a decade down the road become aggressive/ligitious (not presently the case!) continues to find your particular use does or not does qualify as offering the product as a service, and does or does not expose you to a long complex obligation.
GPL does not clearly define where the boundaries of a program is, but there is a fair bit of basis in the GPL FAQ and other writings from the FSF that suggesting that in their opinion, if I write a program B, that specifically depends on program A, then program A and B is part of the same program, regardless of whether or not it is linking in terms of C or if it is using it over the network.
https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation : What is the difference between an “aggregate” and other kinds of “modified versions”? (#MereAggregation)
> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
In that case, B specifically depends on A (for filtering functionality), yet is still (likely, IANAL) considered a mere aggregate as I read things.
If so, why bother leaning into the word "open"? Just call it freeware.
> So essentially, anyone is free to modify MongoDB. It’s only when you offer MongoDB as a commercial service that the conditions of the SSPL state that you must open source the entire service.
https://hub.packtpub.com/mongodb-withdraws-controversial-ser...
Is this a difference like GPLv2 and GPLv3? Does this means that AWS now must open internal service (probably not but I'm trying to be devil advocate)
Not an expert but usually F/OSS licenses are mainly about:
- Patent grants (either grants patent-use or doesn't)
- Copyleft (should modifications be open sourced. ex: AGPL is the strongest FOSS copyleft, whilst SSPL builds on it to make it even more stronger)
- Copyright (owners who are licensing the code)
- Warranty and Liability
- Terms of use (ex: FOSS licenses don't enforce restrictions on commercial use like CommonsClause does)
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?
Non-elastic pull requests are merged, as I mentioned in [1].
Now, it's very likely that many of them will stop contributing for versions 7.11 and up.
Ah right - makes sense.
> Starting with the upcoming Elastic 7.11 release, we will be moving the Apache 2.0-licensed code of Elasticsearch and Kibana to be dual licensed under SSPL and the Elastic License, giving users the choice of which license to apply.
So starting with 7.11 no parts of Elasticsearch will be released under an open source license.
They aren't making everything SSPL, though. Their paid features continue to be only available under the Elastic License.
So apart from adding the cloud non-compete clause (don't offer Elastic as a Service) there are many more restrictions added compared to Apache 2. For example I think linking can only happen with GPL3 code and it is copylefted instead of permissive https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...
- https://www.elastic.co/pricing/faq/licensing#im-building-plu...
Both permissive and copyleft licenses play important roles in the Open Source ecosystem. Different story are proprietary licenses.
However it seems that they will be moving the free modules which were previously only licensed under Elastic License to be licensed under SSPL instead.
At least, that is what this graph seems to be indicating to me. https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce...
Unless they plan to make those modules paid which were previously free, which I doubt
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, timescale, etc etc) have recently made moves to prevent being disintermediated by the cloud vendors.
it's become the new normal.
interesting times.
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.
it's definitely a nuanced discussion internally.
You have to give them respect for approaching things differently.
For a bit more background for the HN community:
When we initially launched the Timescale License in Dec 2018, we didn't relicense any of our Apache-2 code -- that was and has always remained licensed under the Apache 2 license. Instead, we effectively were "pre-announcing" that some future advanced features (yet to be developed) would instead be released under the Timescale License or under a paid-only commercial license (although still source-available).
Fast forward to September 2020 and Timescale 2.0, and we (i) made some aspects of the Timescale License more permissive (e.g., "right to repair", "right to improve"), and (ii) moved all the previously enterprise (paid-only) features to be available for free under the Timescale License. Hope that helps!
https://blog.timescale.com/blog/building-open-source-busines...
Happy (non-paying) user otherwise, but this is a bit shady in my eyes.
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".
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.
That doesn't sound like something incompatible with Open Source Initiative standards for "open source". And it sounds like something existing OSI-approved licenses could do?
And yet, SSPL is not OSI-approved, and they did not choose an existing OSI-approved license, instead the SSPL which they say "embodies the principles of open source", but isn't actually an open source license by accepted standards.
So... why? What's going on? What is this really about?
The press release of course doesn't answer the question "why not use an actual OSI-approved license"?
What they describe seems pretty similar to AGPL, which is a pretty inconvenient license for use in commercial products, but is OSI approved. What does SSPL do that AGPL doesn't, and what about it makes OSI approval challenging?
The OSI doesn't approve any license that "discriminates on fields of endeavor", which means you are not allowed to prevent cloud providers from competing with you with your own product.
Premium sponsors of the OSI include AWS, Google and Microsoft.
The AGPL is OSI-approved, and as I understand it also has a requirement "that if you provide the product as a service to others, you must also publicly release any modifications". (Possibly not "as well as the source code of your management layers", but that addition doesn't seem to post any additional problems related to "restrictions of fields of endeavor", I could see a future AGPL adding it, it seems somewhat the spirit of the AGPL).
What are the parts of SSPL that differ from AGPL in a way that OSI woudln't aprpove?
(The requirement about 'fields of endeavor' can be debated and is one of the currently more debated ones in OSI, but i my memory it goes way back in time to the early days of open source, I think you can probably find Stallman arguing for it before OSI even existed, I don't think it's there for some kind of nefarious reasons inserted by OSI sponsors. But certainly one can disagree with it.)
(Here's Stallman against fields of endeavor restrictions from 2013, definitely not pre-dating OSI, but I think this does go way back, and I don't think anyone thinks Stallman's opinions are bought by corporate sponsors, and Stallman is obviously quite influential in ideas about what open source is. https://web.archive.org/web/20130509151342/https://www.gnu.o...)
MongoDB already answered all these questions when they created the SSPL in the first place: https://www.mongodb.com/licensing/server-side-public-license...
(iirc they also wrote a lengthy blog post about it)
Seems to me that they have no choice but to hard fork off of the last Apache-licensed release of Elasticsearch et al
Horrible service. That’s why it’s ironic that Elastic just shot themselves in the foot with this licensing change. So foolish.
It is the AWS Elasticsearch Service that will be directly impacted. It will be limited to Elasticsearch 7.10.x as a foundation. Unless of course AWS makes available the code that they use to orchestrate and manage that service. Assuming that that code is sufficiently uncoupled from other systems, they could perhaps do exactly that. It would certainly be an entertaining counter-move from AWS.
IMO, the SSPL's cloud provision is a "Japanese No", it is so wide in possible interpretation, that only the Eclipse foundation could actually provide such a service.
Wrong. It only affects code going forward. Elastic can't change the license of existing code.
Although, I guess there will not be much of an incentive for Amazon to continue development of Open Distro after this change.
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.
And the more companies adopt SSPL, the more pressure OSI will be under to accept a viable license for open source businesses.
the osi has failed, in my opinion, for not approving sspl or something similar.
i respect them a lot less for it than i used to.
sspl does not technically impose any restrictions on any class of users; it’s just an extreme copy left license.
instead, osi spent a time arguing about mongo business model, technical capabilities, and sales tactics.
mongo eventually pulled their application to osi because (i think) they were so turned off by the process and politics.
That would be a horrible precedent. Sending an http request to a server should not trigger copyright violation. This is similar to newspapers who claimed that having links to their site, violates copyright.
I believe this is why the GPL uses the term "derivative".
> This is similar to newspapers who claimed that having links to their site, violates copyright.
Making links to their site might violate the license by which they allow you to browse their site, but it doesn't break copyright. If the on their homepage had a pop-up "You must agree not to not share any links found on this site as a condition of using this site" that would be analogous.
No newspaper has claimed that ever to the best of my knowledge, and it would make absolutely no sense to. What's being criticized is so-called "rich linking", ie. previewing content such as Wikipedia articles from search engines or news articles from aggregators without taking viewers to the primary source/site. People having a radical anti-copyright agenda have conveniently named this "rich linking" to dilute the discussion, as have news aggregators to downplay the issue.
As an aside, the way the EU copyright reform is being formulated into national law in Germany has been criticized as outright contrary to the whole purpose of the reform, and coming straight from pro-Google lobbyists [1].
[1]: https://www.faz.net/aktuell/wirtschaft/eu-urheberrechtsrefor... (in German)
> 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, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
Does this include services you don't charge for? For example I might offer services for marketing reasons. At what point is the service no longer primarily derived from the Program? For example if I build an application that offers query capabilities but does not expose the Program API, does that count?
For contrast GPL V2 worked because it tied virality to linking, which is pretty easy to validate.
That's why I never understood the point of SSPL. Is this exactly what AGPLv3 is supposed to be for?
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).
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.
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.
But yes that's effectively publicly releasing it.
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"?
I guess they target AWS but not AWS users...
If there's a policy for open source-only usage, you will definitely be affected.
If there will be a diminished number of contributors (which won't like to contribute if it is not open source) and ecosystem (that will stop developing/growing being a proprietary project), you will be affected too.
And you're not AWS in either them.
I'm not lawyer but this is what I understand from their statement.
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.
Well, you can argue the spirit all day, but in practice, permissive licenses mean what they mean. Once a version is released with that license it stays that way, but subsequent versions can have a new license.
Basically, you do keep the fruits of your labor - you get Elasticsearch 7.10 and all previous versions. But you have no right to Elasticsearch 7.11.
Note: In practice I agree it's a dick move to go to a more restrictive license, and I strongly disagree with Elastic's decision to do so. It's just a greedy move that won't even make them more money in the long run because it will cripple the momentum ES has.
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 Elasticsearch-as-a-service so long as it's based on the current Apache2-licensed code rather than the SSPL-licensed code that will be in effect as of the next Elasticsearch release.
There are certainly valid criticisms of this decision, but a blanket statement that "thousands of individual contributors" are the losers here is an exaggeration.
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.
Not really; the essence of permissive licenses is that proprietary extensions/versions are allowed. If you want to contribute code that will always remain open you need a copyleft license like GPL.
While i hate the change, that isn't true. They have access to their changes in the current and older versions of Elastic. You can lock yourself to the current version forever and create your own bug fixes.
I like BSL because it always eventually transitions to an ordinary open source license. So over time all BSL licensed code will actually be open source. That seems to not be the case with SSPL?
Good post on BSL: https://perens.com/2017/02/14/bsl-1-1/
Also the SPDX identifier for it is BUSL since BSL was already taken by the Boost Software License.
The intention is that it’s up to the one using the BUSL to specify to which degree production usage is allowed:
“The Licensor may make an Additional Use Grant, above, permitting limited production use.”
Eg. Sentry allows all non-SaaS production deployments of their BUSL licensed code, which is pretty much the same goal as here, but with BUSL the code will be actually open source eventually whereas here it will stay in this extended AGPL-like license forever?
It also prohibits use of Business Source Licensed software, but as source code under that license will always after at most 4 years transition to a GPL compatible license, all such code will eventually be possible to use at Google and one can easily maintain a GPL-compatible fork that merges code in as the BUSL expires, thus enabling a good exchange between BUSL and open source, whereas no such exchange is possible with SSPL, its forever stuck in a AGPL like license and most companies generally stay far far away from AGPL.
That make it sound like packaging together the open source core with some third party plugins that could be used in place of proprietary plugins from Elastic was somehow some evil plot to destroy the community. Was the goal of the package to increase the bottom line of a company other than Elastic? Probably. Was the goal to splinter a community from which said company profits? Probably not.
If not, that basically confirms the OSI's rejection of the SSPL as an open source license -- If that provision is too onerous to be followed, it might as well say "you can't offer this as a service".
And nobody uses Linux for their *-as-a-Service offering, no?
I think the big issue is that all Sass Providers considered themselves free from such pesky license details like copyleft, because they don't distribute software.
I think the biggest problem with the SSPL is its vagueness when it comes to liabilities and its broad reach when it comes to contagion. In principle, a copyleft license that covers service providers is long due, but it better be a good and practical one.
Yet now Elastic isn't content with competing in the market with its own managed offering (ironic because their offering is way better than AWS' anyway). Instead, they want to call themselves open source while switching to a proprietary license. Shameful.
I don't care about not being allowed to compete directly with Elastic using their own product against them.
"Free" and "open" have established definitions in the software space, neither of which mean "proprietary." This is just open-washing nonsense.
Edit: fixed typo
The license is plain vague.
And it's ES that's forcing AWS to do this.
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.
AWS doesn't offer any version with new licenses.
Then they fork the project, and none of the improvements AWS makes to the fork gets pushed upstream to ES. Which only hurts Elasticsearch as a project.
ES can take their ball and go home. But they're doing so to their own detriment.
Related: I find it really bizarre how many in the tech community seem to outright just not believe in capitalism...
People want a license that says something like, "you can only use this if you also contribute to the commons, or if you pay for the privilege not to". SSPL is an attempt to be that. Maybe it doesn't do that job well, but don't confuse it as competing with permissive licenses.
[1]: https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up.h...
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 committed to using free and open source software. What a shame.
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.
I have been gathering resources regarding copyfarleft licensing and projects here: https://github.com/LibreCybernetics/awesome-copyfarleft
I already knew about the Anti-Capitalist Software License but didn't know about the others. Copyfarleft is a great concept.
To make this work we need to build an ecosystem around these licenses and non-exploitative business models. The fist step is indeed to let people know such licenses/ideas exist.
The correct FOSS way to do this is using a FOSS license, an SSPL is not one of these. AGPLv3 is and provides a nice protection.
Calling the blog post “doubling down on open” is an insult to the community’s intelligence. They should be more “open” and honest about what their doing and why instead of playing the victim.
Lucene on the other hand, is "owned" by the Apache Software Foundation (ASF). While companies can build products based on Lucene, which they release under their own choice of License, they cannot change the Lucene license itself. Only the ASF can do that.
Another example of this is Kafka. It was developed at LinkedIn, who transferred control to the ASF. When the LinkedIn employees who originally created Kafka, left to form Confluent, they had no control over the licensing of Kafka. They could only decide on the License for the Kafka add-ons that they provide. Eventually (about a year ago) they forked Kafka to create "Confluent Server", which is released under their proprietary license. Kafka itself however remains open source under Apache 2.0 license, still controlled by the ASF.
Does this mean anyone using version 7.10 or lower is not bound by SSPL license and Apache2 still applies?
I think people forget that these companies might be bought in the future by Oracle.
By the way, I am not a lawyer and I might have misinterpreted the article, but I feel like the AGPL could have accomplished what they wanted to do. Maybe it's not restrictive enough for their needs, but I'm not sure why.
But you really like the lucene natural language search functionality, so you copy your database into a lucene database for searching. But hey, elasticsearch takes care of a bunch of tedious problems, so instead of using raw lucene, you use elasticsearch...
So, you've got a PHP web application that queries this cache of the catalog stored in elasticsearch; what's your legal liability?
This will be a nightmare if ever tried in court.
If you're purely processing internal logs on an internal service, you're probably good.
If you're exposing an API or a UI to paying customers which calls Elastic search to run a query, then it's maybe not great.
Everything needs to be caveated with "maybe" or "possibly", because nobody knows how it'd go in court.
We use AWS's ES. And, as far as I'm concerned they already open-source their version.
SSPL is actually helping the open-source community here
No, its purpose is clearly to prevent others from reselling ES as a service at all since it's effectively impossible for anyone offering ES as a service to comply with the SSPL, if they were only concerned about others that offer ES as a service sharing their code AGPLv3 would be sufficient.
Meaning the entire codebase of the infrastucture that provides the offering. I.e. the underlying code behind AWS. Not a big deal right?
> The SSPL allows free and unrestricted use, as well as modification, with the simple requirement that if you provide the product as a service, you must also publicly release any modifications as well as the source code of your management layers under SSPL.
Not a lawyer, but I think AWS fall foul of "as well as the source code of your management layers" because they have a massive amount of closed source stuff running behind their ES service.
GPL licenses are not SSPL compatible, so it would likely still be impossible to comply even if their ES service was entirely open source.
...and it isn't helping anyone (other than the licensor) let alone the F/OSS community: https://news.ycombinator.com/item?id=18301116
MPLv2, EPLv2, xGPLv3 are strictly libre even if not as wildly copyleft as SSPL.
Unfortunately for you, there's a decent chance that AWS freezes their support at a version before this license change, and never offers upgrades. As far as I know, AWS has never agreed to offer services based on code under the SSPL license.
> SSPL is a source-available license created by MongoDB to embody the principles of open source while providing protection against public cloud providers offering open source products as a service without contributing back.
forgive me for not immediately seeing that this is an "open source inspired" license, not open source.
> As previously mentioned, over the last three years, the market has evolved and the community has come to appreciate that open source companies need to better protect their software in order to maintain a high level of investment and innovation.
...by no longer releasing open source software
> As previously mentioned, over the last three years, the market has evolved and the community has come to appreciate that open source companies need to better protect their software in order to maintain a high level of investment and innovation.
again, "we value the same principles as open source... but we're not going to be open source any more" obfuscation.
your doubt is unbecoming, bevacqua.
(The other option, the Elastic License, allows you to use the product in either source or binary form, but you may not make derivative works or compile your own binaries except for testing.)
Or the Open Source Definition from https://opensource.org/osd
On the license there are 3 main "propagation" clauses: Conveying Verbatim Copies / Conveying Modified Source Versions / Conveying Non-Source Forms
Furthermore: Acceptance Not Required for Having Copies / Automatic Licensing of Downstream Recipients
On the other hand, the "issue" seems to be an Aferro-like clause that conveying it as a service combined/linked with other software over a network _counts_ as distribution an gives a right to the users to request the source code that makes the service work.
Here is Google rejection of APGL on this basis: https://opensource.google/docs/using/agpl-policy/
edit Here's an informative StackExchange comment. [0] Apparently it's a good deal stricter than the AGPL, and introduces much more legal uncertainty.
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.
[1] https://github.com/toshi-search/Toshi
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.
Rust and C and manual memory management have overhead too.
This is actually very interesting project. Do we have some benchmark that sonic works on huge scale with lot of data?
they also claim
> It is used to index half a billion objects on a $5/mth 1-vCPU SSD cloud server (as of 2019)
> Sonic is integrated in all Crisp search products on the Crisp platform. It is used to index half a billion objects on a $5/mth 1-vCPU SSD cloud server (as of 2019). Crisp users use it to search in their messages, conversations, contacts, helpdesk articles and more.
Of all the projects you mention however, only Toshi addresses clustering, and as an experimental feature.
If you're using it for logfiles, the only real alternative I know is Grafana's loki.
Too bad we're talking about software license here.
Many elastic pros recommend not using the AWS version because it doesn't operate properly.
While I am pro OSS I can understand why a company based on OSS would not want to subsidize a much larger AWS who is extracting value, and also, their direct competitor.
When I talked with AWS about an estimate for Managed ELK, and also, an EC2 based ELK, I received estimates > 50M a year. Crazy pricing
Elasticsearch is/was an "upstream" for Open Distro for Elasticsearch (which is a distribution / collection of software). As an "upstream", changes to the core Apache 2.0 licensed software was sent as pull requests to Elastic, which are usually merged. It isn't correct to say that AWS has not been contributing to the upstream Elasticsearch code under an Apache 2.0 license (and, also, signing the CLA to boot, which allows Elastic to relicense AWS contributions under SSPL).
Here's a sample of PRs from AWS developers that I could find:
https://github.com/elastic/elasticsearch/pull/61400 https://github.com/elastic/elasticsearch/pull/59563 https://github.com/elastic/elasticsearch/pull/57271 https://github.com/elastic/elasticsearch/pull/53643