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-...
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)
Why? Does Amazon rev share with Red Hat? Does Google rev share with Linux? Or is it the other way around, should perhaps Linux instead pay Android for putting their product in front of billions of eyeballs? I'm sure there's a way of monetizing a billion users even for a kernel.
The answer is no, because Linux is open source. It is a multi stakeholder model where no single actor is allowed to control other actors use of the product. There is ownership, but it is separated from control. This is implemented with the GPL, but the license is only a tool to achieve the outcome, a multi stakeholder product.
This is why Amazon, Red Hat and Google all can justify to employ hundreds of engineers all contributing to a common product. Amazon can work on security functionality with no risk that Red Hat will veto it because it threatens its revenue stream. And while none of the top kernel developers have made billions from their important work, they still earn well, and all the mentioned companies have grown to become billion dollar companies.
Everyone knew this in the 90s, that's why we have the philosophy around open source. Now the discourse has changed. It is suddenly immoral to earn money from someone else's product, because if you start a project then you own it outright. Not only that, but you also have a right to become rich from your work. Discussions how immoral it is for a large company to use a piece of software without paying the original author is a completely normal thing to do, never mind that they would have no problem reinventing that particular wheel in a heartbeat.
Companies like Elastic have latched on to this, and call their product open source, but call foul when other people build products and make a living from their software. They're not actually interested in a multi stakeholder model at all.
How big would Wordpress have been without every cloud actor out there offering to host instances for a cheap fee?
There were several proposals made to Elastic at the time, but their attitude was that they controlled the project and didn’t want AWS to make big contributions to the open source distribution that would reduce their differentiation. They were also mixing licenses in the code base and deliberately making it hard for AWS to use.
I was also assisting in the deal with Grafana, which I thought was a good deal on both sides, setting up a framework for AWS and Grafana to work together over a longer timeframe. Ash Manzani who negotiated the deal for AWS later joined Grafana to run Corp Dev for them.
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.
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"
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?
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.
AWS at the time had AGPL on its list of licenses that couldn’t be used. There were other clouds in China especially ignoring the AGPL provisions and I think SSPL was used to try and be more explicit.
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 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.
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.
> 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).
> 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.
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.
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.
> 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.
> 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".
> 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.
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?
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
> 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...
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'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.
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.
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.
> 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.
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.
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.
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.
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.
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 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.
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.
> 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.
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.
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.
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.)
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)
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.
> 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.
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.
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.
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.
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.
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.
Readit News
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).
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)
The answer is no, because Linux is open source. It is a multi stakeholder model where no single actor is allowed to control other actors use of the product. There is ownership, but it is separated from control. This is implemented with the GPL, but the license is only a tool to achieve the outcome, a multi stakeholder product.
This is why Amazon, Red Hat and Google all can justify to employ hundreds of engineers all contributing to a common product. Amazon can work on security functionality with no risk that Red Hat will veto it because it threatens its revenue stream. And while none of the top kernel developers have made billions from their important work, they still earn well, and all the mentioned companies have grown to become billion dollar companies.
Everyone knew this in the 90s, that's why we have the philosophy around open source. Now the discourse has changed. It is suddenly immoral to earn money from someone else's product, because if you start a project then you own it outright. Not only that, but you also have a right to become rich from your work. Discussions how immoral it is for a large company to use a piece of software without paying the original author is a completely normal thing to do, never mind that they would have no problem reinventing that particular wheel in a heartbeat.
Companies like Elastic have latched on to this, and call their product open source, but call foul when other people build products and make a living from their software. They're not actually interested in a multi stakeholder model at all.
How big would Wordpress have been without every cloud actor out there offering to host instances for a cheap fee?
I was also assisting in the deal with Grafana, which I thought was a good deal on both sides, setting up a framework for AWS and Grafana to work together over a longer timeframe. Ash Manzani who negotiated the deal for AWS later joined Grafana to run Corp Dev for them.
But how much value does "a good look" have to AWS?
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"
Dead Comment
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?
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.
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.
It's not a "can't" it's a "won't".
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.
"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.
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).
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.
it's perfectly valid to have a completely different view of what freedom is for software
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.
[0] https://www.gnu.org/licenses/agpl-3.0.en.html
> 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".
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.
If that's not how to interpret the license then wouldn't a simple API gateway or proxy circumvent it?
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 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.
> 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.
https://www.elastic.co/licensing/elastic-license
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.
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.
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
[1]: https://opensource.org/dosp
At least with DOSP, eventually the community will be able to do those things.
Imagine what the web would be like if React users weren't allowed to compete with Meta.
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.
- 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.
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.
Dead Comment
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...
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'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.
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.
1. https://github.com/jshint/jshint/issues/1234
I don't entirely understand this bit.
> we changed the license, knowing it would result in a fork of Elasticsearch with a different name and a different trajectory. It’s a long story.
I think the name of the fork is now OpenSearch.
[0]: https://opensource.org/dosp
[1]: https://www.elastic.co/blog/why-license-change-aws
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 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.
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.
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.
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)
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.
> 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.
[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...
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.
Deleted Comment
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
Clickhouse has proven to also be a very capable database for logs and there are stacks that use it for log storage.
VictoriaLogs is very promising in this regard!
Deleted Comment