It was so that AWS would create their own name for their fork:

> we changed the license, knowing it would result in a fork of Elasticsearch with a different name and a different trajectory. It’s a long story.

I think the name of the fork is now OpenSearch.

Am I the only one not buying this reasoning? Seems like there's more than is being said, otherwise they would have said this by now. I'd reckon that ELv2 had friction that couldn't be easily overcome without OSS or at the very least DOSP [0]. I personally experienced said friction with ELv2, so makes me curious.

[0]: https://opensource.org/dosp

Sounds to me like they're trying to cover up a bad case of regret. At our company we've fully shifted to OpenSearch, so there's no going back to ElasticSearch even if we wanted (not that we would want to). Also there is a lot of engineering contribution from Amazon that's seemingly gone now from Elasticsearch, right?

Sounds like you've fully shifted to exploiting (without contributing anything) to OpenSearch. I think Elastic will be just fine without your company or Amazon.

They are paying Amazon for Opensearch resources. To Amazon, that’s enough contribution to continue supporting the source code.

Not necessarily. You can run opensearch on your own hardware and pay nothing to Amazon.

How truly far we've fallen that people refer to using open source software— literally software given away for other people to use, exploitation.

Gonna go tell those freeloading kids who take my candy on Halloween that they're exploiting me unless they contribute to next year's candy bowl.

I'm not the GP, and I don't have a dog in this fight, but I think what they are complaining about is this sequence of events:

  - ElasticSearch was open-source
  - Amazon offered ElasticSearch open-source as a paid service
  - ElasticSearch was not happy about this and changed their license
  - Amazon forked ElasticSearch (the open-source version) and created OpenSearch based on that, continuing to serve OpenSearch
  - (Few years pass)
  - Amazon and ElasticSearch are now buddies

I think GP is talking about the events that transpired a while back before Amazon and ElasticSearch made up.

What, when Amazon forked an open source project, as was allowed by the license, and continued to support that open source license even when the original company abandoned theirs? I’m not an Amazon fan, but they did the same thing (forking) that many others do, and they did it perfectly legally according to the license.

Yes, doesnt Elasticsearch do the same thing with Lucene?

https://stackoverflow.com/questions/27793721/what-is-the-dif...

AWS just offered a convenience layer over ElasticSearch

It's a bit more complicated than that because Elastic during all of this had some of the plugins in Amazon's OpenDistro (now OpenSearch) project recycling proprietary code from Elastic's commercial, source available codebase under OpenDistro's permissive Apache-2.0 license.

https://www.elastic.co/blog/dear-search-guard-users-includin...

Your link specifically says Amazon didn’t steal the code, some German company did.

I get it, Amazon is bad, I agree they are too, but not because they’re malicious, Amazon is bad because they’re too large to compete on level ground with anyone other than Google or Microsoft in the cloud.

My peeve is with the companies like elastic that claim they are for open source but they try to prevent the open source from being used as such. It’s a scam to attract developers who care about open source. If I made code I wanted to be open source, I’d understand that means everyone can use it, like a public road or a public park. That includes big corps.

At least Amazon actually supports the Apache licensed OpenSearch product! They don’t even go around acting all superior like those “open source” corps do about it.

> Your link specifically says Amazon didn’t steal the code, some German company did.

Yeah it's not that Amazon stole the code, it's that they were distributing stolen code. It's not as bad but it's still problematic unless Amazon immediately pulled said code when they were notified.

> My peeve is with the companies like elastic that claim they are for open source but they try to prevent the open source from being used as such. It’s a scam to attract developers who care about open source.

I think this was less about preventing open source from being used and more about picking the wrong license for their project. The way I see it they took the long way around because they were afraid of the AGPL.

They dual licensed under the SSPL (which is the AGPL with one change that makes it problematic) and the Elastic License (which they originally also provided code under a previous version of).

Then they are now finally getting around to moving from the SSPL to the AGPL (while technically still offering the SSPL).

Had they gone straight to the AGPL none of this would have been even worth discussing but a lot of people are afraid of that license in the same way people used to be scared of the GPL.

> If I made code I wanted to be open source, I’d understand that means everyone can use it, like a public road or a public park. That includes big corps.

Sure however if you chose an open source license, you probably don't want companies selling access to your software with a few extra closed source bits bolted on without contributing anything back. It's not legally wrong but it's a dick move and against the spirit of FOSS. So even then Amazon hadn't broke any laws but it'd make sense for a FOSS oriented company to pivot to a license they think would force upstream contribution. Elastic just fucked up and chose a bad license (SSPL) because they feared the AGPL. This is just them getting over that fear and picking the license they should have picked from day 1.

> At least Amazon actually supports the Apache licensed OpenSearch product!

They do now. When Elastic was Apache licensed they did not. That was the problem. It was only when they re-licensed Elastic that Amazon open sourced their fork. Had they not, OpenSearch would still be the closed source AWS ElasticSearch.

> it's a dick move and against the spirit of FOSS

I disagree with this. Most people use FOSS and do not give anything back, individuals included. The spirit of FOSS is creating things that others will use without compensation. If I release anything open source, it's because I'm donating it as a whole to humanity, including big corps and individuals. I understand that, because I've thought long and hard about what it means to release something with, say, an MIT license. It means you lose having full control of your creation. If I wanted to limit who can use my software, I'll sell it or license it accordingly. Complaining later that your FOSS software was "stolen" or "exploited" or whatever is just sour grapes.

I think it's a difference of scale.

If rando small business or rando dude is just using FOSS software without giving back, whatever people have priorities.

If megacorp is re-boxing it in a closed source manner and making mass profits off of it without dedicating at least some level of engineering hours or money to the project, that's a dick move.

