> 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).
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.
"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.