Edit: Not a lawyer!
> 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.
See also: http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...
Or my monitoring? Deployment and management in kubernetes for example?
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.
[0] https://news.ycombinator.com/item?id=17814386
[1] http://dtrace.org/blogs/bmc/2004/12/16/the-economics-of-soft...
[2] https://www.gwern.net/Complement
[3] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
Also HN: Don't be a knob and F/OSS your core product if you plan to make billions or whatever.
They're doing exactly you want: picking a non-free license for their core product, and you're still mad at them.
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.
It doesn't impact your devops pipeline or your monitoring workload(s).
Link to FAQ: https://www.elastic.co/pricing/faq/licensing
https://news.ycombinator.com/item?id=25782849
https://news.ycombinator.com/item?id=25784581
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.
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?
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.
The overhead to those relationships for what they do offer is significant.
Nah.
Choosing something else - at least if you can do it before getting locked in.
Didn't go well.
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.
SOLR?
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.
But what if they only sent me a link to the FAQ or I just silently relied on it to be accurate?
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.
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
Google did zero offers back it was still unclear who would save Sun, most likely hoping that they would just sink away.
Eventually Oracle and IBM came into the picture, and still radio silence from Mountain View.
So yeah, they get what they deserve.
As for links, the press of the day.
> If you make the functionality of the Program or a modified version available to third parties as a service... (license conditions apply)
> “The Program” refers to any copyrightable work licensed under this License.
IANAL, but that seems pretty cut and dry referring to making an Elasticsearch or Kibana service
> 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.
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.
Of course, they should "encourage" Amazon not to steal their product and business model. Right.
It is not possible to steal something from someone who deliberately and freely offers that thing to you.
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.
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.
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...
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.
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".
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.
Otherwise it's e2e as usual.
(But I guess I'd taken Elastic's approach and switched to SSPL)
About 2: i replied here: https://news.ycombinator.com/item?id=25798359
I am quite sure they are open to a reciprocal licensing agreement with AWS et al.
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.
> 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.
https://hub.packtpub.com/mongodb-withdraws-controversial-ser...
Is this a difference like GPLv2 and GPLv3? Does this means that AWS now must open internal service (probably not but I'm trying to be devil advocate)
Not an expert but usually F/OSS licenses are mainly about:
- Patent grants (either grants patent-use or doesn't)
- Copyleft (should modifications be open sourced. ex: AGPL is the strongest FOSS copyleft, whilst SSPL builds on it to make it even more stronger)
- Copyright (owners who are licensing the code)
- Warranty and Liability
- Terms of use (ex: FOSS licenses don't enforce restrictions on commercial use like CommonsClause does)
Correct me if I'm wrong, AWS ES service still uses ES free licence but they've re-written the plugins so they won't use ES and pay ES fee?
With new licence, AWS won't be able to use ES as SaaS?
Non-elastic pull requests are merged, as I mentioned in [1].
> [...] 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.
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...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?
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:
https://gist.github.com/slimsag/2164520b9e249fbae4e08e2bdf6e...
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)
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.
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.)
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.
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.
https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation : What is the difference between an “aggregate” and other kinds of “modified versions”? (#MereAggregation)
> 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.
In that case, B specifically depends on A (for filtering functionality), yet is still (likely, IANAL) considered a mere aggregate as I read things.
- no impact on the overwhelming majority of our user community
- no impact on our cloud customers or self-managed software customers
Also, this helped calm my nerves: https://www.elastic.co/pricing/faq/licensing
If so, why bother leaning into the word "open"? Just call it freeware.
Now, it's very likely that many of them will stop contributing for versions 7.11 and up.
Ah right - makes sense.