Being unhappy with that situation is totally fine and it's understandable to change the licensing to a more copyleft license to reflect your intents.

That's what elastic did. They essentially went Apache-2.0 -> ... -> AGPLv3 but it took a while for them to figure it out.

And my complaint isn't that people make money off FOSS software or don't give back enough. It's that they make money off FOSS software and don't give back essentially at all while depriving their users of the same rights/licensing terms that the upstream gave them.

In any case, Amazon did give back to Elastic via code commits before the fork, so they didn't just steal the code, they also made it better. I can't believe I am defending Amazon, but this is a hill that I will die on: FOSS means free, as in beer.

No one ever accused Amazon of breaking the law.

The issue that Elastic had is that their entire business model was offering a managed elasticsearch solution. Amazon then created their own offering of the same thing, but of course since it is Amazon it was more tightly coupled with AWS and benefited from being a native AWS solution. There was simply no way for Elastic to compete with that.

Now, there can be a lot of opinions on whether that is a good thing or a bad thing for the open source community, but it should be pretty obvious why elastic didn’t like it. They were a company who had a product they were selling, and then the biggest competitor in the world starts selling THE EXACT same thing with the EXACT same name. They needed to do something to compete.

So they did, and forced Amazon to change the name of their offering to opensearch instead of Elasticsearch. Once they achieved that, they reverted the change.

>The issue that Elastic had is that their entire business model was offering a managed elasticsearch solution. Amazon then created their own offering of the same thing

Amazon first offered Elasticsearch as a managed service in 2015. Elastic began offering managed services in 2018.

https://en.wikipedia.org/wiki/Elasticsearch#Managed_services

That’s not true. Elastic acquired Found in 2015 and immediately offered their managed Elasticsearch service. It was publicly announced at their user conference early that year.

> since it is Amazon it was more tightly coupled with AWS and benefited from being a native AWS solution. There was simply no way for Elastic to compete with that.

That's one interpretation. I've another, which I've seen play out multiple times now across multiple OSS projects: company invents a thing, thinks that because they're the inventor of said thing they'll be able to sell a managed version of it, belatedly realise that inventing a piece of software doesn't magically make you the best in the world at running it at scale.

What Elastic, and most like them, can't compete with is the ability to run highly available/reliable software at the scale of Amazon.

Several years ago, I led a project at a startup to move from Postgres to Elasticsearch for geographic search. I chose Elasticsearch because it had the capability to do geohashing and so it provided a credible alternative to PostGIS for our particular use case. Geohashing-based search is particularly computationally intensive, which is somewhat different from traditional full-text search, which can be memory intensive.

I wanted to pay Elasticsearch to host our search cluster. And I did for a while. But it became clear we were paying for gobs of RAM that we weren't using and we didn't have enough CPU to really cover our search needs. I talked to the head of sales at the time and he said they were working on a plan that would allow us to choose machines that were more CPU heavy but that that was in the pipeline and there was no ETA.

So we switched to AWS and everything worked just fine.

All this is to say, Amazon was not offering the exact same service. They were offering a better service.

The true irony being that elasticsearch would be no where near what it is now if it wasn't opensource and receiving contributions in the first place. AWS had employees dedicated to contributing to Elasticsearch (same as Redis).

I think the logic goes something like:

1) Amazon is powerful, thus bad

2) we’re discussing Amazon

3) find something potentially bad

4) use confusing and negative language to throw shade to discredit my target because #1

It’s really frustrating to experience these types of conversation. People explicitly choose to donate their work to the world under an open source license. Complaining they someone uses without contributing is so stupid it defies belief. It’s like complaining because Amazon only pays $5 for a Big Mac when that is the posted price.

This is not the argument at all. Software (open source or otherwise) is not created for free; devs gotta eat, pay rent, etc. The business model of Elastic and similar is to offer a SaaS. They feel that Amazon offering a SaaS is directly competing with their business model, and because half the world runs on AWS it's not too different from Windows shipping IE back in the day killing Netscape. Elastic feels Amazon is eating their pie.

Lots can be sad about a lot of this. You can disagree with a lot of this. There have been a million discussion on HN and I don't really feel like repeating it all. But you've spectacularly misunderstood the argument.

Developers willingly choose to donate their work under an OSS license. So yes there are costs and thankfully people release without the expectation.

It’s perfectly fine to sell your software. There’s trillions of dollars worth of companies that do that.

But I make sure I eat through other methods so I’m able to donate my time.

If Elastic doesn’t want Amazon to use their software, then they shouldn’t release it as OSS. It’s quite simple.

But it’s ridiculous, I think, to claim Amazon is doing anything wrong by abiding by the license.

Elastic shouldn’t feel that Amazon is eating their pie because they chose to put their pie out with a “free pie for everyone” under ASL. If they feel bad, that may be so, but their feelings aren’t as important as what their intellect should set up.

I'm not really interested in discussing the merits of the argument (or lack thereof); I've done this a dozen times over the last few years and I have no interest in repeating it.

I am just saying your post hugely misrepresented the argument.

That you think the argument is a load of bollocks changes nothing about that.

It’s unfortunate you don’t want to discuss the merits of my argument.

Not to give out advice, but if your aim isn’t to learn and debate and change minds and be changed, what’s your point? Do you just want to make noise or something?

I would like to properly characterize the argument to understand all sides. Because I want more great software to exist in the world. My belief is that the way to do this is to have people create and share, of their own free will. And I want to learn if there’s a better way.

> Do you just want to make noise or something?

So correcting your enormous straw-man of misinformation is "noise"? Oh just sod off with your bollocks.

Funny, you're doing exactly what you accused others of: defend Amazon with argument 1. Ah, argument 1 completely misses the point? Well, just defend Amazon with argument 2. Say no word about how you missed the point originally, because the only important thing is to defend Amazon.

