This is an alarmist headline. The SSPL license to which they are switching only requires your code to be open sourced if you are providing Elasticsearch itself as a service. This change is directed at cloud providers who take open source software and then provide them as a service for payment without contributing to the project. If you are using Elasticsearch on your backend to build search-enabled products or websites, then this does not apply to you.
Re "alarmist headline": the comment was originally posted in reply to https://news.ycombinator.com/item?id=25781695, but it's a good subthread so I moved it over when merging the threads.
TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes:
> Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL.
> It’s not a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal. There are those who will point to the FAQ for the SSPL and claim that the license isn’t interpreted in that way because the FAQ says so. Unfortunately, when you agree to a license you are agreeing to the text of that license document and not to a FAQ. If the text of that license document is ambiguous, then so are your rights and responsibilities under that license... This ambiguity puts your organisation at risk.
How true is this, in practice? I hear software folks say this sort of thing somewhat frequently, but I haven't heard it from a _legal_ person. And my general sense and understanding is that although an FAQ style clarification is not _perfect_, it _does_ carry non-trivial weight.
Judges are not totally capricious people making arbitrary decisions: the notion that in a dispute they would just cast aside one party's _clear and well documented intent_ to narrow the scope of the burden they place on another is... well, it doesn't seem all that credible to me.
Of course by the time you get to that point in a legal dispute you're already in some trouble.
But IDK, I'm just a software person speculating. Is there a legal person interested in giving their "not legal advice" perspective on this?
I'd rather stick to the license text (than rely on mental gymnastics to justify any interpretation based on a FAQ) to be upheld in the Court of Law.
Btw, note how MPLv2 FAQ page clearly points out that the FAQ doesn't give anyone a license to freely interpret the license itself:
> ...while this FAQ is intended to be accurate and helpful, it is not the license, and may not cover important issues that affect you and your specific situation. As a result, reading the FAQ should not serve as a substitute for reading the license itself, or for seeking legal advice from a lawyer.
Remember when Google argued that Oracle shouldn’t be allowed to sue over using the Java API because SUN had said it was fine? That’s the same legal argument as the FAQ issue. It’s called equitable estoppel.
> Judges are not totally capricious people making arbitrary decisions: the notion that in a dispute they would just cast aside one party's _clear and well documented intent_ to narrow the scope of the burden they place on another is... well, it doesn't seem all that credible to me.
My (non-lawyer) experience tells me the same, judges don't like people who try to argue one thing to a judge while clearly documenting on their website the opposite isn't going to go well, but as others pointed out that doesn't make it a smart choice to depend on, or that corporate lawyers will agree is worth the risk.
It raises question of how binding is publishing an FAQ? If I sent them an email with that question and they sent me an answer, if they tried to sue me over the issue that email will be a significant piece of evidence in my favor (I imagine).
But what if they only sent me a link to the FAQ or I just silently relied on it to be accurate?
In my experience, corporate lawyers don't really understand the distinction and will opt for the route of least risk, which generally entails a commercial relationship with the company. Unfortunately, neither Mongo nor Elastic really offer useful commercial relationships. That is, pay them a sum and be free to use the widely adopted open-source version of their thing.
The overhead to those relationships for what they do offer is significant.
Again, very minor use case. Not worth expending effort on. I attempted to convince the lawyers that we should just yolo it because the product had no actual revenue.
I can get at least a couple of person-weeks worth of dev done for the cost of sending the email that results in attempting to convince the lawyers of _anything_.
I wouldn't even ask for a legal review of this new Elastic License, if I thought I could tear it out for less than 2 dev-months of effort.
Amazon's Open Distro for ElasticSearch is still an open source fork of Elastic Search, so ironically Amazon may be the saviors of Open Source Elastic Search.
Mongo absolutely offers this. A company I worked for had a contract with them -- these terms are hugely expensive, to the point it was worth switching to the AWS version when we had no AWS services.
> How true is this, in practice? I hear software folks say this sort of thing somewhat frequently, but I haven't heard it from a _legal_ person.
As a business person, I'd prefer to avoid the legal expense and risk to find out the hard way later on. Who knows who'll manage ElasticCo 5 years down the line and whether their motivation may be to milk their IP through litigation. Do you really want to be the guinea pig? The smart business move would be to either license explicitly OR stick to the Apache 2.0 version and plan a migration off ElasticSearch
Ambiguities result in increased litigation expense. Each argument over what a term means or how it should be interpreted is very expensive. These kinds of disagreements often need to be resolved early in the case by expensive motion practice.
It is much cheaper if both sides are willing to stipulate that they are in agreement with what the terms mean. Then you can get to fact finding and settlement talks with less upfront cost.
> Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version.
and IMO (IANAL) that would put some of the services that offer log ingestion / indexing / querying in legal gray area.
There's quite a cottage industry of SIEMS that wrap ELK, so I'm curious how this'll shake out...
I do empathize with the desire to safely open their code for all/most users and their attempt to use SSPL to do it. For Graphistry, we ended up going proprietary for our core GPU visual analytics and went open for more generic infra and client codes, e.g., launched one of the Apache Arrow languages and our popular Python/Jupyter lib. I'm still looking forward to the day we can open our core as well (all our $B/$T partners ask us to, and yet ;-)). Encouragingly, our users are increasingly preferring the marketplace + saas versions, so I remain optimistic about an SSPL-ish license. That 90%+ of ES users go with SSPL is promising!
> Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
From what I understand the big question is, where is the line on if value is derived primarily from "the Program", and what exactly constitutes modifying the program.
I reserve special hate for Commons Clause [0] too but SSPL is downright offensive.
A reminder that F/OSS works very well for a lot of reasons [1]. The number one of which is if you want to commodize your product's complement [2][3]. Don't be a knob and F/OSS your core product if you plan to make billions or whatever.
1. Avarice: They rode the FOSS wave and gained industry mindshare for a conveniently long time. Now, after making (well deserved) millions on the back of it, they turn to an absurd license to basically say, fuck you, looser, I need my billions.
2. Hypocrisy: Spinning the whole thing as "doubling down on Open" with a source-available license. One must be so delusional to call out "naysayers" as spreading FUD about SSPL when the fact remains that SSPL is a landmine.
3. Short-termism: It is all fun and games till Elasticsearch is wealthy and healthy. Once some PE firm takes over when they get pushed into a corner, I can see them doing Oracle-esque law suites even if it isn't their current intention.
If their core product was Elasticsearch, they could have SSPLd it from the start. I'd be curious to see where they'd have ended up then. I'd absolutely not have been upset in this scenario.
The current scenario is what we are in, lets see how it pans out.
Yes. That's the intent, that if you have some code (such as your devops pipeline) which is used to provide some service to an end user, the end user is able to use/modify/redistribute that code to provide the same service without you being able to obstruct what they do.
No. None of the things you describe involve both providing service to third-parties and modifying SSPL-licensed ElasticSearch code. You are operating the code purely for your own benefit, and you are not patching SSPL-licensed code, and therefore nothing from this discussion is applicable to your described use case. (I'm not your lawyer, etc.)
I would like to point out to anyone else perusing these comments the issue a lot of people are raising in the comments can be summed up in the two responses to the parent:
The ambiguity is the problem. Yes, the FAQ/A Developer/A Company has said they really mean (A), but the license text, which is the legally binding part, is ambiguous. Even if a judge supports the freest reading of the license, you have to go through the time and resources to get in front of a judge.
For FOSS, this means the majority of projects that run on a scattering of donations + developer free time are dead in the water the first time someone tries to hit them with a Cease and Desist or similar.
The current open-source Apache 2 license is being replaced by two proprietary, source-available licenses. Of course this only applies to future releases.
The author says in the end that the problem is not Amazon. Then links to a post where he suggests that companies maintaining the open source should have "invested the resources to build stronger communities around them. They would have reached out to Amazon, encouraged them to contribute back to the projects, and helped them to do so."
Of course, they should "encourage" Amazon not to steal their product and business model. Right.
I highly doubt elastic intended to offer it for free to the cloud providers from the start. They wanted to offer it for free to end users. This is why I expect new products will now start with these more restrictive licenses.
Everyone wants to open source their code until someone else makes a billion dollars of it. Everyone wants censorship resistant end to end encryption until terrorists use it. Everyone wants software patents to not exist until they get issued a really good one.
This is a classic case of trying to put the genie back in the bottle.
Edit: I want e2e encryption but not censorship resistant, not when it starts getting used for inciting to violence. Search for eg "WhatsApp lynch mobs" or "Facebook Myanmar genocide".
Here's a way to build true e2e encryption apps that can be, to some extent, censored:
NLP locally in the phone -- an AI that slightly understand what the user writes -- and if it's (I'm oversimplifying) like "kill all ...", then the AI bricks the phone.
I highly doubt anybody chooses an explicitly free and open source license without intending to offer their software to users under the terms of that license.
And to flip it around, the question isn't whether Elastic envisioned use case X. The whole meaning behind FOSS is that you're explicitly saying "I don't care what your use case is, you're free to use it".
So to later turn around and say "hey we never envisioned Amazon et all turning around and selling Elasticsearch as a service" is looking at it backwards. When you release something under Apache 2 (or a similar non-restrictive license) you're intentionally telling people to do what they want with it.
Anyway, my thoughts on these kinds of situations is that it usually implies there's some disconnect between how Elastic Co wants to make money versus how they actually are making money.
---
There's a related issue of open source maintainers/devs feeling "exploited". Now while having users submitting issues with unfortunate tone/wording that implies that you're obligated as the maintainer to spend your time fixing their issues is frustrating, it's also part of the game. I'm getting really frustrated with the whole "it's not fair that company X is using my free software without contributing back". That's literally what you agreed to have happen when you released under a non-restrictive license!
If you want a restrictive license, that's fine, but don't release under Apache 2 or BSD and then turn around and act shocked when people use your free software for free. It is unreasonable to put something out there for free and then suddenly expect money for it. That doesn't mean that companies shouldn't be contributing back to software they rely on - that's a no-brainer as far as I'm concerned - but it does mean that nobody should be surprised when someone does choose to "consume" software without contributing back.
I wouldn't be so sure about that. Thinking "is this software going to be resold by Amazon" is not high up on the priority list for someone who is just working on a hobby project/releasing that project under a permissive license. Sure, this is a non problem for 99.99+% of the population and it's a relatively new "problem", but it's fair to retroactively change the license because it's within their rights.
Important to note though that they are not retroactively changing anything. The license for old code was and remains Apache and can be used under those terms.
Elastic are of course entirely entitled to change the license to whatever they feel like, including closing the source entirely for future development. But they made the choice at an earlier stage to release the code under a permissive licence - that was a choice to allow others to do what they want with the software, not just “what you want so long as it doesn’t infringe on our business model”. They are free to change their mind on that, but it’s not like it’s an unexpected, unfair, or unpredictable outcome.
It's only a "problem" for the 0.001-% who choose to view it that way. There's decades worth of large/serious/complex open source projects that have totally been monetised by other companies without the founders/maintainers feeling ripped off and butthurt about it.
Linux, GNU, Apache, Perl, Python, PHP, Rails, WordPress, and many many more projects at least as important and complex as Elasticsearch. We don't hear Linus or Stallman, or Larry or Guido or Rasmus or DHH or Mullenweg complaining about hosting companies profiting off their work.
I get that newer projects are structured differently, and that companies like Redis Labs and Mongo and Elastic are paying salaries to engineers to develop their software - which is _way_ different to the examples I cited above. But just because they've chosen that, doesn't mean they're "right" or entitled to succeed working that way. The optimist in me hopes some of them will, and perhaps this will be a route to the world getting "open source" software written that the old Apache project's model perhaps could never have achieved. I certainly don't think that's a given though.
The pessimist in me feels bait-n-switched, and is wondering how to plan on staying on 7.10 safely and keeping an eye out to see who's gonna fork it and at least keep up security work on it under Apache 2.0 moving forward. We don't "sell Elasticsearch as a service", but we use it enough that I don't want to ask for legal budget to mitigate the risk of upgrading away from the Apache 2.0 licensed version. I don't trust SSPL enough to want use anything licensed that way, and I doubt I'll be very happy with Elastic License either if I spend enough time to read/understand it properly...
> staying on 7.10 safely and keeping an eye out to see who's gonna fork it and at least keep up security work on it under Apache 2.0 moving forward
I wonder how many companies would be willing to pay $100 a month for their elastic search to continue to receive security updates... in theory the right individual could make a decent living simply forking the various OSS projects that have since gone noSS, applying security fixes, and collecting money from the companies build on them.
Almost all the examples you give are GPL. That is the only license that protects the freedom of your software. Any 'permissive' license can be converted to 'private'. Too bad nobody really understood that for the past 20 years.
They are welcome to do that if they feel that way. But it's not theft for people to use software under the terms of the license you offer it to them under, and it's a fucking stupid accusation to make.
Trying to determine what offering as a service is or implies is a bit difficult. If Discord used it to enable full text search, does they need to release their management layers too? Why or why not? How excited to defend your rationalization/decision to the court are you, if some disagreement arises?
The ask, that companies open source their management layer, concerns me because it's unclear in many circumstances what does & doesn't need to go into that box. A management layer is often a rather sprawling piece of software. Trying to disentangle & release the Elastic Search or Kibana management layer from the other management /deployment/control systems could be quite onerous.
I do think the intent is not "bad", but it's so hard & murky, there's so much peering into the crystal ball to guess whether, some day in the future, a once "open source" company that may, a decade down the road become aggressive/ligitious (not presently the case!) continues to find your particular use does or not does qualify as offering the product as a service, and does or does not expose you to a long complex obligation.
AFAIRemember, RedHat dropped MongoDB because of "controversial SSPL"
> So essentially, anyone is free to modify MongoDB. It’s only when you offer MongoDB as a commercial service that the conditions of the SSPL state that you must open source the entire service.
AWS wouldn't, I presume, touch the 7.11 dual-licensed Elasticsearch release with a ten-foot pole. They would have to hard-fork it here on, or Gold+ partner with Elastic.co to sell Elasticsearch Service under the relatively more permissive Elastic License.
there is this twitter user that claims that non-elastic employees can't contribute[1]. I wish somebody could summarise this romance between AWS vs Elastic for simpler people because I can't catch up :(
Also not a lawyer, but I find the language in the license pretty interesting and ambiguous choice of words.
> [...] where obtaining access to the Elastic Software or the features and functions of the Elastic Software is a primary reason or substantial motivation for users of the SaaS Offering to access and/or use the SaaS Offering
It seems like you can still offer Kibana to end customers, but I wonder where the cutoff line for "substantial motivation" ends.
Yea I read that as if E/K is used to power your backend analytics for your dev team we're OK but using for client facing reports, a key feature of your application, is blocked.
Even worse, Elasticsearch is a great product for adding "search" to your webapp. I don't see how integrating it doesn't run afoul of:
Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network...
I'm not sure if people are really confused about this or sowing FUD. Using Elasticsearch to search your own webapp is not providing Elasticsearch as a service. It's using Elasticsearch to provide functionality in your application.
Providing Elasticsearch as a service means allowing people to upload their own data and giving them an Elasticsearch instance to search it.
There's some grey area where it's a question if you're providing an application with a search feature or just hosting Elasticsearch. Like if you provide a way to upload logs and then search them that's Elasticsearch as a service. But if you provide an automated upload, is that enough?
> ...if you provide a way to upload logs and then search them that's Elasticsearch as a service
Yes, and if you let your internal company blogging platform ping a service upon every new post, which then feeds that post into Elastic so blog posts across your company are searchable?
I suspect one way to avoid this would be “buy a commercial license” (or use Amazon’s fork if you’re so minded), but if you’re using Elastic’s open source offerings — I’d be careful about licensing anything under SSPL, whatever your intentions are.
It can be, they just chose not to (with ulterior motives or not, I cannot say.)
For my side project, I am using a dual-licensed MIT/Apache (your choice) but with an exclusion which prohibits companies like AWS from offering it alone as a service. Here's a copy of the (quite human-readable) license:
I think a more charitable interpretation of Elastic's motives in the re-licensing would be to view them the same as your motives for your side project -- allow free use to anyone except those wanting to offer it as a hosted service. You say that you've licensed your side project with MIT and Apache2 but with an exclusion. In other words, it's neither MIT nor Apache2 and it's unclear how your exclusion would hold up legally (hopefully well!). At Elastic's scale, uncertainty over a license is too risky, so I'm sure they paid their lawyers $$$ to ensure that the SSPL would hold up in the scenarios that were important to them.
But I think it's unfortunate that companies end up with licenses like SSPL which are lengthy, not legible to non-lawyers (see this thread) and more importantly ambiguous in favor of the SSPL-software-provider. It's only natural, that's what lawyers are hired to do, after all! But I think there are other options (be ambiguous in favor of the opposing party, or build upon existing licenses)
If you aren't modifying the ElasticSearch source code, then you don't need to care about any of this conversation at all.
If you add search to your webapp using ElasticSearch, you typically would not be modifying it, and so any source distribution burden that could possibly be compelled from you in a worst-case scenario would be for the unmodified source code that you freely downloaded from a public website. No local modifications? No violation of terms. End of line.
While that's a slight risk of having more burden than not having to provide that source code, it's not like it contains anything proprietary, because you probably aren't modifying it anyways — and once you divulge that source, it's proof that you not only did not violate terms, but could even request legal fees.
So whether or not this search usage would qualify, which can only be definitively decided in a court of law, your actual risk of harm and exposure is none whatsoever — unless you have proprietary patches to ElasticSearch and you aren't already sharing them openly in a GitHub fork. (I'm not your lawyer, etc.)
> using for client facing reports, a key feature of your application, is blocked.
That seems a very pessimistic / overly conservative interpretation to me. They are clearly shooting for people selling Elastic itself as a hosted service here. Your client facing report being "Elastic Software or the features and functions of the Elastic Software" is unlikely to fall into "reasonable interpretation" space IMHO.
The problem is, SSPL is heavily based of GPL, using the same concepts, and inheriting similar problems.
GPL does not clearly define where the boundaries of a program is, but there is a fair bit of basis in the GPL FAQ and other writings from the FSF that suggesting that in their opinion, if I write a program B, that specifically depends on program A, then program A and B is part of the same program, regardless of whether or not it is linking in terms of C or if it is using it over the network.
> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
I think it’s more complex than that. If your program B is, as an example, a formatting-in-HTML wrapper around program A (say gnu grep), then you can ship B in binary-only, non-GPL form that calls A, so long as the end user can replace A with a later version or their own patched version of A and B continue to work. (This preserves the freedom of the user with respect to A.)
In that case, B specifically depends on A (for filtering functionality), yet is still (likely, IANAL) considered a mere aggregate as I read things.
Hmm, the Apache httpd folks didn't complain when web hosting services around the world started making money offering web hosting using it, without modifying it nor contributing back financially.
Isn't it equally true that if they moved to being entirely proprietary but free-of-charge software, or if they had a "all rights reserved but you can look at the source if you want" license, or whatever, there would be no impact on most customers either?
If so, why bother leaning into the word "open"? Just call it freeware.
I wonder if non-ElasticCo contributors to Elastic Search who disagree with the SSPL license change can sue to have their contributions removed. Could even be a class action lawsuit if quite a few contributors disagree.
All their contributions up until this point are still under the Apache license, so they'd have no reason to sue, I think. And anyone is of course free to fork that code and call it something else.
Now, it's very likely that many of them will stop contributing for versions 7.11 and up.
Edit: Not a lawyer!