The good news is that while it was painful, it worked. 3 years later, Amazon is fully invested in their fork, the market confusion has been (mostly) resolved, and our partnership with AWS is stronger than ever. We were even named AWS partner of the year.
I don't entirely understand this bit.
I'm pretty happy with this, since they are keeping the option to use the Elastic License. Now everyone can be happy. To me, it's weird that the AGPL is any more "open source" than the Elastic License. The AGPL requires you to publish all of your source code if you make any changes to the product; the Elastic License just says, "don't use our code to make a direct competitor to Elasticsearch". I find the former to be much more restrictive in most practical ways since the majority of companies don't want to open source their code, but very few of them plan to sell hosted search.
Personally, I do wish that there was more broad acceptance of the Elastic License. Who wants to put in years building a business and then have a competitor with better distribution take your code and compete directly with you? For me, the reasons to want open-source code are:
* If a vendor goes under, I can self-host
* If a vendor raises prices too much, I can self-host
* If there's a bug in the code that affects me too much, I can fix it
* If there's a feature I really need, I can add it
The Elastic License allows for all of the above. Seems fair to me.
to publish all of your source code if you make any changes to the product
Specifically, this is the text [0]:
if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version
There are a few companies who try to make it sound like if you interact with an AGPL program over a network then your client code is now infected with the AGPL, but I'm not at all sure how they arrived at that conclusion unless it was willful misinterpretation.
Under the mainstream view, you only have to publish the source code for the AGPL work that you modified, which for 99.9% of users is fine but isn't great for a reseller.
The main barrier isn't the actual text of the license, it's that AGPL is still untested in court and there are companies who will try to make it mean something different than its apparent meaning, so legal departments are liable to get antsy. But lawyers are likely to get antsy about self-hosting under these other licenses as well.
not great for the re-seller
If the AGPL is exactly as you say, I don’t see why this would be a problem for a re-seller. For a pure re-seller I don’t think the value add is provided by modifying the software.
E.g. take the example that Amazon hosts the service and integrates with their internal services etc for logging, storage, load balancing etc. If they only have to distribute the modified source, then their internal service APIs will be leaked. This is probably fine most of the time, but what if the API reveals too much of the secret sauce (very unlikely, but possible so necessary for legal CYA, or extra approvals every time you want to modify the AGPL code). In a more devil’s advocate reading, the following stands out (IANAL, just conjecturing):
all the source code needed to generate, install, and (for an executable work) run the object code
Do I need to include my super secret storage engine X because my modification requires that I use it? Let’s say I write the code in a way that it is an optional dependency, but because of a programming mistake, a single version goes out where it becomes a non-optional dependency, do I now have to include it (for the users of that version)?
In an even more contrived case, let’s say I integrate it with a vendor closed source program X. The virality is impossible to satisfy, unless I negotiate an AGPL license for X.
Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication
Intimate data communication is pretty vague. Imagine the AGPL is a database, and I write a custom storage engine. Naively that seems pretty intimate to me.
Either correctly or incorrectly (because it’s never been tested), the perceived virality of AGPL is probably a major reason, regardless of the actual intent.
The two parts you quote apply just as much to the GPL as to the AGPL. And virtually every company today uses GPL software in some fashion.
Also, AWS did offer at least one AGPL service, managed MongoDB. They still offer it, Mongo just changed their license precisely because the AGPL didn't protect them from Amazon in the way they were hoping.
Well, it doesn’t matter as much for GPL because there are no requirements over the network, which means no requirements for SaaS (which is exactly what AGPL addresses).
And also, software distribution is different. Typically, you don’t bundle dependencies and instead install them with e.g. a package manager or system library (at least on Linux), so the separation is clearer because you don’t need to distribute the GPLed code to your user (in many cases).
Amazon offered at least one AGPL service
Are you sure? I only found DocumentDB (which only promises MongoDB compatibility). There’s also a comment by an Amazon employee that suggests Amazon never provided hosted MongoDB when it had AGPL or SSPL [1]. Further down that thread, it also suggests that AGPL at Amazon is possible, but requires extensive review beyond other open source.
Amazon has never offered MongoDB. They implemented thier own DB that was (maybe still is?) API compatible with Mongo.
take the example that Amazon hosts the service and integrates with their internal services etc for logging, storage, load balancing etc. If they only have to distribute the modified source, then their internal service APIs will be leaked.
No. What URLs the logs are sent to is just a config option - probably not even for the hosted software, probably for the kubernetes pod - not source code. If the logging exporter has to speak a magical protocol to send to Amazon's internal logging, that's Amazon's problem - they can either write a shim service to translate the protocol and then they have to publish nothing, or they'd have to publish their changes that allows talking to the magical internal logging protocol.
Do I need to include my super secret storage engine X because my modification requires that I use it
If you are hosting the software with your super secret storage engine, then you have to be ready to provide the modified software code to anyone who uses it. If all your users are internal then cool you get to keep it internal - though there's no restrictions on who they can send that code to.
You modified the code to improve it for a use case. The whole point of AGPL is that you if you start distributing that modification then you don't get to keep it a secret and prevent it from being upstreamed. The original project might not even be interested in your changes if it's only for some super specific use case.
If the client talks to service A, which talks to AGPL service B, I assume that would count as having to "prominently offer the source code for service B". No? If that's true, then it becomes a real pain to track all the places where an end user could indirectly come in contact with service B.
If that's not how to interpret the license then wouldn't a simple API gateway or proxy circumvent it?
then it becomes a real pain to track all the places where an end user could indirectly come in contact with service B
Easy solution: then you just publish your patches for anyone to get. Or just anyone with a login to your SaaS. If you haven't changed anything then they can just get the original source themselves.
They define it earlier in the license:
To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
While the AGPL might be untested, copyright isn't, and I don't think any copyright lawyer would say that "calling over the network" is adapting "the work in a fashion requiring copyright permission".
I agree with you, and I'm perfectly happy to use AGPL in this way for my own stuff, but my employers have not been.
There are a few companies who try to make it sound like if you interact with an AGPL program over a network then your client code is now infected with the AGPL
Of course not, or
1. Any web browser would have to be open sourced, and
2. That would be the consequence of an action taken by a third party (eg: me) and not by the parties that created the web app and the web browser.
The AGPL requires you to publish all of your source code if you make any changes to the product; the Elastic License just says, "don't use our code to make a direct competitor to Elasticsearch"
"changes to the product" means changes to the service itself, and "publish all of your source code" means the specific service, not for everything you build. If you patch the ES service you make the patch public, but you don't need to make any service calling ES public. That is pretty static and controlled on your end.
On the other hand "direct competitor" can change over time, so that if elastic buys a competitor to my product or reinterpreters what it means to be a competitor it changes how I can use the software. Say you were early into ML stuff and built a RAG on top of ES, ES will probably offer that soon as a service (if they don't already) so now you are a competitor without any change to your business. Or you want to launch a small project that is ambiguously adjacent to a component (with these non-OSS licenses) that another team within your company uses from a third party. That now becomes a huge legal liability and risk, regardless if you use that exact component to compete with that supplier or are even aware of it.
At least that is the way I've understood the risks of these non-OSS licenses and have gotten similar advice from lawyers at major users of OSS.
The words of the license are "You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.".
I don't think competing with ElasticSearch is mentioned anywhere within the license. If team 1 uses ElasticSearch and team 2 is developing RAG (without using ES), then that's not an issue (but only if using the most recent version of ES, since the license for the code that I fork today has no bearing on future code that ES hasn't written yet).
They're probably mixing up the SSPL with Hashicorp's version of the BSL, which does talk about competition [0].
It is authored by MariaDB, actually.
Hashicorp is just one of the company using it.
Yes, but MariaDB's doesn't have that clause—it's part of the Additional Use Grant that Hashicorp added.
Yes, we don't have that competitive clause — it's Hashicorp [I work for Elastic]
This is why the proliferation of these custom licenses is yet another self-own by these companies. To HashiCorp, their own products are special unique flowers and deserve their own license, but to their customers, HashiCorp is just one of dozens or hundreds of vendors. Adding layers of confusion and risk to using their software is not going to encourage anyone to try it out.
Ah, yeah, that sounds right. I was under the assumption that they had similar restrictions.
For the most part I don't think people are against shared source or closed software existing, being sold, being marketed, etc. There's really only two things people viscerally don't like:
- Marketing a project that isn't open source as open source. Debate about what the "definition" is or why it matters all you want; taking a term and using it in a way that contradicts the vast majority of domain experts is bullshit.
- Taking an open source project, which people adopted on the basis that it was open source, which people contributed issues and pull requests to on the basis that it was open source, which people evangelized and promoted because it was open source, blogged about, built on, and so forth because it was open source... and moving it to a license that isn't open source.
To be clear: yes, the unforced error here in many cases is accepting a CLA. That said, I think it's not even unreasonable that people initially accepted CLAs: many of them presumably believed they would only ever be used in good faith, as a sort-of CYA. But CLAs are now very commonplace, so refusing to contribute to any project with a CLA requirement is hard.
If nobody cared about the benefits of open source, then it would be easier for companies to just start with a closed or shared source offering and call it a day; not much backlash for not changing a license. Clearly, marketing something as open source helps... but once you've gotten what you need out of it, it's easy enough to click a button and change it back to being closed.
In my opinion the big advantage of open source is that everyone is on a level playing field. This isn't "fair", it's balanced, and that matters if you are serious about long-term software. If shared-source software is discontinued, that's probably the end of the road for it. For open source software, it only depends on if there are big enough stakeholders to keep funding development; it never has to stop.
There's ideas like BUSL, which might work better... but it's still awkward and experimental. I don't put much stock into any of the other "shared sorta-like-open source" licenses, they're mostly bullshit and sometimes catastrophically horrible, i.e. much worse than AGPL.
I would rather a software product be eventually open source than use a never open source license, but I still try not to use it if I can choose open source. And I refuse to sign CLA's that require giving more eights than the license grants to me, and won't sponsor projects that require them. (with some limited, carefully considered exceptions for well established open source foundations that require CLAs, but that have sufficient gornance to add trust)
Out of curiosity (since I'm pursuing an AGPL/proprietary dual-license), how would you consider a CLA that explicitly tied my right to sell the proprietary license to releasing under the AGPL?
Smolblog shall be entitled to make Your Contributions available under a proprietary license provided Smolblog also makes Your Contributions available to the public under the terms of the GNU Affero General Public License version 3 or later.
That gives you more rights than it gives me. I was always free to release my patch under the AGPL, why would I need you to do it? (well, if you do it I wouldn't have to maintain a fork, which is something I will admit).
It would allow you to maintain a proprietary product with proprietary features that you don't release under the AGPL and use my code within that product.
I like reciprical licenses, if I get code from you under the MIT license, I will give you code back under the MIT license (which you can use however you want to, under that license, just like I can.) On the other hand if you give me your code under the AGPLv3, I give you back code under the AGPLv3 (and you can take it or leave it, so long as if you take it, it is under the terms of the AGPLv3 license).
At least, that is my idealist stance. But in reality, practicality sometimes takes precedence, so I might make a minor bugfix or something. But then I have all the trouble of reading the CLA, making sure I understand it, and agreeing to it, so practicality may just as likely lead me to just file an issue instead and patch my own copy.
I think you make good points here, but it's also annoying that the words "open source" are defined to mean something a lot more specifically detailed than what the words themselves intuitively mean.
For instance, your post calls things "shared source", which, to me, is a lot less clear of a description for the projects you're describing that way. ("Shared" how? Shared ownership? Or what?)
I think "source available" is intuitive and fine (and better than "shared source"), but to me it's still a bit weirder. To me, it sounds like if you send the company an email, they might send you back a zip file with a bunch of source code. But most of these "source available" projects operate just like any other open source project.
But I'm also not unsympathetic to your arguments here at all.
"Shared source" comes from Microsoft's initiative, back in Ballmer's days when they were attacking Linux with FUD campaigns and patent threats (which continued well after their "Microsoft changed" marketing campaign).
https://en.wikipedia.org/wiki/Shared_Source_Initiative
The software industry called their initiative for what it is. Whether it's "shared source" or "source available", it's a poisoned gift. In the case of Microsoft's shared sources, this was because it was opening up readers of that source to the possibility of patents lawsuits. I remember for instance that Microsoft was making more money from Android, by threatening phone makers with patents, than they did from Windows Mobile.
BUSL is the worse of both world imho. People are not willing to send patch or contribute to something that is not yet open source and vendor thus does not get any benefit of having openly readable sources.
Same applies to BSL and similar. Not being able to compete with the project owners is much less restrictive, for me, than AGPL/GPL.
But it restricts your ability to use a commodity product based on Elastic, provided by a third party who will compete on price or bundle it with other cloud services.
Yes, but what I'm more interested in is self-hosting. I couldn't care less that someone else is unable to profit off of others' work.
And of course the third party can compete on price, they don't have to develop the actual software they're selling!
GPL is viral and somewhat compatible with AGPL.
BSL and GPL code are probably never mixing since they prohibit each other. This creates friction in GPL world and tends to produce incidents line this [1] out of thin air.
Sure, but the issue that you link is different. The "problem" there is that Debian (and many others) only distribute software that complies with the open source definition of freedom, which Crockford's license and the BSL runs afoul of as they both discriminate against uses. So, this is about what some are willing to distribute, not license compatibility.
It feels like Elastic got burnt with the license change, their stock is down 40% since they announced the fork, and they are starting to realize that being open source is important. I don't think AWS would abandon the fork given the amount of efforts they put in, they cannot walk back and re-brand their products.
It's sad to see elastic turning sides for their benefit, and as a contributor I feel betrayed. While OpenSearch on the flip side is more contributor friendly. I honestly feel all energies should be focused on one product to make it better instead of walking in different paths. Amazon has already taken that path and I don't think they will ever walk back, unlike Elastic.
My understanding (after talking to several market analysts) is that OpenSearch is focused on APM/monitoring/log-aggregation, while Elasticsearch has an edge on pure search engine functionality and now AI.
That's because the license change by Elastic impacted not only Amazon, who could not provide Elasticsearch as a service anymore through its administrative consoles, but also all those vendors who were building APM/monitoring/log-aggregation solutions as-a-service on top of Elasticsearch. In fact, such vendors would typically use Elasticsearch as a back-end behind some custom UI.
So those vendors teamed up with AWS to develop OpenSearch.
Now last time I checked the commit history of the two projects, Elasticsearch had 3x more commits and many of them on cool new stuff, while OpenSearch focus seems to have remained on APM/log aggregation.
As someone who needs an actual "search engine", I am glad of the change, as I was worried OpenSearch may not be a viable open source alternative as it could be lagging behind in this domain.
Now I need to check what happens with the clients: will the client remain Apache License or will they change to AGPL? The latter would be a problem for closed source software.
My understanding (after talking to several market analysts) is that OpenSearch is focused on APM/monitoring/log-aggregation, while Elasticsearch has an edge on pure search engine functionality and now AI.
Not in my experience. AWS is fully behind using opensearch as a search engine. For AI, hard to see how Elastic can compete with AWS...given it's vast resources and deployed products.
I think your comment around the dip in their stock price is fairly misleading because it lacks context of the market sector overall. When ETSC announced in January 2021 their stock was around 150 and by November 2021 it was in the 180s, so the change very much was not responsible for crashing their stock - the market was. Their entire industry sector was pounded heading into 2022 and has never recovered. For example Datadog crashed from ~$190 to $80 over the course of 2022.
It’s impossible to know what would have happened if they had continued on their existing path. My guess is Amazon would have eaten their lunch and they’d be in a similar situation.
If you use the Elastic license, legally speaking, you're in hot waters. The biggest problem with software licenses for freemium is that you have no contract with the company, money doesn't change hands, and the license itself can be open to interpretation. What's a competitor anyway? This sounds like that JSON license saying you shouldn't use the software for evil.
The Open Source licenses have been vetted and are time tested. That's one big reason for why Open Source is valuable. When you adopt an OSS project, you know exactly what you're getting, and the legal departments of corporations are prepared for it. Some are banning copyleft licenses, of course, for good reasons, but the knowledge is there.
Personally, I wouldn't touch the Elastic license.
The Elastic license doesn’t use the term “competitor”. To me, the definition of the limitation is actually pretty clear:
You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.
It doesn't use the word, but "access to any substantial set of the features or functionality of the software as a hosted or managed service" is a specific kind of competition, and who is a competitor can change at any time depending on what functionality Elastic adds, even if you had reimplemented some of the enterprise functionality in a private fork.
Imo "substantial set of features" is pretty ambiguous. If you're using search software, then you have a search use case in your product. At what point does your product cross the threshold into a competitor?
It seems risky to use in anything exposed as a customer facing feature
Search may be 10% of your software but what if your software is a managed email provider (or really anything) and you're pretty much exposing Elasticsearch directly through a minimal interface?
To me, it's weird that the AGPL is any more "open source" than the Elastic License. The AGPL requires you to publish all of your source code if you make any changes to the product; the Elastic License just says, "don't use our code to make a direct competitor to Elasticsearch". I find the former to be much more restrictive in most practical ways since the majority of companies don't want to open source their code, but very few of them plan to sell hosted search.
The four freedoms of software are: the freedom to use the software for any purpose; the freedom to study and change the software; the freedom to share the software; and the freedom to share one’s changes. The AGPL permits all four; the Elastic License does not allow using the software to make a competitor; therefor the Elastic License is not a free software license.
More details: https://www.gnu.org/philosophy/free-sw.en.html
Who wants to put in years building a business …
Free software is not about the original author of code; it is about the users of that code and what they do with it. Copyleft ensures that those who build upon a software foundation grant the same freedoms to their users which they themselves received. Free software is about the users.
the four freedoms were not written by God, just a bunch of ideological pedants.
it's perfectly valid to have a completely different view of what freedom is for software
That is a very US-centric perspective on freedom, and one that isn’t actually very helpful in assessing actual real-life restrictions of a license. You may win the philosophical argument on the nature of freedom, but you lose the debate participants. If both the vendor can’t continue working on the software, because they’re unable to monetize it, and the user is unwilling to use it due to concerns over exposing business secrets, the outcome is a net-negative, no matter how venerable your cause might be.
The AGPL is more restrictive than the nonfree license because the AGPL is also a nonfree license.
I await the day that the industry corrects itself and stops calling the AGPL open source/free software. It isn’t. It is very obviously a EULA, despite what the anticapitalist zealots at the FSF wish to claim.
It is very obviously a EULA
It's really not, because the end users of your service, that being whoever consumes them, does not care about the AGPL and CAN close source their code.
If I call an AGPL service I can do that from a proprietary application. What I can't do is publish an AGPL service, modify that service, and then hide the modifications. So it works just like GPL in that way except instead of, like, including it's publishing an internet-available service.
Companies are super scared of AGPL but that's just because they're scaredy cats (sorry, "risk averse"). But no, you're free to publish an AGPL service and you can even monetize it, if you want. You're also free on the client-side to do whatever and have whatever license you want for your code.
If a vendor goes under, I can self-host.
It's worth mentioning that this is true -- to an extent. Under ELv2, if the vendor goes under, you can self-host, but you will eventually lose access to any features protected by a license key if/when that license expires, since said vendor can no longer renew said license.
This was one of the main drivers for me writing the FCL [0], which undergoes DOSP [1], even for the protected features.
[0]: https://fcl.dev
You also can't pay someone else to host it for you. Nor will the community be able to fork it and support development by paying one or more community members to host it for them.
At least with DOSP, eventually the community will be able to do those things.
This is exactly where I'm at.
I find what seems to be the prevailing opinion of people here (and in similar places) of passionate opposition to these kinds of licenses to be very mystifying.
It seems to me like they hit a pretty good spot on the continuum of trade-offs here.
I might add one, which is related to your third bullet point, but which I avail myself of far more often:
* If I'm confused by how something seems to work, I can read the implementation.
The AGPL requires you to publish all of your source code if you make any changes to the product; the Elastic License just says, "don't use our code to make a direct competitor to Elasticsearch". I find the former to be much more restrictive in most practical ways since the majority of companies don't want to open source their code, but very few of them plan to sell hosted search.
There's two ways that this doesn't seem right to me, though it hinges on the vague term "interacting" and how it's interpreted.
Suppose I use Elasticsearch to power website search on my company's website -- maybe something like a customer support knowledge base of a bunch of FAQs and support articles, and I make some modifications to Elasticsearch to better fit my requirements. My website makes calls to an Elasticsearch service to provide search results.
1. Based on my interpretation of the AGPL, visitors to my site who make searches are not remotely interacting with the Elasticsearch software that I am running; they are not sending requests directly to the Elasticsearch software, and thus they have no rights to its source code under the AGPL. (I'm not suggesting that a proxy server that passes on requests and responses unmodified would be the same situation.)
2. If they do in fact have rights to the source code, it is only to the modified version of Elasticsearch, not "all my source code" (which could include the web server software itself).
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. https://www.gnu.org/licenses/agpl-3.0.en.html#section13
In AGPLv3, what counts as “interacting with [the software] remotely through a computer network?” If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...
Your users might want to benefit the same rights that you are listing. Hence the GPL family of licenses.
The Elastic License prohibits you from moving, changing, or disabling some of the software's functionality. It's a limited compromise, and I understand why it's necessary to achieve their business objective, but it's pretty straightforwardly not compatible with the open source ideal.
Imagine what the web would be like if React users weren't allowed to compete with Meta.
Here’s the initial AWS response to the license change that they made in 2018, which I helped write. At the time we didn’t think a new license made sense, as AGPL is sufficient to block AWS from using the code, but the core of the issue was that AWS wanted to contribute security features to the open source project and Elastic wanted to keep security as an enterprise feature, so rejected all the approaches AWS made at the time. https://aws.amazon.com/blogs/opensource/keeping-open-source-...
Unfortunately many companies charge extra for security where security should be the default. Truth to be told there some some situations where extra security costs could be justified but there are not many if charge is necessary it should be considered as a temporary measure. My $0.02.
Including the recent trend of access to SOC2 reports requiring an "Enterprise" tier subscription.
In fact I like the change. This allows them to make almost everything free of charge to individual/small companies, but could fund it from revenue of larger organization, who generally don't have problem paying.
And what of small companies that need things like SOC2 reports from vendors?
If you want to work with large companies, being SOC certified makes it easier. Part of that is ensuring your vendors are also compliant with good standards and that's best done with SOC reports.
Getting SOC 2 compliance alone takes ~10k USD apart from vendor reports. Yes they may be small with employee count, but when I said small I just meant someone running something for small set of users for free or close to free. Not someone working with other enterprises.
I don't mind them requiring a paid tier to get the detailed compliance level reports, but requiring the most uber expensive "call us" plan is probably too much for many smaller companies that might still benefit from easier SOC2 complaince.
I have the same problem at the moment with Supabase. We're a startup trying to get ISO 27001 certified and need to upload Supabase's SOC2 report to Vanta, but we can't because we're on the Pro tier and they don't give access to that, even after emailing them. It's ridiculous.
It is even more ridiculous because it costs them nothing to issue an extra copy of this pdf report. They need to certify anyway because their enterprise customers will demand it.
Or worse, "SSO" as an Enterprise feature. You're a 2-3 person startup, you set up GSuite, you want to set things up right, oh, "$Call us" for a tier with SSO. Nope, I guess disparate users for now. Not the worst in the world to be clear, but an entirely arbitrary gate, in my experience.
Yeah, the SSO gates are common and borderline criminal. "The only way you can use our software is insecurely"
We got a SOC2 cert in our bootstrapped small saas company. Then we hid the report behind Enterprise subscriptions because it takes too much time, effort and money to obtain and maintain it.
We did not get certified because we wanted it, we did because the enterprise scale customers forced us to. Due to their internal bureaucracy.
I'm not sure what you mean by "security" in this context.
Identity management, role based access control, useful audit logs; all "enterprise" features, probably are very expensive to implement, and make for obvious "up-charge" product segmentation.
I suspect there's some combination of "the community doesn't add useful implementations of these features" and "we can't possibly risk our reputation based on some community contribution" and "we can use this to segment our product to sell to some and give it away to some."
This set of features seems to always get put in the "enterprise, only for licensed / supported customers" and it stinks.... I can understand why, though, and none of these are strictly speaking "security" as much as "compliance"
Using your yardstick, we wouldn’t have any open source software, everything costs time to implement, that’s the point of open source, we donate time to the collective community. All those security features are not enterprise specific, they are rudimentary for any modern open source product
I'm saying that companies that opensource their products tend to distinguish "enterprise" and non-enterprise based on things like RBAC and audit mechanisms, neither of which is "security" as much as "compliance".
The original license owner, if a commercial enterprise trying to sell the product alongside the "open" version, has less incentive to accept those features from the community as it would reduce their sales of the enterprise version of the same thing, and may not align with their long-term product roadmap.
In open source, the team managing a codebase isn't under any obligation to accept contributions the community and you are welcome to fork the project, if you like.
RBAC is absolutely a practical security control, even for non-commercial users. Least necessary privilege is not a checkbox, it will 100% save your butt in a breach by limiting blast radius.
I think it's fair to say most security is built-in by your average developer. However, the security side of things needs efforts from a far smaller pool of experts that can make your tool as secure as is possible. I don't imagine it is as cheap to find feature developers as well as security experts or security developers. Practically speaking, cheaping out on security might cost you the reputation of the app, so doing it well will be expensive but worth it, but might never be worth it if you offer everything by default but in the end only a fraction of your customer base uses the features.
"as AGPL is sufficient to block AWS from using the code"
I have taken this position in another thread a while ago, but the responses seemed to indicate that this is not a clearly cut situation at all. If it was, what is the point of the "source-available" licenses in the first place? I mean, the idea that they were invented to cut out AWS is pretty prevalent, no?
AGPL doesn't forbid Amazon from providing a competitive service using the software. Elastic License/SSPL/BSL all do. That's the difference.
It also ensures Amazon can’t add any secret sauce to the code they offer - everything must remain open.
translation: AWS refuses to provide unmodified open source hosted software as a service or to open source the changes they make to host it.
It's not a "can't" it's a "won't".
Well, the comment from OP isn't necessarily complete. The AGPL is not about preventing someone from using source code (indeed that would be contrary to the spirit of all liberal and copyleft licenses), but rather the condition under which source code modifications need to be made available.
Specifically, if you offer the software for "Remote Network Interaction" (AGPLv3 section 13), well, "if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version".
I think the original challenge with AGPLv3 vs (to grossly generalize) the VC-backed open source corporate ecosystem was not around source code, but around monetization as SaaS by the hyperscalers. The problem there is even if the hyperscalers publish source code modifications (which they probably have no problem with) they have such sales efficiency and gravitational pull that they will end up eating your business.
There's enough legal uncertainty about API calls being considered linking that it keeps coming up. Minio are probably at the forefront of claiming this somewhat implicitly while referring you to your lawyer (or their pricing page, preferably) when asked about how they understand the AGPL.
FSF/GNU have an example of an AGPL proxy becoming compliant by serving it a page with the offer to download source code on the first request, pretty far off from reality if you ask me. That's also the big other issue, AGPL is unclear about conveyance over a network. Does a header work? Does a link to the source repo work or do you need to offer hard copies? What do you do if the "networking" is a highly specific protocol that simply can't make that offer over the wire?
I much prefer the clarity of intent of the EUPL.
Out of curiosity, did you pursue a rev share model with Elastic (Co) for your Elastic managed service? I guess that's not something thay can be discussed openly but recognizing you probably had 10x their revenue in the managed service and another 10x their revenue in compute behind the OSS, I wonder if there could have been a proactive happy middle ground found years ago.
I suppose that they might not have accepted something that was too small percent wise and hence might have preferred to go head to head no matter where that might have gone.
My real sense for why they've struggled to out maneuver is their lack of execution on their managed service (9 years in market, still minority of their revenue); while you had a head start and I'm sure that's what they point to as preventing execution, if they had really focused there they might be more like Confluent in terms of being considered the well regarded SaaS leader in their segment.
But I do think it'd be a good look for AWS to proactively help these companies. I didn't think the approach taken with Grafana Labs was right... that looked more like a Faustian bargain to an outside observer (e.g. we'll cut you down at your knees and directly compete but offer you their more expensive version on our paper. It looked incredibly humiliating).
From previous threads, my understanding is Elastic is a pretty arduous enterprise sales process which turned a lot of small/mid customers away.
High vendor management overhead is a huge pain for smaller companies that don't have robust IT to manage those relationships.
The smaller/mid size startups I've worked at almost never acquire "enterprise" software and always leverage pay-by-credit-card type SaaS
Besides operational overhead there's also a much longer acquisition time (no one wants to spend 3-6 months working with a sales team to sign a contract on a project with 2-3 month timeline)
Totally and that goes back to their lack of execution as a managed service/SaaS offering because the GTM for those is different, more self-service. If you can't unwind yourself from selling a heavy weight legacy style enterprise software package, you struggle to execute in SaaS, you burden yourself to be understood by your customer as the opposite of modern.
About this topic I'm going to say that at my company we had to choose a managed solution for logs, and there were several contenders. I strongly wanted to use the service offered by Elastic, the company, as we were already managing a lot of biggish clusters and we thought that going with the company behind it would be the best thing to do.
But they made it very difficult to try it out at scale (we generate quite a lot of logs) and at one point they only wanted to talk to the CTO instead of the persons in charge of the PoCs.
That move made them untrustable to me, and they were disqualified from the process. If they wanted to compete on selling the solution to non-technical people that told us all we needed to know about them and how support would be. We ended up choosing managed Opensearch by AWS, which was a shitshow in several fronts. I wish we had given Loki a bigger chance at that time. We've ended up migrating to it anyway.
But I do think it'd be a good look for AWS to proactively help these companies.
But how much value does "a good look" have to AWS?
Depends on who sits in the antitrust seat. It's pretty incredible to realize the one who does today wrote this a few years ago: https://www.yalelawjournal.org/pdf/e.710.Khan.805_zuvfyyeh.p...
I don't know if this was part of the issues but adding authentication to Elastic APIs and Kibana is so confusing and complicated that it is almost impossible to do unless you go for a managed solution. I'm sure that one factor alone motivates a lot of users to buy the service instead of hosting their own using the available source.
Yeah, this is an underrated aspect of all the managed hosting options out there. If vendors made it easy to deploy their code, folks would be far more willing to run it themselves. But just rolling out a simple production-ready cluster of most software is a nightmare of complexity. (Note that while open-source software is often not great at this, proprietary software is often just as bad or worse. This is not a side-effect of open-source. It's a failure of prioritization of the operator experience.)
But why couldn't you or AWS donate/pay to Elastic for what they created to get those features in? I understand the security features you mentioned is very necessary, but Elastic will lose revenue because of this, and they are not a trillion dollars cap tech giant like AWS to support the project for free.
Too late, the community all moved over to OpenSearch.
I'll never forgive Elastic for locking basic security features behind their paid licence. Over the years probably millions of people had their data compromised due to that (due to people inadvertently leaving instances on the public internet - having auth enabled by default would have helped a lot)
I think it's pretty sad that Conglomo X can take an open source product, add some tweaks and sell/capture the entire market. Basically taking all the work that open source maintainers have done.
What's the solution here?
Source available + MAU/ARR restriction clauses that prevent hyperscalers from robbing the bank.
Because that worked so well for Elastic here.
Elastic waited until it was too late.
I've always been a little sceptical as well of the grassroots (maybe, maybe not) resistance on here against any efforts to stop the big 3 from using their network effects to syphon off the revenue from these projects.
The messaging against elastic style licences and even copyleft licenses is too convenient for me to trust as being 100% genuine.
These handful of companies have employed legions of people at this point and I think plenty pump their own brand, not unlike colleges with their alumni networks.
The main incentive for maintainers of open source software is to see many happy users of this software. Most open source maintainers do not care about monetizing their products (or the monetization has very low priority).
That's why most open source maintainers use truly open-source licenses for their software - BSD, MIT, Apache2, and they will be happy if Amazon, Google or Microsoft builds successful product on top of their open-source software, since this gives them the desired recognition.
This is literally what open source is. If you don't support this, you don't support open source.
There isn't a 'purer' form of open source which does exactly what you want with respect to big companies using the code.
You can be in favour of licensing that restricts Amazon or Microsoft's right to use your work. But that position is detrimental to, not supportive of, open source, since such a license would not be open source.
Like elastic did to Apache Lucene, the core of their product?
Or when they infected their previously open source components like logstash?
What is "the community" here? Every metric I'm able to find (commit frequency, gh stars, gh stars gained since the launch of opensearch, stack overflow tags, google search result counts...) suggests that OpenSearch didn't really take much of Elastic's mind share in the end. Each metric I've looked at shows OpenSearch at somewhere between 20%-50% of Elastic's numbers, which isn't nothing but is a far cry from "the community".
I've heard a few anecdotes suggesting some people took it seriously, but while we're sharing those: my company actually adopted ElasticSearch since the license change and never seriously considered OpenSearch.
Last time I deployed elastic was years ago. In the meantime I deployed hundreds of opensearch instead for customers.
Are you the one who makes the call, or are you getting hundreds of customers requesting OpenSearch over Elastic?
If you're making the call then that's really one anecdote, not hundreds.
I let the customers choose by themselves. And guess what they choose every single time after checking license cost from Elastic.
If you're referring to the SSPL (it's unclear), it can be used without obligations when a service uses it as a storage, rather than providing it as a service to the clients. Since the latter case is essentially cloud companies, I'm confused by the business nature of the "hundreds of customers"; if they're not cloud companies, Elasticsearch pre- or post-license change makes no difference.
SSPL is also preventing DevOps/services companies to deploy for their customers, it's not affecting only cloud providers.
Do you tell them that it's deploy OpenSearch or buy an Elastic license, not mentioning that they could also legally deploy their own Elastic?
If only they had the skills to deploy and maintain it sure. But they don't so they ask services companies/DevOps to do it for them. No need to be AWS to be affected by SSPL
Counterpoint: I just got introduced to the ElasticSearch/OpenSearch products and have gone with Elastic
Yes, let's praise and reward the hyperscaler and not the small company that is 1% of the size of AWS.
AWS got Elastic's goodies for free. They just came in and gobbled up all of that value for themselves like vultures. Meanwhile the people putting in the work effectively got robbed.
Small companies should stop doing open source and switch to source available + MAU/ARR restriction clauses.
the small company that is 1% of the size of AWS
What on earth? Elastic is a multi-billion dollar company. They are no indie startup, scrappy underdog nor are they victims here.
AWS took the high road during this fiasco despite Elastic's mudslinging and flailing about.
What on earth? Elastic is a multi-billion dollar company. They are no indie startup, scrappy underdog nor are they victims here.
AWS took the high road during this fiasco despite Elastic's mudslinging and flailing about.
They didn't start as a multi-billion dollar company. In fact, AWS started shipping their Elasticsearch Service in 2015. Public records show that Elastic's annual revenue in 12 months after their IPO in 2018 was ~200m with <1000 employees.
I'd argue that Elastic is a multi-billion dollar company _in spite_ of AWS.
The small company with over billion dollar revenue and thousands of employees?
They shouldn't stop doing open source, they should just make sure they use the correct licence, like AGPL. Businesses will always take as much as they can and give back as little as they can. The "permissive" licences specifically allow them to give back nothing. Cue shocked Pikachu when they do exactly that.
That's hugely overblown.
Maybe 20% of the companies I work with have switched.
Maybe 20% of the companies I work with have switched.
Smells like opportunity!
It's the new users where the pain is. A lot of companies that were using Elasticsearch indeed haven't switched because doing so is a bit of work without a lot of advantages. But all my new clients are defaulting to Opensearch. It's not even close.
Source? Unless you're locked into the Amazon flavor of cloud hell I'm pretty sure most people are using the "real" elasticsearch. I know I am.
We have a vendor that refuses to support ES 8.x due to license fears, so we're just migrating everything over to OpenSearch.
Yeah, it hasn't been nearly long enough for "everyone" or even most people to migrate.
They did? I can't stand all the missing parts around documentation and the lesser known pieces like Spark integration - horrible.
[D.N.A.]
[LOVE.]
I don't understand what these are supposed to mean. Is this a new writing style, song references, or just a quirk of the author?
These are songs by Kendrick Lamar. I guess that these were used to try and add a youthful, lighthearted touch to the article? Didn't work on me though.
I'm a fan of that album and I didn't even realize the reference. Is there any other point to it?
Their marketing department is run by children?
Subliminally heart warming. Just look how the article ends:
Forever :elasticheart: Open Source
[Count me out] No reason to use Elasticsearch in 2024.
[i] am still not going to use Elasticsearch [For Free?] again?
I really hate this corporate trend. The soundtracks to all of our company meetings are basically mostly songs about wanting to fuck that girl you met in the club last night and I seem to be the only person who finds it incredibly inappropriate for the setting.
It kind of reads like it was LLM generated..."Write an announcement/apology about ElasticSearch finally being open source again (for now), where each paragraph starts with a relevant title from a Kendrick Lamar song"
To me, at first, it read as satire - but that doesn't make sense, coming from the official blog. Being LLM-generated is a plausible explanation - considering the circumstances, saying "open source is in our DNA" is right inside the uncanny valley.
Not like us is pretty new (may 24), not sure any proper llm could have been trained on it. All big openai models know nothing about 2024.
Nothing a simple "Browse the Web" plugin/tool before replying can't fix ;)
They are Kendrick Lamar song titles. Not clear to me why, though
Seems to be references to Kendrick Lamar songs... for some reason?
All those are Kendrick Lamar tracks. Highly recommend if you're into hip hop.
Okay, cool. No notes, that's neat.
Are there any SMEs that have worked with both OpenSearch (the fork) and ElasticSearch? Are there significant differences?
I know the AWS fork had the big difference back then of having RBAC built into their Kibana portion.
OpenSearch has terrible docs.
Can’t be worse than Solr heh.
That's so quintessential AWS :P. Even only for this Elastic should be compared to not waste 10s of hours on poorly written documentations.
I've found OpenSearch to be a bit flaky but I haven't worked with it very seriously compared to ElasticSearch
(and before OpenSearch, the AWS-managed ElasticSearch absolutely hurt the ElasticSearch brand because of all of the issues Amazon created - it couldn't even rebalance shards, let alone add new nodes or switch to larger nodes without a blue-green deployment)
This would be the same period when Elastic didn't even have a cloud offering....
Elastic bought found.no, which became Elastic Cloud in 2015. That was years before Amazon forked Opensearch. The AWS hosted Elasticsearch emerged around the same time.
Pure hearsay, but apparently ElasticSearch is considerably faster than OpenSearch. Would be good to compare the sources again, but I don't see any links to source on elastic.co yet.
That would be strange as it's largely based on the same Lucene library.
I support both professionally. The last Apache licensed version of Elasticsearch was a very capable product and Opensearch inherits all of that. In the few years since the license change both products have evolved a little bit but the vast majority of those changes don't really matter to new users. Both products use the same core component, which is Apache Lucene; which powers all of the search features. If you are a new user, there is very little reason to prefer Elasticsearch over Opensearch. And this is confirmed by the fact that most of my new clients default to Opensearch.
The exception to this might be vector search, which is a relatively new feature that was implemented on both sides post fork. Lots of users want/need this. And both Elastic and Opensearch provide independent implementations with very similar feature sets. Both build on what Apache Lucene offers on this front. So there isn't a massive difference between the two. But I would give the advantage to Opensearch here since its implementation offers a bit more beyond just the Lucene support.
Kibana had a lot of closed source components before the fork already and Amazon fork of that is a bit more limited. But notably Amazon indeed re-implemented the security layer (before the fork actually), which on the Elastic side is a bit of a dumpster fire of complexity. In general I'm not impressed with the product from a usability point of view. Either on the Elastic or the Opensearch side. But the Elastic version is arguably a bit richer in features.
Some notable recent changes there include trying to introduce a new query language based on SQL and the whole fleet ecosystem (an agent based system) to get logging and other data into Elasticsearch. I don't think either is getting a lot of traction because of the licensing.
The spark components were rushed and the documentation is super crappy.
Elasticsearch hands down for this area.
For most use-cases (indexing denormalised data as documents then running searches against them), there's little difference between the two. The mechanics of how the cluster operates are almost identical.
There are some Elasticsearch features that were part of X-Pack (their commercial offering) so aren't included in the OpenSearch fork. Some of those features are really nice to have and make life much easier; the enrich ingest processor is something I really miss in OpenSearch.
The biggest differences are in the tooling around Elasticsearch. All the observability stuff, the SIEM features, various integrations, and now the AI fluff. I've worked with clients in different sectors and - aside from the observability stuff (which is really nice) - none have had an appetite for any of that.
The OpenSearch team is doing some really cool stuff and the project has come a long way. I'm sure it'll continue to improve. It has a very loyal customer base and even has its own annual event; OpenSearchCon 2024 is next month!
For use by businesses, the AGPL is a nightmare from my perspective. What does it actually require on behalf of a company using AGPL components? If I write my own library and link statically I need to release that? What about if I link it dynamically? What if the library is running on a separate machine and is separated by the network?
I'm sure there will be people commenting in this thread that they understand exactly what the AGPL requires, and it's not that bad, but their opinion matters much less than the opinion of lawyers.
I've never been able to get lawyers in a business setting comfortable with us using AGPL components, for fear that it will be interpreted at some point to require us to release our application source code.
As a result, we've never been able to use anything licensed AGPL in a corporate setting.
The AGPL is actually pretty clear:
if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version
To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
Calling over the network is definitely not "adapting (...) in a fashion requiring copyright permission". While the AGPL might not be very much tried in court, copyright is.
It’s not the network call, it’s what you do with it.
Let’s take redis, pretending it’s AGPL.
Adding a new command to the source code: definitely a modification.
Adding a new feature to the redis client: also a modification.
Creating a class (RedisPlusClient) that inherits from its client and adds a feature: Maybe a modification? Feels modification-adjacent.
Building a microservice that uses the redis client and exposes the exact Redis API? I don’t know! Maybe? Feels like a technicality that it is “using a network call” so it doesn’t count.
The thing is, I don’t want to think about any of this. I want to build things. We have seen overwhelming evidence that for-profit companies give back to open source, both through contributions and open sourcing their own code.
Are these licenses limiting the actual impact of the projects in exchange for ideological purity? There is consistent feedback from engineers that this is the case.
I don't disagree with those new examples, though you've moved the goalpost quite a bit.
I didn’t mean to. I very much don’t know what would or wouldn’t be considered a violation. I think there’s a not-insane-or-bad-faith argument that each of these violate what AGPL is trying to do: force modifications to software into the public domain.
To the people who do love copyleft, I could imagine them not agreeing with a network being a clear line of modification, especially with how common distributed systems are.
For me and how I read it, I agree with you that it’s not. I also understand lawyers who don’t want to be the test case.
I think it's worth considering that stuff like Elastic and Grafana tooling at most places is just internal ops & analytics.
Elastic yes moreso can be used for user-facing search, but in general the point of these ops technologies is plug it in and let your employees use it.
If you wanna modify and have SSO and re-sell it sure yeah you should expect you're gonna need the enterprise license unless you're gonna host a purely vanilla version and layer your own auth over it, which is also possible.
just leaving this here for reference
https://opensource.google/documentation/reference/using/agpl...
Maybe the license is pretty clear, but interpretations differ. E.g. Minio provides a very aggressive interpretation of AGPL, equating to "if you use it in closed-source commercial product, it's a violation of AGPL": [0], [1], [2]. For me the whole problem with AGPL is that it's so subjective.
[0] https://github.com/minio/minio/issues/13308#issuecomment-929...
[1] https://github.com/minio/minio/issues/12829#issuecomment-889...
[2] https://github.com/minio/minio/discussions/13571#discussionc...
Yes Minio lies, but they can do that no matter what anything is.
It being clear to eng. and how lawyers evaluate risk are pretty orthogonal.
Those are the same reasons for why I avoid AGPL (and GPL frankly, because I dont want to make my frontend code fully open source either). I always thought that when a project is AGPL then I might as well consider it off limits for myself because if any of my code is touching it and then that code indirectly eventually reaches users via the network then wouldn't that also mean that I have to open source everything? I mean otherwise you could just put any AGPL software behind a proxy and you'd be instantly fine which I don't think that's how it works. In an ideal world we would have a license where you're required to open source only the changes you make to the 3rd party code, not everything that surrounds it and without restrictions on linking or network. But I guess that is too hard to enforce.
In an ideal world we would have a license where you're required to open source only the changes you make to the 3rd party code, not everything that surrounds it
Good news! That license mostly exists: it’s called AGPL.
The one where you have to open source “everything” (not really everything, but close to it) is SSPL [1], but that requirement only applies in certain circumstances.
[1]: https://en.wikipedia.org/wiki/Server_Side_Public_License
If Amazon's OpenSearch plateaus, and everyone wants to host ElasticSearch, but on their existing AWS infra/sales business inertia, this issue will fundamentally reoccur. Nothing actually changed except Elastic thinks Amazon will commit to their own fork. If Amazon doesn't, we're back to square one: Amazon hosts open source ElasticSearch, Elastic changes their license, another fork.
"Amazon is fully invested in their fork." Amazon is a cutthroat business that will change strategy if their investment isn't paying off.
That this scenario isn't addressed at the very top of your "addressing the trolls" doesn't bode well at all.
I felt like that was implied by the usage of AGPL: if Amazon wanted to start using this and apply patches on top of it, the AGPL would require that they share those patches with their customers, which would allow Elastic to integrate them into main again.
I don't think that's their intention. Elastic wouldn't be able to integrate Amazon's patches back into their codebase without losing the ability to change the license in the future. Even more, since it's AGPL, they'd have to get rid of their other licenses immediately.
Elastic wouldn't be able to integrate Amazon's patches back into their codebase without losing the ability to change the license in the future.
(I anal, even if I were a lawyer, I am definitely not YOUR lawyer, yada yada)
If I were Elastic, I would require Amazon dot com or anyone else who wants to contribute code to Elastic to sign a CLA. Depending on how the CLA is structured, this could allow Elastic to continue multi licensing?
In this scenario, Amazon doesn't want to contribute to Elastic, Elastic wants Amazon's changes from Amazon's fork (Opensearch). So they can't demand Amazon sign a CLA, because they can't offer Amazon anything for it. Amazon is fine just ... not signing and continuing on their open fork.
Elastic have lost the Schelling monopoly on what constitutes the "mainline".
But Elastic can already take the changes from Amazons fork - opensearch is permissively licensed. What they might want is that Amazon stops maintaining its fork and contributes directly to elastics mainline. I believe that ship has sailed, and it's not coming back to pick up stragglers.
Is that important, though?
Isn't the whole point that amazon doesn't care about source availability or openness, so long as they can extract profit from people running it?
I love https://resend.com/ as an example of a website that does a GREAT job explaining what they do. Lots of companies tell you that integrating their product is quick, but with their website I can look at it for 30 seconds and understand what the next steps would be.
thanks for the kind words, we spent a ton of time on the website ;)
Lots of negativity in this thread. Can we take just a bit of time to appreciate this. Thank you Elastic folks!
What are we appreciating exactly?
Maybe a ridiculous writing style for a blog post about software licensing?
Came here looking whether anyone else found the weird teenager writing style getting on the way of the real message.
I was wondering what the fuck was going on and whether this was internal community meme or style that I just wasn't aware of. Turns out it's just cringey corporate goons being cringey corporate goons.
Elastic being flexible
More like Elastic panicking when they realized the traction OpenSearch is getting at a number of companies.
Being flexible is kinda the point of an elastic.
We've altered the license terms. Pray we don't alter them any further.
It's hard to not be sceptical about their motivation.
Great, how long until they change the license again?
Depends on what new tricks ~FAANG~ MAMAA companies come up with to get as much as they can from open source without giving anything back I suppose.
Whatever you think of those companies in a wider sense, it's totally inaccurate to suggest that Microsoft, Google or Amazon haven't given anything back to open source.
Hyperbole aside, they certainly haven't given as much as they've gotten, though.
E.g., remember when Heartbleed hit, and the world learned that OpenSSL was maintained by one person getting only $2000/year for it? Fixing Heartbleed was estimated to cost half a billion dollars world-wide.
Hyperbole aside, they certainly haven't given as much as they've gotten, though.
Agreed, but the point of sharing software is that it's not a zero sum game. The thing you create once is not diminished by me using it many times.
We still have to pay our bills under capitalism, though. Software copies might be infinite, but money isn't.
Hot take: lots of widely popular open source software only exists because mega corps developed and released it.
Reference: most software in the Apache Foundation and huge portion of the container ecosystem.
I'm increasingly of the opinion that the definition of "open source" that narrowly defines open source is going to be the thing that contributes to the reduction of open source software.
Open source communities are essentially anarchist syndicates, collectively working towards common good. Groups like Amazon coming in and taking their work and selling it, profiting to the tune of millions, and contributing nothing back will fundamentally alter the dynamics of the system.
IMO, we need a definition of open source that permits me to limit users to those who aren't actively exploiting me. GPL flavors get close, but not sufficient.
I believe, genuinely, in wellbeing for all, and that we should be working towards the common good of all. Open source is one such effort, but I'm tired of seeing people say, "it's only open source if the code is also permitted to be used against the common good and for the enrichment of a very select few already wealthy people."
You can be as tired of it as you want, but tiredness doesn't change the meaning of words.
What you probably want instead is "fair source": https://fair.io/
Like their names imply, open source is about source being open. Whereas fair source is about ensuring that code is used fairly.
I would argue that people contributing to open source shouldn't be putting themselves in a position to be "actively exploited". If that's something you're worried about, then open source was probably the wrong choice. You should have sold the code for a profit instead, or established some revenue-limited source sharing (so that only indie devs can use it for free, like e.g. Unreal Engine). Or use a fair source license. Or a proprietary "source available" license.
You speak as if there is a divinely written definition for the words "open source". There is not, there's a group of people who have said, "this is ok, this is not".
I'm of the opinion that those people have made a mistake that will work against them, and they should consider revising their definition.
But... there is a definitively written definition for those words. The phrase was invented to refer to a very specific thing. Changing the meaning of the word would accomplish nothing except force existing usages of the word to change.
Like, if fair source licenses began to be referred to as "open source", then "open source" will have lost its original meaning. So now when stating that something is "open source", you will have to clarify whether you mean "original open source" or "expanded open source" (or something like that). This distinction will be very important to potential users, since it may or may not restrict their intended use case.
It's no different from if we were to start referring to reptiles as mammals. Now when a biologist wants to refer to only organisms with mammary glands, they will need to use some other term, like "milk-making mammals". It does nothing but cause confusion.
Not sure how else to explain this concept... like, I'm really just talking about semantics and pragmatism here. I don't disagree with you on ideological grounds, if that's what you're assuming.
GPL flavors get close, but not sufficient
What do you think makes it insufficient?
Stock is down almost 25% afterhours (not sure if due to this or their earnings call)
"'We had a slower start to the year with the volume of customer commitments impacted by segmentation changes that we made at the beginning of the year, which are taking longer than expected to settle. We have been taking steps to address this, but it will impact our revenue this year,' said Ash Kulkarni, Chief Executive Officer, Elastic."
So, whatever that means, is the answer to your question.
I guess it's better to have nerds fighting about licensing filling up the Internet instead of people talking about why there's a 25% decline in the share price :)
A sales org change caused 25% share price drop. Someone made a big mistake
Segmentation changes probably means more companies are in the "not interested" segment now than we'd like. We're going to throw a load of stuff at the wall this year to see what sticks.
Too late. We just deployed a new project with OpenSearch after learning from an Elastic salesperson that their licensing fees would eat up significant portions of the projects profits. Also, since it's not spelled out clearly, I'm supposing huge parts of vital functionality are still subject to a paid license, even if the core functionality is technically open source now.
Plus they lost all trust now. Who's to say they won't pull the same thing again if developers were to come back? It's not like they stopped requiring a CLA...
To be fair, though, every project of a certain size requires you to sign away your rights via CLA, so I don't think that can be held against them. (Though I admit, dispensing with a CLA would be an amazing gesture of good will.)
This is not at all true. Only projects that have the intention of wanting to be able to screw over their users have a CLA.
The obvious counter example is Linux which has no CLA.
Bit hard to trust - plus OpenSearch would continue to go strong because lot many companies have built business on top of it. Most of the centralised logging providers come to mind.
Grafana and Elasticsearch with their AGPL, are not deployable for teams that don't even want to provide a competing service because even basic security features (group membership via external OAuth source for example) are only available in Enterprise Edition (TM)
Nice, maybe they can hire some humans to write more explanatory website text, documentation, pricing information—better yet, anything on their website.
Elastic.co is the #1 example we use with our clients when we want to show how 'vague websites make you lose clients.' We show them the website and ask, 'What do you think of this company?' and 'What do you think they are providing as a service?' Not a single client, including tech-savvy ones, has been able to answer.
Elastic.co is probably one of the worst websites that somehow gained popularity despite its crappy pricing model and support. Their documentation assumes you already know everything about their weirdly vague services and have in-depth knowledge of server infrastructures.
To anyone who works for them: If you're reading this, know that your website is so terrible that it became our first example of a crappy company.
I assumed that "website that tells you nothing" was a deliberate thing, presumably because somehow they make more money as a result. It seems to be the rule more than exception.
I can't think of any company does that and makes money. Imagine Apple doing the same, they'd go bankrupt.
Well at least now you know one, elasticsearch.
what.... are those random words... in brackets??
They're all names of popular Kendrick Lamar songs. Don't ask me why though
Perhaps AI generated?
Reminds me of HK-47 from KOTOR: https://www.youtube.com/watch?v=UPeI4mX8Nus
The change of Elastic license resulted (or perhaps coincided) with the massive growth of other tools like Meilisearch, Quickwit, Loki, typesense, and more.
In a way, their original open source license was suppressing innovation. I know this is not a popular opinion in some circles of pure OSS aficionados but it seems the evidence is to the contrary
I am biting here because I don't understand the train of thought. How would such a license suppress innovation? What evidence?
For all those new search projects named in my OC to be viable, ES had to stop being “open source”. Before that it was not worth trying because there was one single dominant player in the market giving search away for “free”.
The same is happening with Redis after their license change.
I wouldn't really see it as an innovation blocker in that case just because someone is dominant. Or, if we really indulge in this wider sense, a lot of companies would block innovation too. Amazon as a whole for example, so I cannot really make the connection to the license.
You could of course argue that because air is free, it stops innovation in the air trade. But in the end that doesn't end in a sensible argument.
Since Elasticsearch changed their license, Loki has also appeared as a competitor and the Grafana machine have released a suite of tools that cover the observability categories. It may also be that the license change encouraged users to look for alternatives and there are more now than just being graylog and Elasticsearch.
Clickhouse has proven to also be a very capable database for logs and there are stacks that use it for log storage.
Loki and Clickhouse are not really excelling in what ES is. For example, full text search.
VictoriaLogs is very promising in this regard!
It's fair to say that most elasticsearch use cases aren't search based, they are analytical - which they don't 'excel' at. There are much more compelling products on the market these days.
Hasn't everyone already moved on to Open search? At this point it's more stable, which is preferable.
Too little too late. Cannot trust.
I am in the middle of the migration from Elastic Search to Open Search... Not sure what to do right now.
Go for OpenSearch. Elastic might flip the license once more depending upon how and what stock market wants.
What license are contributions to Elastic given as? I'm very confused how this works with all the licenses, are they just all compatible with AGPL magically? Or are all contributions under their primary private license, I think the last time I saw someone change a license similar to how Elastic did (maybe MongoDB?) I suggested AGPL, I don't really like the license, but it is designed for this type of thing.
I'm guessing these license models are all because they want to just plainly sell their own instances without cloud providers competing with them directly (who typically have unlimited resources to do so!) or keeping any changes or fixes to themselves (I think that was the reasoning with Mongo?).
Offtopic / Meta to the article itself:
What is with the format of this article, like if they meant for the stuff in brackets to be headings, but chose this format instead of making them headings.
The CLA best answers the questions in your first paragraph.
tl;dr: you keep the copyright but give inconditional rights for elastic to distribute your code, eg under different licenses.
There's already an open source Elasticsearch, it's called OpenSearch and it is pretty much all you need right now.
Users that had to pay the price to migrate to OpenSearch do not have a reason to migrate back to Elasticsearch.
Also, OpenSearch is Apache-2 licensed so much more usable.
Also, opensearch is free, enterprise-ready tool. It's 2024 and you have to pay for things like ldap auth in elasticsearch. https://sso.tax/
Why are they using Kendrick Lamar songs for each title?
It's honestly really weird and makes reading the post hard for me.
For example, MongoDB used to be AGPL and Grafana is AGPL. It shows that AGPL doesn’t affect usage or popularity.
I take some issue with this characterization. Let's look at Grafana in particular. Grafana was not always AGPL, and much of its popularity came before the license change. I've been in multiple organizations who only purchased a license for Grafana to avoid the AGPL terms because it had gained traction already in the organization and switching away would have been more costly, and AGPL software is still outright banned.
That Grafana is still popular does not show that the AGPL doesn't impact usage or popularity, only that Grafana is still popular.
AGPL software is still outright banned
This is just an unforced error to enforce this for a product that is literally an internal analytics tool. You can even host it and sell it as a service under AGPL! you just have to open source your changes/contributions.
The Grafana AGPL-licensed stuff has massive adoption, the few places where corporate lawyers can't get their heads out of their butts can just keep suffering.
This is their somewhat muddy response to the “trolls” who might say
“Changing the license was a mistake, and Elastic now backtracks from it”.
We removed a lot of market confusion when we changed our license 3 years ago. And because of our actions, a lot has changed. It’s an entirely different landscape now. We aren’t living in the past. We want to build a better future for our users. It’s because we took action then, that we are in a position to take action now.
This statement is confusing to me. I never found the old situation confusing, until Elastic started adding invented licenses and trying to claim openness while monopolizing the right to host their software. That was confusing.
Nice! Time to switch back real quick.
They've probably been losing market share to all the opensource vector search solutions. But anyways, this is still good.
That is great news but I have prepared my stack for OpenSearch which seems even if less feature rich but is more trustworthy.
At least there are some security features built in (OIDC/OAuth/JWT/Proxy etc.) which are dead critical to operate any software stack be it internal or otherwise.
As for centralised logging or building a search functionality, OpenSearch was already good enough back in the day at the start of the fork.
I think both ES and OS would continue to flourish in their own ways.
IMHO, this is just the beginning of the trend for reverting source-available licenses back to open-source licenses. The reason is that source-available licenses don't help increasing revenue growth rate. https://news.ycombinator.com/item?id=41266819
A bit aside but anyone have experience using elastic managed on Azure with a many terabyte+ cluster for prod? Just curious if having less control etc has ever been problem.
But es has fallen behind in vector search
This is huge. We wrote "Why we picked AGPL" only a few weeks ago, discussing why ParadeDB (an Elastic competitor!) chose the AGPL. Glad to see Elastic is joining forces on the AGPL front.
Yes, awesome news.
I made a career with Solr, but building my product, Wide Angle Analytics, on top of Elastic search, made me realize how much more robust and polished ES actually is.
With restoration of Open Source alignment I am confident we will continue building with ES as we are very happy with it.
Honestly at this point I just see little reason to invest in Elastic Search.
I have to wonder how much what is happening with terraform and tofu is related to this.
While I can understand why they went down this path, it burned a bridge and I just don’t know why I would even bother instead of using opensearch.
I guess it's true. Except you cannot contribute code under AGPL, so it's only open source in name, there is no room for a community to form around the software, Elastic co remains in sole control
Congrats on releasing under a free software license again.
We are there to complain when something becomes proprietary, there's no reason we'd not be there when the opposite happens.
"Changing the license was a mistake, and Elastic now backtracks from it"
This could have been the entire article and it would make more sense than whatever this is.
It's an interesting move for sure but I don't think it's enough. A move back to the Apache license would open up the landscape for a reunification with the now dominant fork, which is Opensearch. But that's not going to happen with AGPL + copyright transfers. AGPL + copyright transfers vs. SSPL is a choice between getting stabbed or shot from a legal point of view. It's a hard no either way for a lot of corporate legal departments.
I also don't think this will inspire a lot of companies or developers to start contributing changes to the Elasticsearch code base again; which is something that ground to a halt earlier. I saw my modest contributions under the Apache license being locked up behind this bullshit license and I learned my lesson: I'm never signing another contributor license again. My trust was violated. Not lifting a finger to help them.
Elastic suffered a self inflicted fork of their developer community three years ago and Opensearch has become the default search solution for a lot of developers and companies. Opensearch replaced Elasticsearch as a neutral ground for open source researchers to rally around. I don't see that changing in any material way because of this license change.
It's interesting that they are doing this though because clearly they are feeling the pressure and basically people using the opensource argument was cutting off their stream of new users. I consult in this space and Opensearch has become the default choice for new users. It isn't even close. Why would you pick Elastic as a first time user? They don't even consider Elasticsearch because it's all closed source and proprietary and Opensearch does the job. I don't think this change is enough to change that.
IMHO their next logical step is embracing/acknowledging Opensearch and moving their efforts to join Opensearch and supporting that. That's a huge community of users, developers and companies that's just sitting there without delivering any revenue to Elastic. It's stupid; they are competing with their own product and leaving a lot of money on the table. Elastic has all the core skills to support that community but they are just sitting on their hands now pretending it doesn't exist. They must be starting to feel the pressure to just toss in the towel and grab a chunk of that market. This our way or the highway position sure has resulted in a lot of people choosing the highway.
I think they still have a contributor licence agreement, meaning every contributor transfers the copyright of his contribution to the owner of Elasticsearch.
Could be a defensive move of Elasticsearch to win the mindshare of the community. OpenSearch has been gaining some momentum, albeit far from being comparable to Elasticsearch. See OSS Insight: https://ossinsight.io/analyze/elastic/elasticsearch?vs=opens....
I'm not sure Amazon is willing to go all in to win the war of search services, for that means they need to to handsomely reward the best coders that contribute the most to the OpenSearch project to produce insane amount of high-quality code for better and new features. See the great article Code Hard Or Go Home: https://hypercritical.co/2013/04/12/code-hard-or-go-home. Nonetheless, there's a chance that Amazon may be determined to make OpenSearch catch up with ES, just like Apple has made Apple Maps comparable, even not better than, Google Maps. Therefore, open sourcing ES with AGPL is not a bad choice to retain the talent in the ES community.
And AGPL is kinda restrictive to many large customers too, as the customers do not want to risk being forced to open source their business-critical code. In fact, many companies simply ban the use of licensed software. Therefore, AGPL reflects quite the spirit of OSS while in the meantime will not undermine Elastic's business model.
Is it still open core? Which parts are only available on the enterprise version? Couldn't easily find in their website (after this announcement).
Despite what they are claiming, they are clearly changing back the license because they felt the pain of not being Open Source anymore.
The proof that companies like that publicly under value the success that they owe to being Open Source.
But being able to use the term Open Source, by using AGPL, an OSI approved license, removes any questions, or fud, people might have.
Elastic trying to reclaim the lost ground in their original territory by re-embracing open source is a bold move. They might be hoping to attract developers and businesses back by offering more transparency and community involvement. Could this have anything to do with vector databases starting to eat into some of their market share, pushing Elastic to innovate and re-establish their relevance?
our partnership with AWS is stronger than ever. We were even named AWS partner of the year.
This detail in the post made me chuckle. Oftentimes big vendors give out these kinds of marketing awards strategically.
One big firm I know makes it a point to have its CEO present on-stage awards at its annual user conference to customer that have indicated they might not review.
Petition to make all the official blog post written like this, I love the rap songs reference
Thank you, ElasticSearch!
I know the AGPL may be a terrible license and all, but it is allowed by Free Software purists. I hope more companies follow suit.
Confused? Alternatives to Elasticsearch are
- https://www.meilisearch.com/
- https://manticoresearch.com/
and maybe
Does anyone else find the wording of this is really strange and mildly unprofessional?
Too late, there are so many competitors that are both faster and provide more features. Same will happen with Redis in 3-4 years.
Does anyone involved with MediaWiki here know how this could affect CirrusSearch? Once ES became non-OS it kinda went to hell. https://www.mediawiki.org/wiki/Extension:CirrusSearch
Looks like Elastic is bowing to OpenSearch threat. This is great news to have more Open Source choices, yet I think for those who care about Open Source the trust have been broken and there is little assurance there will not be a license change one again, serving needs of the moment
The software engineers who care enough to have an opinion probably likely don't contribute to the ELK stack, and those who are impacted by this license change are no better off. Ever since Elastic went on the warpath with their serverless cloud and Gen AI the entire "open source" pitch is moot, regardless of the license.
Regardless of the openness of their code - their observability product is grossly bloated and unimpressive, the security product is sideways, fleet is broken by design, the entire database sector is coming after their analytics use cases at much better perf + much lower costs (and winning), management look incompetent, RAG is a big bet - but unlikely to be the saving grace the stack + company needs. It's truly a product on fire. Elasticsearch was interesting 10 years ago - nowadays not so much. This just seems like a "hope for the best" distraction for scarier things to come for Elastic.
To super-simplify things: using the AGPL software, can I offer a competing service to Elastic’s?
If yes, then it is opensource, otherwise it is not.
Open source, again … for now.
It was so that AWS would create their own name for their fork:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
So correcting your enormous straw-man of misinformation is "noise"? Oh just sod off with your bollocks.
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.
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.
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%.
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.
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.
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?
Isn't elastic itself based on open source tech too? Is elastic exploiting java for example?
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.
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.
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.
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
You are not the only one, that's a ridiculous story.
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
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?
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.
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...
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.
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.
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.
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.
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.
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...
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
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.
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".
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).
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.
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.
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
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.
sunk cost. at least that’s what elastic seems to be betting on.
It's a very different open source license than their previous one. AGPL vs Apache 2.0
I don't understand why they didn't treat Amazon's previous offering as a trademark infringement.
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?
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.)
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.
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
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.
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.)
Huh? Elastic definitely had a trademark in place. Not sure why you think they didn't.
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 -
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.
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.
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.
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.
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.
Yep, that was the problem, they just called it "Amazon Elasticsearch Service" and it resulted in a lawsuit.
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.
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/.
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.
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.
The problem in that case is that ElasticSearch named their company after their product that they published for everyone to use or sell.
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.
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.
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.
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.
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...
They did https://www.elastic.co/blog/elastic-and-amazon-reach-agreeme...
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.
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
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.
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.
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.