> If Elastic doesn’t want Amazon to use their software, then they shouldn’t release it as OSS.

So maybe they should stop releasing future contributions as OSS? Oh, wait…

Exactly. It’s their choice as the creator. And they can change their mind as much as they like.

It’s cool being a programmer because we have such autonomy over our actions and our creations.

This is kinda funny, because I am arguing both sides a bit here in my reply to different comments, mostly because I am not actually sure what my final belief on this topic is.

But maybe we shouldn’t fund open source development via companies whose entire revenue is selling support for that product? I feel like my favorite OSS projects are ones that are created and maintained by developers working for companies whose business model is based on something entirely separate from the OSS project, but who need the OSS project to support that business. They, and many other companies who have the same need, pay developers to work on the project so they can get what they need from it, but they keep it open source because it isn’t core to their business and being OSS makes it easier and cheaper to maintain.

In this way, there is no conflict of interest between the open source needs and the companies business model.

I think the word "using" here is doing a lot of work. When talking about an entire application, I think of "using" it as being, well, using the application. But what I think we're talking about here is "using" the application code by selling it as your own product.

I recognize that "open source" is ok with that second way of "using" the code, but I do think it's meaningfully different.

According to a quick search, there are 33M "users" of Linux (I suspect that number is way too low). Only 15k have contributed to the kernel. That's an "exploitation" rate of well over 99.9%.

> According to a quick search, there are 33M "users" of Linux (I suspect that number is way too low). Only 15k have contributed to the kernel. That's an "exploitation" rate of well over 99.9%.

This is very misleading. There is a lot more code than just the kernel for the Linux operating system. If you ran the numbers for a default install of Ubuntu or RHEL that would be far more useful. The Linux kernel requires far deeper skills than a lot of user-and development so it is going to have fewer contributors per year on average.

Source: I am a Linux kernel engineer.

You're right; that's just an example. Even if we included all components, and bumped that contributor number up to 1M, we're talking about 97% "exploitation". My point was that pretty much every open source project is almost entirely usage vs contribution and that claims of exploiting open source are a non sequitur.

Isn't elastic itself based on open source tech too? Is elastic exploiting java for example?

Then why is Elastic opening sourcing their code again? No need to change any part of their business model if things are going perfectly well? Altruism?

This is exactly it. They made the gigantic miscalculation that Amazon wouldn't win this battle.

I can't believe they didn't predict that this exact outcome would happen: Amazon forks under a more permissive license and becomes the new standard instead of Elastic because the entire package (managed service from AWS + more permissive license) is a lower risk package to the average business.

I mean, if you actually can't believe they didn't predict this exact outcome, that means you believe that they DID predict it and this is what they intended/hoped to happen!

I am certain you are familiar with this colloquialism, so I’m not sure what you’re trying to say.

This is literally what we're talking about though -- Elastic Search claims they did predict it, and this outcome now was their hoped for plan all along. So I wasn't sure what you were trying to say, if you don't believe they didn't predict it...

I guess you're actually saying that despite their claims otherwise, you don't believe they did predict it?

What I’m saying is that if they are claiming this is the outcome they wanted, they are lying.

The truth that I think they are trying to hide is that they are losing adoption to their Amazon-backed competitor and that they will bleed more customers if they don’t go open source again.

I think that when they made the original decision to change the license they thought their product had more pull than it really did. They thought customers would leave Amazon’s managed product for their “superior” product rather than Amazon’s “inferior” fork. They thought people wouldn’t trust Amazon to have the expertise to continue development. In reality what customers wanted was a managed solution from their cloud provider, they didn’t really care if it was Elastic or not.

I totally understand that the situation was a pickle for Elastic in terms of being able to be a sustainable company and perhaps they had to do something. But the thing they did didn’t work, or else they would have stuck with it.

In my experience companies that modify the licensing of their products or get bought by bad stewards like IBM (Hashicorp) or Progress (Chef Software) scare away the engineering managers who make purchase decisions.

You are not the only one, that's a ridiculous story.

> I personally experienced said friction with ELv2, so makes me curious.

Can you share more? What friction did you experience with ELv2?

I wrote about it earlier this month: https://keygen.sh/blog/keygen-is-now-fair-source/

Also briefly touched on one of the issues here: https://news.ycombinator.com/item?id=41395663

we sunk our own boat, it forced them to get on rafts and leave, and now we're declaring our own boat sea-worthy again.

So, yes, the ELv2 did introduce significant friction?

Yes, except that since Amazon have infinite resources, the friction didn't stop them doing anything, and the fork was always going to be perfectly viable.

It’s very clear in the post ZIRP era that none of the hyperscalers have infinite resources. AWS just discontinued, er, de-emphasized Cloud9 and CodeCommit. Neither of these were free, and both were substitutes for paid products that AWS customers can get elsewhere.

Here is the reasoning they gave at the time.

"So why the change? AWS and Amazon Elasticsearch Service. They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse. If we don’t stand up to them now, as a successful company and leader in the market, who will?"

https://www.elastic.co/blog/why-license-change-aws

It was crazy for Amazon to name their hosted search product Elasticsearch! At that time, Amazon clearly felt the name had some value.

I agree that this is probably not the picture of the huge win they are painting. Still, it must have been frustrating for Elastic to have to explain to potential customers that they weren't reselling an Amazon product.

https://www.computerweekly.com/news/252513588/Amazon-drops-E...

It was probably also crazy to call the search product “elasticsearch” 4 years after Amazon had started using “elastic X” branding for their already-popular cloud services.

You can call any decision you want crazy, but it's not relevant in a matter of trademark, and they talked about this at the time of the original license change. The word "Elastic" isn't enough on its own. In contrast Amazon was literally offering a product identical to theirs (quite literally) that was also using the exact same name "Elasticsearch".

