7 ms·

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

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.

sofixa 2y ago
Same applies to BSL and similar. Not being able to compete with the project owners is much less restrictive, for me, than AGPL/GPL.
- outop 2y ago
  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.
  - sofixa 2y ago
    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!
    - deleted 2y ago
      [deleted]
    - outop 2y ago
      The company that 'owns' Redis or Elastic also do not need to develop the software they are selling. They already have it, since its creation for free on a non-commercial basis. Without competition, they are free to charge any rent they like for it. If you think that the person that originally wrote Redis or Elastic should have an exclusive license to charge people to use that software, that's a totally valid opinion and a totally valid licensing/business model. However, it has nothing to do with open source software.
- hamilyon2 2y ago
  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. 1. https://github.com/jshint/jshint/issues/1234 https://github.com/jshint/jshint/issues/1234
  - ninjin 2y ago
    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.
ezekg 2y ago
> 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 https://fcl.dev [1]: https://opensource.org/dosp https://opensource.org/dosp
- ensignavenger 2y ago
  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.
lolinder 2y ago
> 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. [0] https://www.gnu.org/licenses/agpl-3.0.en.html https://www.gnu.org/licenses/agpl-3.0.en.html
- ratorx 2y ago
  > 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.
SpicyLemonZest 2y ago
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.
re 2y ago
> 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 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#AGPLv3InteractingRemotely https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...
SahAssar 2y ago
> 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.
- chadash 2y ago
  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).
  - lolinder 2y ago
    They're probably mixing up the SSPL with Hashicorp's version of the BSL, which does talk about competition [0]. [0] https://www.hashicorp.com/bsl https://www.hashicorp.com/bsl
jchw 2y ago
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.
- prmoustache 2y ago
  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.
- sanderjd 2y ago
  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.
bad_user 2y ago
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.
- jotaen 2y ago
  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. https://www.elastic.co/licensing/elastic-license https://www.elastic.co/licensing/elastic-license
  - deleted 2y ago
    [deleted]
  - bonzini 2y ago
    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.
    - nijave 2y ago
      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?
crewdragon 2y ago
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.
- maccard 2y ago
  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.
- giamma 2y ago
  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.
  - nova22033 2y ago
jraph 2y ago
Your users might want to benefit the same rights that you are listing. Hence the GPL family of licenses.
sneak 2y ago
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.
- consteval 2y ago
  > 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.
sanderjd 2y ago
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.
eadmund 2y ago
> 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 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.
- 9dev 2y ago
  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.
- skrtskrt 2y ago
  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
  - riedel 2y ago
    But FOSS and OSS are brands/labels of FSF and OSI and sometimes it is good to have such labels. This like arguing that same SmartTV is not smart or that there is other ways making a TV smart. I think it is good to have some innovation in licencing (like ethical licences which are by definition probably not free), but not by redefining stuff.

sofixa 2y ago

Same applies to BSL and similar. Not being able to compete with the project owners is much less restrictive, for me, than AGPL/GPL.

outop 2y ago
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.
- sofixa 2y ago
  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!
  - deleted 2y ago
    [deleted]
  - outop 2y ago
    The company that 'owns' Redis or Elastic also do not need to develop the software they are selling. They already have it, since its creation for free on a non-commercial basis. Without competition, they are free to charge any rent they like for it. If you think that the person that originally wrote Redis or Elastic should have an exclusive license to charge people to use that software, that's a totally valid opinion and a totally valid licensing/business model. However, it has nothing to do with open source software.
hamilyon2 2y ago
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. 1. https://github.com/jshint/jshint/issues/1234 https://github.com/jshint/jshint/issues/1234
- ninjin 2y ago
  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.

ezekg 2y ago

> 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 https://fcl.dev [1]: https://opensource.org/dosp https://opensource.org/dosp

ensignavenger 2y ago
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.

lolinder 2y ago

> 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. [0] https://www.gnu.org/licenses/agpl-3.0.en.html https://www.gnu.org/licenses/agpl-3.0.en.html

ratorx 2y ago
> 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.

SpicyLemonZest 2y ago

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.

re 2y ago

> 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 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#AGPLv3InteractingRemotely https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...

SahAssar 2y ago

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

chadash 2y ago
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).
- lolinder 2y ago
  They're probably mixing up the SSPL with Hashicorp's version of the BSL, which does talk about competition [0]. [0] https://www.hashicorp.com/bsl https://www.hashicorp.com/bsl

jchw 2y ago

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.

prmoustache 2y ago
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.
sanderjd 2y ago
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.

bad_user 2y ago

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.

jotaen 2y ago
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. https://www.elastic.co/licensing/elastic-license https://www.elastic.co/licensing/elastic-license
- deleted 2y ago
  [deleted]
- bonzini 2y ago
  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.
  - nijave 2y ago
    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?

crewdragon 2y ago

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.

maccard 2y ago
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.
giamma 2y ago
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.
- nova22033 2y ago

jraph 2y ago

Your users might want to benefit the same rights that you are listing. Hence the GPL family of licenses.

sneak 2y ago

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.

consteval 2y ago
> 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.

sanderjd 2y ago

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.

eadmund 2y ago

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

9dev 2y ago
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.
skrtskrt 2y ago
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
- riedel 2y ago
  But FOSS and OSS are brands/labels of FSF and OSI and sometimes it is good to have such labels. This like arguing that same SmartTV is not smart or that there is other ways making a TV smart. I think it is good to have some innovation in licencing (like ethical licences which are by definition probably not free), but not by redefining stuff.