If Elastic the company sold a product called "Elastic Amazon EC2" and it was an API compatible copy of EC2 cloud compute, you can reasonably assume that Amazon would be pissed off about it.

It might not be sufficient to trigger trademark violation, but that doesn’t stop it being a dick move.

Edit: As was Amazon's choice to offer a service named that once Elasticsearch was established, to be clear.

What could be learned from this example that might enable companies in the future to leverage trademark instead of a license change to accomplish the same thing? So much damage could have been avoided if this had been resolved differently to begin with.

Change your name, not your license.

I think they are saying: trademark your product name (open source in this case), make sure it's used only as approved.

Altho i believe it does go back to the license attached to the product.

Source code license doesn't matter, Mozilla did this with Debian, that's why Iceweasel was a thing.

what is preventing AWS from dropping OpenSearch and going back to just selling Elastic ?

To be honest, the OpenSearch brand has more value now than Elastic.

I see a couple people on here claiming this, but no data to back it up. Elastic beats out OpenSearch by a wide margin on every metric I've thought to check (gh stars, gh stars rate of increase, number of commits, number of pull requests opened, number of pull requests merged, number of issues, stack overflow questions...). Not a single one shows OpenSearch ahead.

What metric are you using to come to the conclusion that OpenSearch is the more valuable brand?

As a related proxy for market awareness, DB-Engines.com's ranking is a composite index of a number of factors:

• Google search volume and quantity of search result pages (blogs, recipes, etc.)

• Mentions in LinkedIn profiles as a skill

• Number of job post listings as a requisite skill

• Social media mentions

It is a measure of "mindshare" or "share of voice." Not one of market share ($$$) or utilization (TBs under management, etc.).

With that said, in the August 2024 listing:

• Elasticsearch is ranked #8 (of 423 systems tracked), with an index score of 129.83

• OpenSearch is ranked #35, with an index score of 16.47

This would make OpenSearch about an eighth as prevalent.

Relevant, the curves tell a different story: https://db-engines.com/en/ranking_trend/system/Elasticsearch...

A big question is New + Churning installs. I'd expect a scary portion of the New, and inherently slower rate of Churn are heading to OS instead ES. The curves support that: note that ES isn't substantively growing on that chart. Anecdotally, we see most new installs as leaning to OS in the security industry, which is one of the top money makers for ES/OS.

Yes, exactly. I often do comparative results like this to see where there is "momentum."

Opensearch is definitely coming on strong.

thats a super one sided set of metrics. it doesn't tell us anything about how many people are actually using one, just how much visible dev activity they have.

I don't have those metrics or an opinion, im just saying that value is based on utilization by a product's target users, not support activities.

> it doesn't tell us anything about how many people are actually using one, just how much visible dev activity they have

Stars and rate of star growth and stack overflow activity are all passable proxies. They're not great, and I'm open to better metrics, but they're what I can find.

Truly, if anyone can give me any metric that shows OpenSearch ahead I'll shut up. I can't find one, and I've looked.

AWS revenue. Internal AWS stats. Open search client pulls (not sure if the client is different now). Opensearch is mainly going to be used on AWS so that won't show up as much in GitHub stars.

None of those metrics measure the value of the brand, so none of those metrics are useful for the question that this thread is about: figuring out if AWS benefits from sticking with the OpenSearch brand.

If I'm right that OpenSearch has a weak brand, Amazon could switch and their internal stats and revenue wouldn't budge.

For one, we don't have to pay for basic amenities like security and alerts. To heck with gouging the customer for basic feature sets. Aws have their faults, but enabling teams to get the whole elastic experience without the weird nickle and diming is a blessing. Good on Amazon and boo elastic.

This is a reason why you prefer it but not evidence that the brand has overtaken Elastic's.

This evidence can only come from financial accounting. Amazon does not report OpenSearch results separately so you’re looking for data that does not exist in a public form. It’s a waste of time.

> This evidence can only come from financial accounting.

That's not true—we're talking about brand value, not financial value of the product. If AWS switched over to offering ElasticSearch again (not that they will) and ditched OpenSearch, I have no reason to believe that their financial numbers would go down a bit.

Brand value is nearly impossible to measure, but to the extent that you can it'd be by measuring perception among those outside the company, not through an accounting of the company's actual revenue.

Think of it this way: the brand LENRUE [0] is worth approximately zero. The company that makes these products could rebrand tomorrow and their revenue stream wouldn't take a hit in the slightest. But the company presumably actually makes some amount of money.

For Elastic vs OpenSearch, the brand value of the two products should be loosely comparable by looking at some measures of public perceptions, and I can't find any measurement that would suggest OpenSearch is in the lead.

[0] https://www.amazon.com/stores/LENRUE/page/24E9713E-AC7E-4269...

Louie.ai team talks to a lot of sec teams, and new projects generally prefer OS bc openness, and a lot of migrations. Think MSPs etc.

Anecdata, but very real.

interesting. I've heard of ElasticSearch a gazillion times and this is the first time I've heard of "OpenSearch", and I've also been using AWS since it came out basically.

I'm basing it off my own experience with managers, developers, and sysadmins. No one wants Elastic Search over Open Search. We're spending all our money on Open Search. Whenever I mention Elastic Search I may as well have just farted. Everyone hates the support and enterprise licensing model. We already pay for AWS support anyways so why not use their fork? Why add yet another vendor to our tech stack?

Please explain. This isn't obvious to me.

I think it's nuanced. I'm currently managing an engineering team on an interim basis. During standup I noticed that most engineers were talking about 'elastic' or 'elasticsearch' but one was talking about opensearch. I asked them to clarify that for me and they told me that they transitioned to AWS opensearch but still use the old name for the product often - that might point to the strength of the Elastic brand.

"Elasticsearch" seems to be often referred to as a technology, as in ELK stack, rather than as in "Elastic" the company.

Large tech companies care about their reputation. If they dropped their own fork and went back and started again from Elastic that would be admitting their own incompetence. So not happening.

I think the bigger risk to Amazon: what if Elastic wants to pull the rug out from under them once again? Why take that risk when Amazon is already stable? Given the duration since the fork, I suspect there are more than a couple of features differences between the products that would have to be smoothed over.

It's a very different open source license than their previous one. AGPL vs Apache 2.0

sunk cost. at least that’s what elastic seems to be betting on.

Perhaps the fact that AWS has got years of time investment already made into OpenSearch and staying with their own version allows them to reduce risks should Elastic attempt to change ElasticSearch’s license again.

If you try to sell AGPL software the owner will probably shake you down.

Examples?

Grafana https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic... RethinkDB http://web.archive.org/web/20161003231505/https://rethinkdb.... BerkeleyDB http://web.archive.org/web/20170211004058/http://www.infowor... MongoDB tried the shakedown but I guess it didn't work http://web.archive.org/web/20240202161503/https://www.mongod...

None of these are examples of shakedowns - they are just posts about adopting a license. Do you have any examples of shakedowns? 'Cos that's quite a claim you made there, and surely there are some examples.

Those links are all generic pages related to their licenses. I'm not seeing how they support the idea of a "shakedown", which is criminal extortion.

They all say if you sell the database as a service you can't use AGPL; you have to pay for a commercial license.

no they don't unless, you are using the features like SSO that are behind the license or you are refusing to publish any patches you apply

The point of DBaaS is that you wrap an open source database with a proprietary control plane that you won't release. Cloud vendors say this is compliant with AGPL but database startups say it isn't and thus the cloud vendors need to buy a license.

None of those pages you linked say anything like that, you're just making stuff up.

One of them is not the company talking about their license choice but a FUD article crying about AGPL which we've seen a million tired versions of.

The Rethink one says

> * Require users who choose to modify RethinkDB to fit their needs to release the patches to the software development community.

> * Require users who are unwilling to release the patches to the software development community to purchase a commercial license.

note:

> * who choose to modify RethinkDB

and

> * release the patches

none of these say anything about problems with putting control planes in front of it.

I have worked with cloud hosting a database where the only feature behind the enterprise license is a load balancer with some dead simple authz plugins.

You can write put any LB in front of it and host and sell it with the same capabilities without violating the OSS license. Adding a "control plane" that sits in front of the hosted database does not require you to publish any modifications unless you actually are running a modified version of the open source software. You would never have to publish your own LB.

lowagie/itextpdf being an obvious/prominent one.

it happens - why would you think commercial operators who’ve chosen a dual-license model wouldn’t protect their IP? That’s literally their breadwinner.

"shakedown" is a rather stronger claim than "adopted a licence".

I fairly well knew that your question wasn't good-faith, that's why I hesitated to respond rather than just flagging it.

what element was "bad faith", that the query was nonsense? Point me at anything that would legally or even ethically constitute a "shakedown" as alleged by OP, who it appears in the subthread to have misread the license?

like, answer the question instead of evading, surely it cannot be that hard.

OpenSearch really appears to have a significant amount of development momentum. It is functionally equivalent with Elasticsearch. There would be no incentive for AWS to do this. After ES broke their compatibility with OpenSearch they also broke compatibility with their own older versions. This forced users to choose in order to move forward with anything. I don’t know how it worked out for others but I’ve converted hundreds of ES clusters to OS and switched all development to OpenSearch because they started gaining momentum and didn’t make decisions that were actively hostile to their users.

Edit: As long as OpenSearch doesn’t start breaking the self hosted use case, I don’t see any reason to consider Elasticsearch again. In fact, ES would have to offer up a significant advantage to overcome the bother.

well importantly, Elastic was originally Apache-2.0. Then Amazon started using their stuff and they relicensed to their not-really-FOSS-license. Then Amazon forked their stuff, a bunch of legal conflicts happened. Now they are friends again. And now they relicensed to AGPL (which is FOSS).

So they were originally Apache-2.0 which was permissive versus now they are AGPL which is copyleft.

The important distinction here is that if Amazon was to use Elastic directly, they'd have to make their contributions available to users and those users could then upstream those contributions back to Elastic. In the old situation with Apache-2.0, Amazon could take contributions from Elastic but then they kept them themself for the most part without up-streaming.

This forces a give-and-take relationship vs a one-way relationship.

Also importantly now that Elastic is AGPL they can integrate anything they want from OpenSearch's Apache-2.0 licensed projects but unless OpenSearch becomes AGPL as well, they can't pull any contributions from Elastic.

Realllllly? I sure hope not.

There going to be some hard irony here, of making such a fuss about it before, when it was someone else doing it, and then doing it themselves.

We’ll see. Maybe they’re principled enough not to rip off the open search contributions.

If not, you’ve really got to believe there’s no sincerity left at elastic.

I guess time will tell; I’d like to believe they’re better than that.

There's a difference though. Prior to the relicensing, Amazon had a private fork they were running and weren't contributing upstream. Only after the relicense did they open source their fork.

Now you have two open source projects and one has a copyleft license and the other has a permissive license.

Taking contributions from the permissive to the copyleft project isn't ripping off contributions. It's using open source software and collaborating in the FOSS ecosystem. And Amazon would be free to pull contributions back the other way just as well as long as they agree to the mutual terms of the AGPL (which is by all means a FOSS license).

It will not happen. OpenSearch grows fast in the last four years. There is no incentive to go back to ES.

Recently tried OpenSearch, it has good momentum but tbf the tooling / documentation and support are not that great.

Contrary to what other people are saying in this thread, I would not say it has better branding than ElasticSearch and that ES has lost its battle. Outside AWS OpenSearch is still not a big contender

You're right about documentation and tooling. There's some good momentum in the OpenSearch community around it though, and I am really excited by things like https://github.com/opensearch-project/documentation-website/....

I don't understand why they didn't treat Amazon's previous offering as a trademark infringement.

We did: https://www.elastic.co/blog/elastic-and-amazon-reach-agreeme...

But it takes a long time. And it's very costly (especially against a much larger entity like Amazon). Legal battles alone will rarely save you (in time).

[I work for Elastic]

Thanks, I'd missed that. Anyway, congrats on doing open source again

Also worth noting that AWS was already selling products using Elastic in the name before Elastic/Elasticsearch (2010)

Eg AWS Elastic Compute Cloud (2006) AWS Elastic Block Storage (2008)

I suspect if Elastic tried to take them to court they would have got the trademark thrown out.

As a previous comment noted, Elastic _did_ take them to court over the trademark and it was _not_ thrown out: https://www.elastic.co/blog/elastic-and-amazon-reach-agreeme...

If I sell my Toyota car on the side of the road I can call it a Toyota. If I sell you ElasticSearch(tm) Service which is the actual ES code base, what’s the infringement?

> If I sell you ElasticSearch(tm) Service which is the actual ES code base, what’s the infringement?

A reasonable consumer or customer might be confused into thinking a service named ElasticSearch(tm) Service is being provided by the company behind ElasticSearch. This confusion is exactly what trademarks rather than copyrights are meant to prevent.

The trademark law doctrine of nominative fair use allows you to describe your product as a hosted version of the ElasticSearch codebase, which provides the substance of the right you were describing, and it's also why you can describe the Toyota car you're selling as a Toyota, both without needing permission from a rights holder.

In the car case, you can also reference the product by name as a Toyota product because it is the same product Toyota sold, just being resold by you. But in the hosted service case, you're not reselling the same service as Elastic does; you're offering your own independent version of the service, backed by their technology. To prevent unwarranted damage to Elastic's reputation from any weaknesses in your service's reliability, customer support, or other factors, trademark law doesn't let you call your service ElasticSearch Service without their permission.

This works similarly for lots of software products and services, even other free and open source software projects. Debian has a trademark policy and exercises oversight of modified / derived / integrated versions shipped by the major public cloud providers to make sure that it's consistent enough with Debian's software freedom values, expected functionality, and quality standards to be called Debian, using trademark rights as the way they have that leverage.

At the same time, the cloud providers do not need trademark permission from Debian to redistribute unmodified official Debian images under the name Debian, or to derive from them without using Debian in the product name. (As with the ElasticSearch example, they can still use the word Debian in a fair and accurate way when describing the nature of any derived product they make without trademark permission.)

> A reasonable consumer or customer might be confused into thinking a service named ElasticSearch(tm) Service is being provided by the company behind ElasticSearch. This confusion is exactly what trademarks rather than copyrights are meant to prevent.

> you're not reselling the same service as Elastic does; you're offering your own independent version of the service, backed by their technology. To prevent unwarranted damage to Elastic's reputation from any weaknesses in your service's reliability, customer support, or other factors, trademark law doesn't let you call your service ElasticSearch Service without their permission.

I don’t know. The orginal AWS-hosted Elastic Search product was the elastic search code, hosted by AWS. That’s fundamentally the same thing. Maybe the exact wording matters and the service name was “AWS managed elastic search” or whatever. I’m sure the Amazon lawyers knew how to name it.

This feels analogous to “Amazon Linux” where it’s clearly Amazon’s version of Linux (which is also a trademark). Or “hosted postgres” or “Postgres compatible RDS” or any number of other services based on OSS.

> Maybe the exact wording matters and the service name was “AWS managed elastic search” or whatever. I’m sure the Amazon lawyers knew how to name it.

Yep, that was the problem, they just called it "Amazon Elasticsearch Service" and it resulted in a lawsuit.

> The orginal AWS-hosted Elastic Search product was the elastic search code, hosted by AWS. That’s fundamentally the same thing.

It isn’t, though, when comparing it to the ElasticSearch service offered by Elastic the company. Using the same codebase is very different than offering the same service. At minimum, pricing, billing, support, legalese, etc will all vary between the two. Downsides in Amazon’s service shouldn’t be misattributed to Elastic the company without Elastic’s permission, and trademark law quite rightly seems this more likely if Elastic trademarks are in the name of the product.

As for RDS’s PostgreSQL version, I presume the lawyers very carefully made sure it was called Amazon RDS for PostgreSQL (as indeed it is) and not PostgreSQL for Amazon RDS or PostgreSQL, Amazon RDS Edition or PostgreSQL on Amazon Web Services. Wouldn’t any of these last three names quite reasonably make a lot of people blame the PostgreSQL project rather than Amazon for any failings? Doubly so if the PostgreSQL project offered their own managed service on AWS, as Elastic does.

And as for Amazon Linux, I can think of a bunch of ways they might be operating legally in this regard, but a key one is that they probably have explicit permission from the Linux Foundation or Linux Torvalds to do as they do; in any case, the Linux Foundation and Linus Torvalds are both highly unlikely to sue Amazon for this usage regardless of the legalities, for purely pragmatic reasons that have nothing to do with whether a judge or jury would take the lawsuit seriously, and that don’t apply to companies like Elastic.

Slightly off topic but it saddens me that so much time money and effort from incredibly smart people is spent on this bullshit.

No reasonable person is going to think that “Postgres for Amazon RDS” would be materially different to “Amazon RDS for Postgres”. It’s absolute insanity that so much time effort and money is spent on this in so many places to try and skirt around trademarks (which weren’t in place in this case)rather than focusing on the actual details of the product

> Slightly off topic but it saddens me that so much time money and effort from incredibly smart people is spent on this bullshit.

Was it bullshit when Debian wanted to make sure that Google Compute Engine images shipped as Debian didn't include proprietary software, components that would nonconsensually report telemetry to Google from within the guest operating system beyond what is inherent to the nature of any VM running within Google's cloud, or default configurations that are unjustifiably different in ways that are undocumented and/or would surprise and disrupt the usual expectations of Debian users?

Yes, trademark law is the reason Debian got to have those in-depth discussions and collaborations with Google. Source: I was quite personally involved, both as a Debian developer and as a then-Googler. (And Debian was more pragmatic than you might think about some of the specifics. I was surprised myself.)

Trademark law is not bullshit even though the term "intellectual property" is.

> No reasonable person is going to think that “Postgres for Amazon RDS” would be materially different to “Amazon RDS for Postgres”.

Not in the primary technical nature of the product or the underlying software, no, that's true. But in the overall aspect of whom to blame for the service's faults or credit with the service's strengths - in other words, who is viewed as endorsing the product with the corresponding responsibility for good or bad reputational and commercial consequences - then yes absolutely the naming does change that in a reasonable person's mind.

Imagine you were not a cloud infrastructure expert but rather a stock market investor who sees a lengthy global outage occur in a managed PostgreSQL service running on Amazon Web Services. Further imagine that the PostgreSQL project were commercial enough of an organization to run their own managed PostgreSQL service on AWS in competition to the one run by Amazon, and had PostgreSQL stock traded on a public stock exchange, similar to Elastic's real situation.

In this hypothetical scenario, is it not true that an outage in "the PostgreSQL for Amazon Database" would look bad for the PostgreSQL project and would make the investor likely to sell or short PostgreSQL stock and/or (since the two services compete) buy Amazon stock? And in the same scenario, is it not true that an outage in "the Amazon Database for PostgreSQL" would entirely swap the reputational and financial/commercial impact on both organizations?

(I'm saying "Amazon Database" instead of "RDS" to sidestep the inside-baseball question of whether someone happens to know that Amazon doesn't let external vendors make flavors of the suite of services called RDS. That's an implementation detail that could easily be false at some future time and upon which trademark law cannot usefully rely.)

> (which weren’t in place in this case)

Huh? Elastic definitely had a trademark in place. Not sure why you think they didn't.

> It’s absolute insanity that so much time effort and money is spent on this in so many places to try and skirt around trademarks [...] rather than focusing on the actual details of the product

Why do you assume that? My assumption is that both Elastic and Amazon spend much more on their products than on their attempts to comply with trademark law when naming their products.

You’ve missed my point a little -

> Was it bullshit when Debian wanted to make sure that Google Compute Engine images shipped as Debian didn't include proprietary software, components

Absolutely not. But, calling it Debian on Google Compute vs Google Compute for Debian has absolutely no bearing on whether they’re doing that or not.

Like you, I’ve had similar discussions with lawyers on my side and “the opposition side” and we’ve spent hours arguing over the semantics of these things while ignoring the root problem - in this case google bundling nonfree software with Debian and calling it Debian.

> my assumption is that both elastic and amino spend much more on their products than on their attempts to comply with trademark law when namjng their products

And yet here we are unfortunately discussing how we’ve come full circle, and I’m wondering how many thousands of people hours across google, elastic and all of their users were spent on dealing with a naming dispute.

> Absolutely not. But, calling it Debian on Google Compute vs Google Compute for Debian has absolutely no bearing on whether they’re doing that or not.

It does have a bearing on whether Debian has a say in the matter, though. In fact, Google did ship customized images that didn't meet Debian's requirements to be called Debian alongside other ones which did until they were able to achieve good enough outcomes with the latter images - achieving this took a bunch of collaborative work over time.

Those other images were described in ways something like "Google Compute Engine-optimized images for Debian" (I forget the specifics), and indeed Debian completely agreed that they didn't have veto power over the contents of those images, assuming they were in fact for Debian instead of for a totally different operating system.

> Like you, I’ve had similar discussions with lawyers on my side and “the opposition side” and we’ve spent hours arguing over the semantics of these things while ignoring the root problem - in this case google bundling nonfree software with Debian and calling it Debian.

To be clear, Google did not bundle non-free software with Debian and call it Debian - they didn't even do that with their customized GCE-optimized images, though there were ways other than licensing in which those weren't up to the Debian trademark policy standards. Google did the right thing on this issue and only put free software inside all of those image images. But as you might imagine, plenty of people in Debian started out skeptical of that fact until they and Google collaborated enough for the truth to be clear.

> And yet here we are unfortunately discussing how we’ve come full circle, and I’m wondering how many thousands of people hours across google, elastic and all of their users were spent on dealing with a naming dispute.

My hours on this conversation don't count - I haven't worked for Google in almost a decade and am typing this in unpaid personal time.

And, speaking from firsthand memories of collaborating across Debian and Google on this, pretty much none of the discussion was about a naming dispute. Google agreed that Debian had the right to decide whether a modified image could be called "Debian", and Debian agreed that Google had the right use the word "Debian" in the descriptive way I've been highlighting when shipping images not approved to be called Debian.

The nature of the collaboration was much more productive than that: "Okay, Debian wants the images to meet this set of standards to be called Debian and meet Debian users' needs, Google wants the images to meet that other set of standards to be a proper Google offering and meet Google users' needs, some of the relevant standards / workflows / cultural attitudes aren't obviously compatible at first glance, but we acknowledge that we have some shared users who want Debian on GCE to work well for them. How do we achieve this?"

That's not a waste of time at all - and lawyers were not involved in the vast majority of those discussions, because it wasn't a legal dispute.

Similar good collaborations happened between Debian and the Azure and AWS teams, and some collaboration events even happened with Debian plus all three clouds. I must say, 2000s-era me would have been very surprised to see Microsoft hosting an event with Debian developers, giving them \\backslash\printer\paths in order to print something, and offering them Visual Studio subscriptions to enable working on Debian on Azure...

I should probably add a very clear disclaimer here: I am not speaking for Debian, their US fiscal sponsor and legal trademark owner Software in the Public Interest (SPI), Google, Amazon, or Microsoft in any of my comments on this Hacker News post, and while I retain very inactive affiliations with Debian and SPI, I have no current affiliation with any of the major cloud providers.

I remember when CentOS' website described it as, more or less, a major American Linux distribution with the trademarked parts removed. Everyone knew it was RHEL but the official word was mum.

How is it different than the thousands companies selling you PostgreSQL or Redis services ?

Development of postgres is funded by the companies using it, for instance Amazon.

Elasticsearch and Redis are private companies that fund most of the development themselves.

When Amazon sell Elasticsearch and Redis, they are in direct competition with its creators.

Obviously such a situation isn't sustainable in the long run, and as such both Elasticsearch and Redis (and to my knowledge also mongodb) have changed their licenses to avoid that cloud providers sell their OSS product without paying a license or otherwise contributing back.

In the case of Elasticsearch and Amazon, Amazon even used the Elasticsearch brand to sell their own version.

As I see it it's a good thing that cloud providers are forced to take part in maintaining the OSS software (forked or not) that they are cashing in on.

It’s the license type that matters, not how development is funded.

Postgres’ license is similar to BSD so even if Microsoft made and was the sole developer and sold it, anyone could distribute or sell it or whatever regardless of who contributes. Similar to Elastic’s old license and why Amazon was legal in what they did.

Amazon (and most all large companies these days) do a ton of OSS dev, but that doesn’t matter. The license of the various software counts.

FWIW, Redis was previously mostly developed by the community but the trademark was acquired by a VC funded tech company. AWS, and other cloud providers like Tencent, were contributing to Redis and they went ahead and changed the license anyways. You can read more about it here, https://lwn.net/Articles/966631/.

The problem in that case is that ElasticSearch named their company after their product that they published for everyone to use or sell.

That's an excellent explanation of a situation with a lot of complexity. Well done!

The confusion between ElasticSearch the software kit and ElasticSearch the hosted service illustrates some of the drawbacks of having the same name for your Open Source product and your business.

but if you set up a showroom that only sells toyota cars, i'm fairly sure you can't call it a toyota dealership

I don’t know if that’s true. I see tons of car repair services advertising “we repair $BRAND with original parts” and they’re definitely not owned by $BRAND.

Clearly not confused with the original brand, but also advertising a service built off that brand.

Right, but they aren't naming their business "Bob's $BRAND" which is kinda the point.

How can that be the point? That would be parallel to Amazon calling itself Elasticsearch, which never happened or was even a remote possibility.

The parallel is Amazon called their offering Amazon Elasticsearch Service.

The service is more than the code base: it's who is offering it, who supports it.

Besides, I'd be shocked if that analogy is how the law works. Perhaps if you'd bought an individual license then sure, you could resell it with the brand name, just like the car. But wholesale is a completely different situation.

It depends on the legal jurisdiction but in the US you're allowed to use a competitor's brand name/trademark specifically to inform your customers. E.g. "acetaminophen, the stuff that's in Tylenol". You can also use the competitor's brand colors.

so if I create a website called other-Facebook.com that looks exactly like Facebook, I can even tell people I'm going to steal their time and information just like the real Facebook, and that's allowed?

I think “foobar.com, a Facebook with blackjack and hookers” would be OK, while “other-facebook.com” wouldn’t.

I’d say one is marketing, the other is misrepresentation.

> Besides, I'd be shocked if that analogy is how the law works.

There's not really much actual law at work here, it's all civil matters.

That's splitting hairs. It's trademark statute which make trademarks enforceable.

They did https://www.elastic.co/blog/elastic-and-amazon-reach-agreeme...

Their post[1] from three years ago explains in more detail the reasons behind the license change and what they consider not ok behavior by AWS. The "it worked" likely means that they consider these problems resolved or otherwise no longer relevant.

[1]: https://www.elastic.co/blog/why-license-change-aws

I think they are saying when somebody looks to buy elastic search on AWS they find the Elastic offering on the market place and are not confused by the AWS offering that’s now called open search.

I think they were trying to say something along the lines of we wanted amazon to take full responsibility over a fork and to dedicate actual resources for it, such that it will be distinguishable from our product.

My guess: as I wrote in another comment, Elasticsearch had significant evolution in the area of "search engine", while OpenSearch trajectory (to use the wording of the press release) has been in the direction of APM/monitoring.

When Elastic changed the license, all vendors of APM products based on Elasticsearch jumped to OpenSearch.

Maybe, they want to pass the message that the fork, OpenSearch, is enough different to not represent real competition, and in any case, now that it exists, after the investment done, AWS will offer that as an alternative to Elasticsearch and not Elasticsearch itself but managed by AWS as it used to be before the license change.

Now, who wants a managed Elasticsearch service will only buy it from Elastic.

The "market confusion" bit has always struck me as disingenuous. The market was never confused about who was offering the old AWS "ElasticSearch Service" or what it was. Elastic's licensing shenanigans and the fork they forced AWS to create have introduced far more long-term confusion. It's certainly not the case that any confusion has been resolved by licensing the ElasticSearch code under three different licenses, all of which are unusual, confusing, and untested in various ways.