I can understand the motivation - AWS' approach, particularly to elastic, has been pretty awful, and migrating away from Apache/GPL/MIT is like a coming of age for the big databases (Mongo, Cockroach, Elastic...) - but calling the article 'Doubling Down on Open' stretches credibility.
Be honest, treat us like adults and cut all the 'we're doing this to remain open' crap. You are a public company who wants to increase the cost of development to your competitors so you can increase your market share. That's it .
Maybe that is too cynical, but I recently went through a license shift (GPL to Apache) with TerminusDB and we were clear that honesty about motivation was the best formula for comms.
Their argument is, more charitably: "We built this, we released it for free. Our business model is professional support and hosted services. In order for us, the creators of this software, to continue building it, we cannot allow megacorporations to freely spin up a loss-leading competitive service and cut us out."
(1) It's interesting how much of the reasoning/argumentation for these restrictive licenses ultimately comes down to a more articulate form of "but that's not fair!". I also wonder how much the implicit beliefs that "unrestrained capitalism is a bad thing", "markets naturally lead towards monopolies", "antitrust law is legitimately necessary", etc are impacting peoples' reasoning here.
(2) If they can't actually compete and provide superior value to whatever managed offering Amazon can scrounge together, that's actually their fault. AWS' managed elasticsearch offering is absolutely terrible, speaking from experience. They block access to important APIs like `reroute`, any minor cluster change results in a whole blue-green deployment which very frequently hits a race condition that prevents the newer cluster from ever coming up healthy, requiring a ticket to be filed that takes multiple days to respond to if you don't have premium support, etc.
So functionally the idea that AWS is going to fleece them because they'll offer a just-as-good service for cheaper has not been the case. Elastic co's managed offering is simply far superior.
---
Ultimately, Elastic has shown that they don't actually want to release FOSS. They want to release proprietary software, and that's why the (in hindsight very easy to foresee) usecase of a cloud provider offering a managed service angers them so much. They don't really breathe the FOSS mindset, because a true non-restrictive license (BSD, Apache 2.0 etc) means that a company can absolutely use your software to make money and that's okay.
Anyway, Elasticsearch is incredible software and the Elastic team has made something truly incredible. I just wish they had a vision for monetization that aligned with their open-source beginnings. It's clear that they don't, and the sooner they stop pretending they're offering a free or open-source solution here, the better.
The problem is that nobody buys AWS ElasticSearch because of quality. They buy it because they already have AWS approved as a vendor and a blank check to spend on it.
Yeah, so they’re not really competing with Elastic right? If I already have an AWS environment I’m never going to use an Elastic hosted service, since it’d be outside my VPC.
I really don’t understand how that business model works.
If you have an AWS env, and they have no comparable alternative, you may be forced to look outside AWS, eg: to Elatic's SaaS offering. But in many cases, if AWS has a comparable offering, you simply don't bother looking outside.
It's similar to bundling tactic of Microsoft, and other big vendors. By bundling MS Teams with other things, no one has to "buy" Teams, they already get it for "free" (well, it's no extra cost beyond what they would be paying for Office or whatever already), so why "buy" Slack when you have a similar chat tool for "free".
It’s important to defend the product and the software ecosystem because so many people are confusing AWS’s offering with what the current state of the system is. It’s so bad that some people actually think that AWS _is_ the developer of Elasticsearch in many cases due to the Elastic-X branding similar to the I-Noun convention that Apple tried to defend against but fell short of squashing around the world. It’s also important to note that not defending one’s trademark sufficiently well means bad things in a court precedent where there needs to be reasonable, demonstrable evidence you’re not simply a patent / trademark troll sitting around waiting for someone juicy to sue rather than small fries.
Seems like you know a thing or two about this — are all the reports I see about companies leaking tons and tons of data through improperly configured elastic search instances something using the aws’s offering would fix (or even ES’s hosted offering)? I don’t really know much about the field, but if AWs’s single contribution were to be “we made it really hard to screw up the configuration and leak all your data”, I’d consider that a very deserving cause.
> Seems like you know a thing or two about this — are all the reports I see about companies leaking tons and tons of data through improperly configured elastic search instances something using the aws’s offering would fix (or even ES’s hosted offering)
The primary issue that leads to that is that the stock open source elasticsearch distribution (APL licenced) does come with no security at all. It even used to be the case that even the most basic security was a plugin that required a paid license. That changed only after AWS released the opendistro set of plugins with a free plugin to add security - after that, elastic offered a basic (free as in beer, but still non-free as in freedom) license that would include security. Additionally, the early ES versions would bind to all IPs by default, so just starting the server would make it available from outside. If you weren't expecting that and no firewall was protecting you, your ES cluster would be available from the outside with not authentication.
Both AWS and elastics hosted offering come with a configured security plugin, so that at least makes it harder to leak data. Obviously, even with authentication you can still leak credential or such.
Hm. So Elastic releases a neutered version of their product that leads to countless PII leaks, AWS provides a FOSS plug-in to fix that, then Elastic turns around and says AWS is leaching off their product and not contributing back to the community and implements a licensing change to prevent them from working together in the future? I can’t help but side with the AWS folks on this one —- I get wanting to make money, but insecure-by-default services are inexcusable, especially when it’s expected that they’ll contain PII.
Exactly! I've used AWS' service, it's awful. Elastic's is better, and price is comparable or better in fact. But the point is they don't even have to compete on price if quality is superior!
If I'm spending $100k/mo on my logging stack, and it's falling over frequently (which in AWS-land means multiple days of back and forth, opening tickets etc), I'd way rather pay $120k/mo for something that actually works.
Have you never been burned by those awful blue-green deployments?
Of course, my company was willing to pay $100k/mo to log every SQL query in existence but wasn't willing to pay for AWS support (of course it would have required paying something like 1% of our TOTAL aws spend, not just aws elasticsearch, although we could have probably created a subaccount or something)...so maybe the experience is different if your tickets actually get answered.
What was bad about performance in particular? You were just seeing less throughput per dollar spent or what?
I believe they have an option so you can peer your VPC to their hosted offering's VPC, so logs from within your VPC don't have the typical expensive AWS internet egress/ingress costs.
Special mention for this paragraph: 'we expect that a few of our competitors will attempt to spread all kinds of FUD around this change. Let me be clear to any naysayers. We believe deeply in the principles of free and open products, and of transparency with the community.' Get your offense in early and try not to mention open source!
I feel so much for the hundreds of open source developers who toil everyday only to have AWS make so much money out of it, to make the largest shareholder the richest man on earth, while contributing nothing back to any of the open source projects. This has to be fixed or we will see less and less developers open sourcing quality products
F/OSS exists so that not everyone has to be subject to undifferentiated work, among serving other very high impact purposes. Think brew.sh, vim/Emacs, Eclipse IDE, Postgres, Java, Linux/Linaro etc;
Substitute AWS for "a software developer" and see if you feel the same way.
> I feel so much for the hundreds of open source developers who toil everyday only to have other software developers make so much money out of it... while contributing nothing back to any of the open source projects. This has to be fixed...
As someone who writes open-source, I'm always happy to see other developers use my code to build cool stuff, and I expect nothing in return.
I'm also happy to see small start-ups rise faster by using my software.
But if those theoretical start-ups, whose business wouldn't exist without my software, grew to dozens of employees, made millions of dollars, and still I wouldn't see a nickel.. That's when I would start to wonder, why am I doing this for free?
Incidentally, the bigger the company, the less likely it is to contribute back.
To conclude, that sounds like false equivalency to me. It does matter who is using it for free and profiting.
AWS does / did contribute patches to Elasticsearch.
The problem Elasticsearch has is, AWS shares none of the gigantic profits it makes from its Elasticsearch Service, which is a double whammy because it cannibalizes Elastic's own SaaS offering.
> To conclude, that sounds like false equivalency to me. It does matter who is using it for free and profiting.
You mean to say, Facebook must share a % of its WhatsApp profits with ejabberd, or ejabberd otherwise is right to SSPL their software?
Or, Google pay Oracle a share of the spoils because it is an "app container layer" on top of Java/JVM? And that Oracle is okay to switch to SSPL otherwise in search of those dollars?
Or, okay if CnFdn SSPLs k8s?
Also, if it matters whoever profits contributes back monetarily, may be the right way to do so would be via a Foundation. Using the Commons Clause or SSPL is not the answer, in my eyes.
I don't think it's reasonable to attribute motive to the contributors in this way. Changes like this protect the elastic enterprise, whether they align with the motives of contributors would have to be evaluated on a per-contributor basis.
I've made several contributions to ELK, and my only motive has been that it's useful open source software, and I want to make it more useful. I personally don't care who profits off the codebase, I think anybody should be free to. I personally would object to anybody trying to lock down how it can be used, and would see any attempt to do so as running completely counter to my personal motivations as a past contributor.
> I've made several contributions to ELK, and my only motive has been that it's useful open source software, and I want to make it more useful. I personally don't care who profits off the codebase, I think anybody should be free to. I personally would object to anybody trying to lock down how it can be used, and would see any attempt to do so as running completely counter to my personal motivations as a past contributor.
This x 10000. I couldn't agree more, thanks for putting that so clearly.
Frankly, I think a number of people in the Open Core movement have a psychological hangup around profit. They feel that if a company - particularly a large corporation - is making money using their software without "contributing back", that that should not be allowed. Well, if you don't want to allow it, fine, but don't pretend you're in the business of releasing free software - you're not. You want to be in the business of proprietary software, since only proprietary software lets you say "hey I don't want Jeff to profit off of my work without paying my for a proprietary license".
I very strongly agree. It's always seemed like a quintessential tragedy of the commons to me. Everybody benefits from open source software, no matter what they're doing. Proportionally, very few people/organisations contribute to open source, and I would guess that nobody contributes to every open source project that they consume. I've always seen one of the core aspects of the value of open source being the common utility they provide. The idea that an open source consumer should contribute back value in some way proportional to the value they derive runs counter to that. The moment you start to restrict access to open source software based on some model of deservedness, you start to undermine the principles of common good that a lot of open source values are based on.
Legally, I’m sure their contributor license agreement gives them the full rights to do that. Which was my understanding at the time. I’ve contributed to lots of projects that have them, and I likely will again in the future.
I think this is the right way to look at things, after all, these were the orignal "why" arguments in favour of open source.
If we can get the same benefits while also protecting open products from megacorps like AWS, that's a better licence than a true open source licence
> If we can get the same benefits while also protecting open products from megacorps like AWS, that's a better licence than a true open source licence
That's your opinion, of course. IMO, there's a type of magic that happens when software is under a truly non-restrictive license. You get a level of quality and reliability in the software that is unmatched by what you get with any proprietary equivalent.
Unfortunately, most people don't really believe in FOSS. And that's okay. But boy am I getting frustrated with these companies that are happy to preach about how "open source" is amazing, until someone else is making some profit with their software and then suddenly the (extremely vague) restrictive licenses start rolling out.
Both the Debian Free Software Guidelines[1] and the GNU Free Software Definition proscribe limiting fields of endeavor. The OSD[3] borrows heavily from the DFSG.
I remember reading (alas, I can't find my source) a spokesperson for the OSI admitting to the existence of licenses that meet the OSD that they don't want to be OSI-approved because they don't add enough value versus the cost of proliferation of licenses that are substantially similar.
These definitions were written a long ago, in a time when cloud computing wasn't even a buzzword yet.
But I read them and couldn't find anything addressing fields of endeavor. GNU's "four essential freedoms", which imho are a little naive in retrospect, don't say anything about this. They say anyone should be able to "sell copies", but SSPL doesn't disallow this either.
Debian obviously didn't address it either. They clarify: " They can even try to sell it. In practice, it costs essentially no money to make electronic copies of software. Supply and demand will keep the cost down."
I.e. they only allowed it because they thought the free market will take care of it, and didn't imagine how cloud provides will become monopolies of access.
"As a result, you can buy a Debian release on several CDs for just a few USD." - Lol.. that's like trying to apply lessons from the bible to modern life.
Just to broaden the discussion, "fields of endeavor" doesn't just mean cloud services, but also whether you can prevent your software from being used in weapons, or other such morally objectionable applications.
Imagine if the only way to use Linux or Kafka is to use a specific hosting company. The title should've been "Doubling Down on our Revenue Model by changing our Licensing"
"protection against public cloud providers offering open source products as a service without contributing back".
I have no issue with whatever license they choose, but let's be honest, its not about contributing back to these projects, its inserting a poison pill clause that they know cloud providers can't meet.
Specifically, by contributing back they mean, per the license: "If you make the functionality of the Program or a modified version available to third parties as a service, you must make the *Service Source Code* available via network download to everyone at no charge, under the terms of this License."
Red Hat (my employer currently) is typically in the same boat here and it drives me crazy how people don't think about that before criticizing.
People love to say, "Red Hat couldn't exist without <project>" which is true, but what they don't realize is that a ton (sometimes all) of the development of that upstream project is done by Red Hat employees. Without that a lot of projects may not even exist.
There are no doubt "open source" companies that take more than they give, but it's a little more nuanced and complicated than people make it out to be.
And guess what, when a corporation uses Elasticsearch in a serious way they will inevitably end up contributing back. It's actually easier to just get a change merged upstream rather than to manage a whole fork, unless the upstream is really hard to get patches merged with.
The whole narrative of "company X is offering Elasticsearch as a service and not contributing back!" is ridiculous. First of all, the whole point of free software is that somebody somewhere is going to be making money with that software, and that's okay, regardless of contribution. Second of all, in practice companies like Elastic will always exaggerate the extent to which corporations aren't "contributing back".
What they really mean is Amazon isn't contributing financially to Elastic Co. That's what they're pissed about, and that's why they clearly wish they were actually in the business of proprietary software (which they now are)
>First of all, the whole point of free software is that somebody somewhere is going to be making money with that software, and that's okay, regardless of contribution.
No, the point of free software is that users of the software have the freedom to use the software, redistribute the software, modify the software, and redistribute modified versions of the software. Someone making money using those abilities is incidental to the actual goal.
> It's actually easier to just get a change merged upstream rather than to manage a whole fork, unless the upstream is really hard to get patches merged with.
The thing is "really hard to get patches merged" is a fuzzy barrier. There are many, many example of what most would consider reasonably maintainers where companies just don't contribute back. Even in breach of GPL.
Would Elastic be in a position to "close source" / "re-license" their code if Lucene itself wasn't permissively licensed? Your argument's putting the cart before the horse.
No, offering your code under Apache/MIT is a bell you can't unring. You can stop offering future changes under the license, but everything up to the point where you change the license is available forever.
What do you expect them to do though? If they want to be viable as a business they need to place some restrictions so they can have a monopoly on some aspect in order to derive profit.
If they're not viable as a business, they die and nobody benefits from that.
It's this kind of all or nothing criticism that has made me rethink open source. I'm releasing a product this year, and it's going to start under a proprietary license. Because it seems you're damned if you do and damned if you don't. At least commercial closed source products don't attract this kind of criticism.
It's a vocal minority that slings the hate. There are tons of people that appreciate open source with exceptions to prevent managed offerings by cloud providers as long as self-hosting to support your own stuff is allowed (including ability to customize/extend/patch).
I for one will (with a few exceptions) only pay for a product that is open source (at least enough so that I can self-host for my own product if I want should things change). Vendor lock-in is a serious problem and concern for many, and open source is how you address that concern. The best example is GitLab, which gets a ton of money from me that would otherwise go to GitHub (which I like better) if GH were open source.
By going proprietary you avoid the vocal minority on the internet, but you also (silently) shrink your potential customer pool. Especially with the AWS/Parler stuff, there are even more people that want the option to self-host in case they get de-platformed if the Overton Window continues to shift.
> at least enough so that I can self-host for my own product ... Vendor lock-in is a serious problem
I'm leery of vendor lock-in myself. Self-hosted will be the only way to run my product in the beginning, and the cloud service will follow when it's popular enough to make sense.
> May I ask what your product is? Just curious :-)
I haven't published the website yet (it will be at https://flowstate.dev), but it's a framework/runtime for building backend APIs using SQL and JavaScript. It lets you run SQL queries from the browser, among other things. Which sounds crazy, but it actually works well. Once I have a hosted cloud service it becomes a backend-as-a-service platform kind of like Parse or Firebase.
I'm not against open-sourcing it down the road, but it can't be an OSI license, and I'll wait until it's big enough that I'm less worried about competitors just lifting my source code. I know copyright laws protect against that, but that only matters if you have the resources to litigate.
I do want my users to be able to dig into the source if the documentation is lacking, and also to patch/modify it if they need to - so I need some kind of source-visible license down the road. I think I would also add a clause that if the company goes under or gets acquired and shutdown then all source code gets published under the Apache 2 license.
I expect Elastic to not pretend they are doing this in the spirit of getting contributions back. Just say that this is in the interests of their business model.
This "We need it for survival" is bullshit. With Elastic being public company you can see their revenue growing 60% last year.... with Apache 2.0 license. It is not the case what we've been loosing revenue for years due to AWS competition and this is the last action of the last resort. This is simply about speeding up the growth at expense of your users which is of course sugarcoated as "it is good for you"
I wish comms were more honest about this, they'd earn more trust than just telling the community SSPL is now an OSS license despite what OSI has shot back about it, and that this is some type of necessary evil.
Agreed, if their hosted cloud services and premium features aren't viable as a business, and they don't have any intention to develop this software without a profit, then they shouldn't have positioned themselves as a free-and-open-source product in the first place.
You can run the SSPL'd code, you can view the SSPL code, if you change the SSPL code then contribute back if you distribute your changes. If you run a service providing the SSPL code, contribute the management layer back as well.
It gets more code into the open, where's the disconnect?
I am not concerned with the code of other users' management layers. I am concerned with being able to use the code of this product in the way I want to use it. Copyleft is not important to me, I see permissive licensing as being a bigger priority for freedom.
> they don't have any intention to develop this software without a profit, then they shouldn't have positioned themselves as a free-and-open-source product in the first place.
If something satisfies the four freedoms [0], it is free software.
Well, the linked page indicated that copyleft is something that applies only to distribution and not use, but I guess the AGPL shows that that's not true.
Nonetheless I don't agree with the GNU's claim that copyleft doesn't reduce freedoms. Of course a permissive license provides more freedoms: it's right there in the name
But this issue isn't really about permissive vs copyleft licensing anyway: Had Apache used a copyleft license with Lucene, Elasticsearch would have never existed.
Those aren’t necessarily contradictory titles. Large OSS projects require funding, or they run a serious risk of stagnation. If there are massively profitable corporations using OSS and contributing nothing back, or even actively competing with the project, then a more profitable business model may be the best thing an OSS project can do to ensure its longevity.
I'm glad that the SSPL is becoming more of a standard for this sort of "open source minus AWS" software. One of the benefits of standard open source licenses is that it's easier for companies to give blanket permission, "you can use software that's MIT licensed". Hopefully it becomes easier for companies to just pick whether they say "we allow the use of SSPL'd software" or "we do not allow the use of SSPL'd software" instead of making all the software engineers have discussions with lawyers to get work done.
My guess is that sspl software is going to be on the block list or in speak to a lawyer territory. Most places don't or shouldn't open source willy billy as they have business obligations that have to be met before doing so.
I agree with the overall principle, but SSPL's wording itself is very problematic. They need to do a much better job in disambiguating (1) what is considered hosting vs just using and (2) what are the obligations of a hosting service in order to abide by the license. The license is simply too vague about these points, and the generally agreed upon lines today might not hold up the first time someone goes to court over it.
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.
> Starting with the upcoming Elastic 7.11 release, we will be moving the Apache 2.0-licensed code of Elasticsearch and Kibana to be dual licensed under SSPL and the Elastic License, giving users the choice of which license to apply.
So starting with 7.11 no parts of Elasticsearch will be released under an open source license.
They aren't making everything SSPL, though. Their paid features continue to be only available under the Elastic License.
So apart from adding the cloud non-compete clause (don't offer Elastic as a Service) there are many more restrictions added compared to Apache 2. For example I think linking can only happen with GPL3 code and it is copylefted instead of permissive https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...
I'd say that similarly to Common Law where rights always come paired with counterpart obligations; the "restrictions" added by GPL vs Apache come with counterpart advantages: they keep forks open source (vs proprietary) and favor contributions feeding back to the OS Community. I believe we should consider them altogether: disadvantages and advantages.
Both permissive and copyleft licenses play important roles in the Open Source ecosystem. Different story are proprietary licenses.
> This change does not affect how you build or license plugins to Elasticsearch or Kibana. For the avoidance of doubt, building a plugin to be used in Elasticsearch or Kibana does not constitute a derivative work, and will not have any impact on how you license the source code of your plugin.
I'm wondering how this affects the distribution of x-pack. From what I'm reading, the new Free model probably includes it and we have to turn it off if we don't want it? I wish there was still an x-pack free distribution in this model.
There are still proprietary modules only available under the Elastic License just as before.
However it seems that they will be moving the free modules which were previously only licensed under Elastic License to be licensed under SSPL instead.
You're right -- it's only the free "X-pack Basic" code that will now be available under SSPL. But that does mean that all Elasticsearch distributions will now include the former "X-pack Basic" features.
That seems to be what they are suggesting by making the "free" box in the 3rd column span both the "free" and "free/basic" tiers of the previous columns.
Unless they plan to make those modules paid which were previously free, which I doubt
Yes, I understand that, but what I would like is a distribution without any x-pack code. I don't want to have to figure out how to turn off and remove x-pack. What I'm concerned about is that it's another vector for security vulnerabilities that I don't need.
wow, this is super interesting, but i can't say i'm surprised by this move.
the landscape has really evolved over the last few years for companies trying to build a business around open source.
at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy.
all of our peers (eg. mongodb, elastic, redis, confluent, cockroach, timescale, etc etc) have recently made moves to prevent being disintermediated by the cloud vendors.
> around what is best for our own licensing strategy
As a user (self hosted for internal monitoring): if you must change, please, please make it completely unambiguous what the scope is. I really want to avoid having an argument with my team about whether we're using grafana to "provide our service".
After rereading the relevant section a few times, no, I think SSPL is fine for our use.
EDIT: I should say for our current primary usecase. It does look like this would make it awkward for us to expose grafana to clients, but that's a narrow case and/or one that I suspect you'd intend to be in-scope for virality.
As far as I can tell, Timescale is not like the others, their shift was to make the formerly proprietary enterprise only code source available. Remarkably they went MORE open rather than less (as it the case for all the others).
You have to give them respect for approaching things differently.
I don't think it's really that different. Elastic did that same thing about three years ago when they made all of their enterprise-only features source-available (https://www.elastic.co/blog/doubling-down-on-open). Timescale also made their enterprise features free of charge, but that's a business decision rather than a question of licensing. It's because their revenue model is based completely on their managed cloud offering while Elastic still gets non-trivial revenue from selling their enterprise features to customers who want them.
Is this an elastic employee throwaway? How is going from a more permissive license to less permissive one "not really that different" than the inverse?!
When we initially launched the Timescale License in Dec 2018, we didn't relicense any of our Apache-2 code -- that was and has always remained licensed under the Apache 2 license. Instead, we effectively were "pre-announcing" that some future advanced features (yet to be developed) would instead be released under the Timescale License or under a paid-only commercial license (although still source-available).
Fast forward to September 2020 and Timescale 2.0, and we (i) made some aspects of the Timescale License more permissive (e.g., "right to repair", "right to improve"), and (ii) moved all the previously enterprise (paid-only) features to be available for free under the Timescale License. Hope that helps!
TimescaleDB licensing is mightily confusing. Instead of clarifying here, you might want to provide clear licensing info for all your products on your webpage.
Happy (non-paying) user otherwise, but this is a bit shady in my eyes.
Ive been interested in the licenses that are restrictive with a time period (eg: 6 months-1 year) after which they become FOSS (Apache2/MIT), eg BSL. I think it's a reasonable approach, but I think the restrictive license still needs to be quite permissive for it to make me happy. I haven't quite found one yet that sat well with me.
I thought Grafana was doing great with its managed offerings. Personally I'd prefer you consider BSL before SSPL since it's usually clearer to most people.
Interesting. I got the impression from the recent announcement that Grafana Labs had something of a revenue sharing model with the new AWS managed offering of Grafana. Given that, I wouldn't think the SSPL restrictions would be as important.
we do indeed have a partnership with aws around grafana. but the cloud landscape goes beyond aws, and the grafana labs landscape goes beyond grafana itself.
> The SSPL allows free and unrestricted use and modification, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL.
That doesn't sound like something incompatible with Open Source Initiative standards for "open source". And it sounds like something existing OSI-approved licenses could do?
And yet, SSPL is not OSI-approved, and they did not choose an existing OSI-approved license, instead the SSPL which they say "embodies the principles of open source", but isn't actually an open source license by accepted standards.
So... why? What's going on? What is this really about?
The press release of course doesn't answer the question "why not use an actual OSI-approved license"?
What they describe seems pretty similar to AGPL, which is a pretty inconvenient license for use in commercial products, but is OSI approved. What does SSPL do that AGPL doesn't, and what about it makes OSI approval challenging?
The OSI doesn't approve any license that "discriminates on fields of endeavor", which means you are not allowed to prevent cloud providers from competing with you with your own product.
Premium sponsors of the OSI include AWS, Google and Microsoft.
Thanks. What about the SSPL is considered discriminating against a field of endeavor?
The AGPL is OSI-approved, and as I understand it also has a requirement "that if you provide the product as a service to others, you must also publicly release any modifications". (Possibly not "as well as the source code of your management layers", but that addition doesn't seem to post any additional problems related to "restrictions of fields of endeavor", I could see a future AGPL adding it, it seems somewhat the spirit of the AGPL).
What are the parts of SSPL that differ from AGPL in a way that OSI woudln't aprpove?
(The requirement about 'fields of endeavor' can be debated and is one of the currently more debated ones in OSI, but i my memory it goes way back in time to the early days of open source, I think you can probably find Stallman arguing for it before OSI even existed, I don't think it's there for some kind of nefarious reasons inserted by OSI sponsors. But certainly one can disagree with it.)
(Here's Stallman against fields of endeavor restrictions from 2013, definitely not pre-dating OSI, but I think this does go way back, and I don't think anyone thinks Stallman's opinions are bought by corporate sponsors, and Stallman is obviously quite influential in ideas about what open source is. https://web.archive.org/web/20130509151342/https://www.gnu.o...)
They'd have to re-license Open Distro to SSPL instead of Apache 2.0 to remain complaint, but I don't know if Amazon would be willing to do that. Considering they have to solve the hosted Elasticsearch problem anyways, I think either a fork or a one-off deal with Elastic is on the horizon.
It means that any “derivative work” will need to also open the management layer under SSPL. The management layer is AWS, so this puts OpenDistro in a tight spot. I’m not sure forking would work - as Elasticsearch evolves Amazon would not be able to copy features anymore. In the search space, this would be a very hard pill to swallow.
The source code for the various components that make up Open Distro is already freely available under an Apache 2.0 license. This change will have zero direct impact on Open Distro. The SSPL restrictions apply when the licensed software is used to provide a service.
It is the AWS Elasticsearch Service that will be directly impacted. It will be limited to Elasticsearch 7.10.x as a foundation. Unless of course AWS makes available the code that they use to orchestrate and manage that service. Assuming that that code is sufficiently uncoupled from other systems, they could perhaps do exactly that. It would certainly be an entertaining counter-move from AWS.
It looks like the way the license is written, they would have to release the source of the entire AWS console, and possibly everything that is AWS.
IMO, the SSPL's cloud provision is a "Japanese No", it is so wide in possible interpretation, that only the Eclipse foundation could actually provide such a service.
they’d still be able to innovate their own fork, but they will no longer be able to pull future upstream elastic code into it. so it becomes more of a hard fork. if elastic continues to innovate it will be difficult for open distro to remain competitive with it.
I don't think AWS really cares. They "bought" (the devs of), and killed, blazegraph to make Neptune. And since, Neptune doesn't really evolve much either so both projects are stagnating. Enough to say they can do "graphs" but not enough to really do anything useful...
Yeah at my last gig we used AWS’ offering. Blue green deployments would hit a race condition and the new cluster would never come up, requiring a ticket to be filed. Important APIs and settings were disallowed.
Horrible service. That’s why it’s ironic that Elastic just shot themselves in the foot with this licensing change. So foolish.
I hope that SSPL becomes the standard for companies so that at least it becomes a known entity instead of a proliferation of bespoke licenses: like if CockroachDB moved to it as well.
Personally, I'd rather see a more aggressive AGPL where REST calls are considered linking and trigger virality and I believe that would meet the definition of open source by the OSI while preserving the value of the commercial version.
The problem I have with the SSPL is that Section 13. Offering the Program as a Service seems pretty vague. Here's the part I don't understand.
> 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.
Does this include services you don't charge for? For example I might offer services for marketing reasons. At what point is the service no longer primarily derived from the Program? For example if I build an application that offers query capabilities but does not expose the Program API, does that count?
For contrast GPL V2 worked because it tied virality to linking, which is pretty easy to validate.
Yeah, I understand the SSPL has some issues that could use better clarification (exactly the extent the copyleft is intended to reach), but it is an aggressive copyleft license, and I'd argue, very in the spirit of open source. The parties using it could develop a more clear newer version to SSPL that addresses the concerns.
And the more companies adopt SSPL, the more pressure OSI will be under to accept a viable license for open source businesses.
> Personally, I'd rather see a more aggressive AGPL where REST calls are considered linking and trigger virality
That would be a horrible precedent. Sending an http request to a server should not trigger copyright violation. This is similar to newspapers who claimed that having links to their site, violates copyright.
The issue should be whether there is a linking and not the nature of the linking. I mean if "over HTTP" was a get-out-of-jail card then you just need a C-ABI => JSON standard, and then you can link any library you want and only the server-linker needs to be opensourced (and probably would be as BSD).
I believe this is why the GPL uses the term "derivative".
> This is similar to newspapers who claimed that having links to their site, violates copyright.
Making links to their site might violate the license by which they allow you to browse their site, but it doesn't break copyright. If the on their homepage had a pop-up "You must agree not to not share any links found on this site as a condition of using this site" that would be analogous.
> This is similar to newspapers who claimed that having links to their site, violates copyright.
No newspaper has claimed that ever to the best of my knowledge, and it would make absolutely no sense to. What's being criticized is so-called "rich linking", ie. previewing content such as Wikipedia articles from search engines or news articles from aggregators without taking viewers to the primary source/site. People having a radical anti-copyright agenda have conveniently named this "rich linking" to dilute the discussion, as have news aggregators to downplay the issue.
As an aside, the way the EU copyright reform is being formulated into national law in Germany has been criticized as outright contrary to the whole purpose of the reform, and coming straight from pro-Google lobbyists [1].
>Personally, I'd rather see a more aggressive AGPL where REST calls are considered linking and trigger virality
Please don't compare a license to a virus. In any case, my understanding is that the AGPL does cover this and is why it exists. If it didn't cover this it would be useless.
I believe AGPL expands the definition of distribution not of linking. So if GCC was AGPL and I made a web page where you could upload source code and then download the binary, that would count as "distributing" GCC and thus I would have to make the changes I made available (because privately made change to GPL code do not have to be shared if the binaries aren't shared).
There are some small-scale ES search-as-a-service providers that serve small and medium businesses.
There are also service providers whose core service is something entirely different and just use ES as the backend for their search APIs.
While the target is AWS (and I think what they are doing to service providers like Elastic and MongoDB is terrible), I think this will also adversely affect overall ES usage by many other companies.
In my mind, this strongly constrasts with the words [0] of WordPress founder Matt Mullenweg. He says they want to own roughly 5% of the WordPress market, and instead of growing their share of the pie, grow the pie itself.
Wordpress is huge precisely because it was open. Elastic is already quite large and would keep growing massively if they stay non-restrictive. Now that they've switched licenses, this may have a significant enough effect over the long-term that they're leaving a lot of "opportunity pie" on the table.
Well, now organizations like Wikimedia are going to have to drop Elasticsearch everywhere despite it powering wikipedia article search and more. So congrats on both missing the GP’s point and also failing to see how this license change would shrink Elastic’s usage / market anyway
They don't need to drop. They're not providing Elasticsearch and Kibana as a paid service to others. You can just read the FAQ: https://www.elastic.co/pricing/faq/licensing
Using Elasticsearch and Kibana is still free, unless you're selling them as a service like AWS Elasticsearch does.
> This change in source code licensing has no impact on the overwhelming majority of our user community
How come? If you switch open source to proprietary software (as much source-available as it may be), there's a significant impact: a % of users won't use proprietary software; those who may will not find this software packaged on package managers; derivatives and companion projects may stop being developed. Where's the "no impact"?
If you'd install ES via deb or rpm or whatever packages from your Distro, this will affect you, as they will be sooner than later removed.
If there's a policy for open source-only usage, you will definitely be affected.
If there will be a diminished number of contributors (which won't like to contribute if it is not open source) and ecosystem (that will stop developing/growing being a proprietary project), you will be affected too.
I wonder how many people contributed to Elastic which do not work for Elastic.co ? Those folks have reasonably counted on having fruits of their labor to be available under Apache 2.0 and now they only get to use them with SSPL restrictions
> Those folks have reasonably counted on having fruits of their labor to be available under Apache 2.0 and now they only get to use them with SSPL restrictions
While i hate the change, that isn't true. They have access to their changes in the current and older versions of Elastic. You can lock yourself to the current version forever and create your own bug fixes.
Those folks have reasonably counted on having fruits of their labor to be available under Apache 2.0
Not really; the essence of permissive licenses is that proprietary extensions/versions are allowed. If you want to contribute code that will always remain open you need a copyleft license like GPL.
I feel this way about all similar licensing changes (Redis, Elastic among many others). It's basically a large company vs much larger company fight, and the losers are the thousands of individual contributors not affiliated with either one who have worked for free and can no longer use their work in the way they want. Moves like this are definitely eroding trust in open source in the long term.
There's a fair amount of hyperbole in that statement. Most of the above products (Redis, Elasticsearch, MongoDB, etc.) don't have "thousands of individual contributors" and are developed primarily by employees of the backing companies.
Second, external contributors can use it in their work in any way that they want so long as it's not in offering Elasticsearch-as-a-service. They can even use for offering Elasticsearch-as-a-service so long as it's based on the current Apache2-licensed code rather than the SSPL-licensed code that will be in effect as of the next Elasticsearch release.
There are certainly valid criticisms of this decision, but a blanket statement that "thousands of individual contributors" are the losers here is an exaggeration.
The quantity of the individual contributors seems to be the only stretch you seem to be able to point out, yet you go further to trying to defend the SSPL license as limiting a very narrow set of applications - despite lawyers and open source advocates almost unanimously having said the license text itself is ambiguous enough to cover a much larger set of use cases.
If you are not a lawyer and if this is not legal counsel, I'd suggest you leave your personal interpretations of a license that is broadly considered to be less permissive than advertised outside of civil discussion.
>There are certainly valid criticisms of this decision, but
Why the but? Obviously this decision hurts AWS but it also hurts a much broader group than them.
my intention there was (and still is) to learn how other HNers think of this. In there I got the response about how the precise version to which people contributed, was and will always be Open Source, regardless of what happens to future derivations of that code.
I'm not sure I bought that reasoning, though... you put it better with that "fruits of their labor". Maybe not the writing, but the spirit of the permissive FOSS licenses is not to end up being swapped into a non-FOSS alternative...
The previous FOSS license did indeed permit any future change in licensing; I would like to learn if that kind of choice might actually become a deterrent and an added reason for a lower number of external contributors, or not.
> Maybe not the writing, but the spirit of the permissive FOSS licenses is not to end up being swapped into a non-FOSS alternative...
Well, you can argue the spirit all day, but in practice, permissive licenses mean what they mean. Once a version is released with that license it stays that way, but subsequent versions can have a new license.
Basically, you do keep the fruits of your labor - you get Elasticsearch 7.10 and all previous versions. But you have no right to Elasticsearch 7.11.
Note: In practice I agree it's a dick move to go to a more restrictive license, and I strongly disagree with Elastic's decision to do so. It's just a greedy move that won't even make them more money in the long run because it will cripple the momentum ES has.
elasticsearch had a contributor license agreement in place for about as long as I can think, requiring full copyright assignment for all changes you’d contribute.
It is effectively very similar to copyright assignment as it gives Elastic basically the same rights they would have if they were assigned the copyright. The only difference is the contributor also gets those rights, but in reality the rights they keep are not that useful since the rest of the codebase is owned by others.
Seems like there’s no talk on why they picked SSPL over BSL?
I like BSL because it always eventually transitions to an ordinary open source license. So over time all BSL licensed code will actually be open source. That seems to not be the case with SSPL?
It also prohibits use of Business Source Licensed software, but as source code under that license will always after at most 4 years transition to a GPL compatible license, all such code will eventually be possible to use at Google and one can easily maintain a GPL-compatible fork that merges code in as the BUSL expires, thus enabling a good exchange between BUSL and open source, whereas no such exchange is possible with SSPL, its forever stuck in a AGPL like license and most companies generally stay far far away from AGPL.
BSL doesn't let you use software "in production" at all. So you wouldn't be able to offer search on your website with Elasticsearch at all, whether you could be construed to be reselling it or not, and whether your whole stack is opensource or not.
Also the SPDX identifier for it is BUSL since BSL was already taken by the Boost Software License.
Not true that it doesn’t allow production usage, it just doesn’t do it by default.
The intention is that it’s up to the one using the BUSL to specify to which degree production usage is allowed:
“The Licensor may make an Additional Use Grant, above, permitting limited production use.”
Eg. Sentry allows all non-SaaS production deployments of their BUSL licensed code, which is pretty much the same goal as here, but with BUSL the code will be actually open source eventually whereas here it will stay in this extended AGPL-like license forever?
> outright attempts to splinter our community with “open” repackaging of our OSS products
That make it sound like packaging together the open source core with some third party plugins that could be used in place of proprietary plugins from Elastic was somehow some evil plot to destroy the community. Was the goal of the package to increase the bottom line of a company other than Elastic? Probably. Was the goal to splinter a community from which said company profits? Probably not.
Are there any known instances where a company offering Mongo or another SSPL-licensed app as a service has complied with section 13 by releasing the “Service Source Code” of everything supporting the service?
If not, that basically confirms the OSI's rejection of the SSPL as an open source license -- If that provision is too onerous to be followed, it might as well say "you can't offer this as a service".
In principle this should not be a big problem. See how Red Hat successfully works with GPL code.
I think the big issue is that all Sass Providers considered themselves free from such pesky license details like copyleft, because they don't distribute software.
I think the biggest problem with the SSPL is its vagueness when it comes to liabilities and its broad reach when it comes to contagion. In principle, a copyleft license that covers service providers is long due, but it better be a good and practical one.
You could say the same about the GPL - the practical effect is almost never to make a company release their previously-proprietary source code, the practical effect is to make companies not use it in the first place. Which is fine, as long as it's clear what the rules are, and the rules seem clear enough to me.
I don't think this is correct. It definitely seems like code that would otherwise be proprietary does end up being open sourced in the case of the Linux kernel with certain drivers.
Does not sound good to me, for the reasons that others have mentioned. But just to be clear: if a big cloud provider uses their software to make money, that's great. That's the point of a non-restrictive license.
Yet now Elastic isn't content with competing in the market with its own managed offering (ironic because their offering is way better than AWS' anyway). Instead, they want to call themselves open source while switching to a proprietary license. Shameful.
If companies want to make the software available under a license that allows me to use it for free, examine the source code, make changes, and release those changes to the community for others to use -- everything except taking their software and re-selling it directly, then I'm 100% fine with that.
I don't care about not being allowed to compete directly with Elastic using their own product against them.
They'll have to base their service off the last Apache-2 version of Elasticsearch. Unrelated to this license change, but they'll probably have to rename it, too, after the trademark infringement suit finishes.
Or they could, you know, just respect the new license and publish their changes and part of their "secret sauce". I bet it would be anyway tightly coupled to other AWS internal services so nobody would get hurt in the process.
what layers would they have to show? All of them up to bare metal? This is madness, should you be able to show your UEFI firmware? Should the server's out-of-band-mangement firmware be available as well?
It's GPLv2 all again, yeah. I remember similar comments 20 years ago about GPLv2 code when used for libraries. And that's good, although in the end they came up with LGPL for that scenario.
Anyway I agree that the license is too generic and can use some more details but IMO it should basically cover all the automatism you explicitly create to manage the software you are selling access to. I mean, there is no need to publish the secret sauce for EC2 because it exists anyway and it's publicly available anyway.
To sum it up, I'm not against the spirit of the license but I agree the implementation should be better.
This is the key. The license doesn't say what layers have to be shown. AWS isn't going to open source all of AWS. They'll take their hundreds (probably thousands) of java developers, make a proprietary fork instead.
Then they fork the project, and none of the improvements AWS makes to the fork gets pushed upstream to ES. Which only hurts Elasticsearch as a project.
ES can take their ball and go home. But they're doing so to their own detriment.
There is some discussion on the P2P Foundation regarding copyfarleft/copyfair/copyjustright however in my experience even the most popular copyfarleft isn't as adopted. ( https://wiki.p2pfoundation.net/Copyfarleft )
I already knew about the Anti-Capitalist Software License but didn't know about the others. Copyfarleft is a great concept.
To make this work we need to build an ecosystem around these licenses and non-exploitative business models. The fist step is indeed to let people know such licenses/ideas exist.
Let's be clear here: You build something. You release it under a license that says, "do what you want with it, profit with it, I don't care". Then someone comes and builds on top of it, and you call them a thief? For using something you told them they could use without restriction?
Related: I find it really bizarre how many in the tech community seem to outright just not believe in capitalism...
SSPL isn't being used as an alternative to permissive licenses (e.g. MIT). It's being used to shore up the holes that AGPL doesn't cover[1], to enable the business model of "free for small guys, paid for by the big guys".
People want a license that says something like, "you can only use this if you also contribute to the commons, or if you pay for the privilege not to". SSPL is an attempt to be that. Maybe it doesn't do that job well, but don't confuse it as competing with permissive licenses.
I know it’s not competing with permissive licenses. That’s my point. The people here acting like the fact that companies are profiting off of Apache 2.0 licensed code are being unreasonable was my point.
Separately, I think this move will just hurt Elastic Co in the long term. The organization I work for runs a 30 TB elastic cluster and we’re going to have to go drop Elasticsearch because of this change because we’re committed to using free and open source software. What a shame.
Good luck with a lot of wasted work power because you are sad that "big Corp" can't exploit anymore "small software house". Please, this is ridiculous.
Anyway, I'm sure many others like me are sympathetic to the cause and will support companies like elastic that take this kind of decision. I don't think elastic will miss you.
I work for a very well-known non-profit. You probably visit our site multiple times a week, if not per day. We're going to have to move off of Elasticsearch powering our article search, despite us not offering Elasticsearch as a service or anything remotely comparable, because we believe in running free software in production only.
So, I hope you enjoy taking the holier-than-thou stance. It must be nice up there.
The big problem I have is that in their marketing material up to this point they stated “Apache 2.0: Now and always”. They had two lawsuits they filed against competitors, both AWS and SearchGuard because they have basically been making money off of Elasticsearch. I don’t think those lawsuits are going well so they changed the rules, and will likely do so again if they lose money to competitors. I don’t trust them, in particular I don’t trust their founder and CEO. He lied to the community and is cashing in in the community’s work.
Calling the blog post “doubling down on open” is an insult to the community’s intelligence. They should be more “open” and honest about what their doing and why instead of playing the victim.
That can't really happen. While Elasticsearch was previously released under the Apache 2.0 license, it was still "owned" by Elastic.
Lucene on the other hand, is "owned" by the Apache Software Foundation (ASF). While companies can build products based on Lucene, which they release under their own choice of License, they cannot change the Lucene license itself. Only the ASF can do that.
Another example of this is Kafka. It was developed at LinkedIn, who transferred control to the ASF. When the LinkedIn employees who originally created Kafka, left to form Confluent, they had no control over the licensing of Kafka. They could only decide on the License for the Kafka add-ons that they provide. Eventually (about a year ago) they forked Kafka to create "Confluent Server", which is released under their proprietary license. Kafka itself however remains open source under Apache 2.0 license, still controlled by the ASF.
"Trust" may be too strong of a word. I would say that one should expect more consistent and predictable behavior from a foundation. I have however seen some questionable actions in the name of the ASF, where the motivations were obviously influenced by project committee members with a commercial interest.
You are correct. And "contributes back" would mean having to open source all of AWS, so they aren't going to update Elasticsearch beyond v7.10. They'll likely hard fork it and continue to develop it themselves.
Everytime an open source project changes it's license to protect against cloud services not "paying their dues" a lot of people say it doesn't matter because the company will only go after the cloud providers, the big players, and if you just use it internally it won't affect you.
I think people forget that these companies might be bought in the future by Oracle.
It seems like overall this was a long time coming and there had been precedence with MongoDB prior to as well. It's never a good thing to think that open source developers need to divert attention to such seemingly hostile actions though it seems credible enough that is was necessary for that reason.
So they'll be source available moving on, like MongoDB. Will keep it in mind.
By the way, I am not a lawyer and I might have misinterpreted the article, but I feel like the AGPL could have accomplished what they wanted to do. Maybe it's not restrictive enough for their needs, but I'm not sure why.
Well I just cancelled my talk submission to the Elastic Community Conference and cancelled my registration. If they want people to give them free content then pull this crap I don’t want to be part of their community. If they want my content they can pay me.
Asking cloud providers that use open-source for a free ride for their own profit while not contributing back to either contribute, pay or GTFO is definitely something that more software companies ought to do.
I was just looking at Elasticsearch a while back and was considering learning it, but I guess they've crossed that open-source tech out of a list of things I need to learn!
How does this affect people providing “search” functionality of arbitrary items, but not Elasticsearch itself (AWS)? Where is the line drawn? Is the SSPL vague enough for that?
So, let's say you've got a product catalog in some SQL database. Your business processes update inventory and availability and leadtime and such in that database.
But you really like the lucene natural language search functionality, so you copy your database into a lucene database for searching. But hey, elasticsearch takes care of a bunch of tedious problems, so instead of using raw lucene, you use elasticsearch...
So, you've got a PHP web application that queries this cache of the catalog stored in elasticsearch; what's your legal liability?
> It's just a change to make sure that those who resell ES as a service share their code.
No, its purpose is clearly to prevent others from reselling ES as a service at all since it's effectively impossible for anyone offering ES as a service to comply with the SSPL, if they were only concerned about others that offer ES as a service sharing their code AGPLv3 would be sufficient.
> The SSPL allows free and unrestricted use, as well as modification, with the simple requirement that if you provide the product as a service, you must also publicly release any modifications as well as the source code of your management layers under SSPL.
Not a lawyer, but I think AWS fall foul of "as well as the source code of your management layers" because they have a massive amount of closed source stuff running behind their ES service.
We use AWS's ES. And, as far as I'm concerned they already open-source their version.
Unfortunately for you, there's a decent chance that AWS freezes their support at a version before this license change, and never offers upgrades. As far as I know, AWS has never agreed to offer services based on code under the SSPL license.
Also, why is SSPL not open source? As far as I can tell, it mostly just seems like the APGL, but taken to 11. I can definitely appreciate why it's a problematic license, but I don't think "not open source" is its problem.
It seems it has neither the OSI's blessing as an Open Source licence, nor the FSF's blessing as a Free Software licence. Can anyone comment on why not, given that the AGPL has the blessing of both organisations?
edit Here's an informative StackExchange comment. [0] Apparently it's a good deal stricter than the AGPL, and introduces much more legal uncertainty.
One of the core tenets of free software licensing is that there is a fair, symmetrical relationship for all parties involved.
Elastic obviously does not publish their own management infrastructure code under SSLP, so the reason for this license to exist is to make the playing field uneven as opposed to all the other free software licenses.
Basically, they can benefit from your code on top of and around ES, while you can't from theirs. This is actually the result of dual licensing but with other free licenses, at least the symmetry is maintained for the core product.
I am not making a judgement call here, just explaining what the distinction is.
Yes, I could see someone putting forward the argument that the SSPL is so unusable that ElasticSearch isn't actually expecting anyone to use it, and therefore it's more of a marketing gimmic than a license.
The Elastic blog post announcing the change never says exactly those words, but it repeatedly talks about being an "open source company" with an "open source product" -- despite the fact that Elasticsearch is now available under a choice of two different licenses, neither of which is "open source" under any reasonable definition.
(The other option, the Elastic License, allows you to use the product in either source or binary form, but you may not make derivative works or compile your own binaries except for testing.)
On the license there are 3 main "propagation" clauses: Conveying Verbatim Copies / Conveying Modified Source Versions / Conveying Non-Source Forms
Furthermore: Acceptance Not Required for Having Copies / Automatic Licensing of Downstream Recipients
On the other hand, the "issue" seems to be an Aferro-like clause that conveying it as a service combined/linked with other software over a network _counts_ as distribution an gives a right to the users to request the source code that makes the service work.
"open source" appears 19 times, but they very very carefully weasel-word their way away from saying they are still open source. but wow how close they come, how much it seems to imply they still are going to be open source. some examples:
> SSPL is a source-available license created by MongoDB to embody the principles of open source while providing protection against public cloud providers offering open source products as a service without contributing back.
forgive me for not immediately seeing that this is an "open source inspired" license, not open source.
> As previously mentioned, over the last three years, the market has evolved and the community has come to appreciate that open source companies need to better protect their software in order to maintain a high level of investment and innovation.
...by no longer releasing open source software
> As previously mentioned, over the last three years, the market has evolved and the community has come to appreciate that open source companies need to better protect their software in order to maintain a high level of investment and innovation.
again, "we value the same principles as open source... but we're not going to be open source any more" obfuscation.
Luckily there are faster and smaller alternatives in Rust for the ElasticSearch - Toshi[1], Meili[2] and Sonic[3]. In the age of Rust there is no need to use JVMs overhead.
One thing to point out though is that Typesense, MeiliSearch (and Algolia) are designed for Instant Search experiences, and so hold the entire index in memory. So for petabyte scale data (like logs) it might be wasteful (and expensive) to store that size of data in memory. This is where ElasticSearch shines and of course comes with it the overhead of managing it.
> Sonic is integrated in all Crisp search products on the Crisp platform. It is used to index half a billion objects on a $5/mth 1-vCPU SSD cloud server (as of 2019). Crisp users use it to search in their messages, conversations, contacts, helpdesk articles and more.
JVM overhead is overrated. And I say that as someone who's not particularly fond of the JVM. Elasticsearch is one of those projects where the JVM is not the issue.
Of all the projects you mention however, only Toshi addresses clustering, and as an experimental feature.
If you're using it for logfiles, the only real alternative I know is Grafana's loki.
According to the Rust evangelists only Rust solves problems - and it solves all the problems in the world, while C/C++, Java, Go or C# just create problems.
The way I understand it, AWS has been creating derivative products that don't work very well based on ELK. AWS has also not been contributing back to the community anything, while raking in the millions for https://aws.amazon.com/elasticsearch-service/the-elk-stack/
Many elastic pros recommend not using the AWS version because it doesn't operate properly.
While I am pro OSS I can understand why a company based on OSS would not want to subsidize a much larger AWS who is extracting value, and also, their direct competitor.
When I talked with AWS about an estimate for Managed ELK, and also, an EC2 based ELK, I received estimates > 50M a year. Crazy pricing
Disclosure: I work for AWS, but I do not work directly on Elasticsearch related services.
Elasticsearch is/was an "upstream" for Open Distro for Elasticsearch (which is a distribution / collection of software). As an "upstream", changes to the core Apache 2.0 licensed software was sent as pull requests to Elastic, which are usually merged. It isn't correct to say that AWS has not been contributing to the upstream Elasticsearch code under an Apache 2.0 license (and, also, signing the CLA to boot, which allows Elastic to relicense AWS contributions under SSPL).
Here's a sample of PRs from AWS developers that I could find:
The article loads for ~10 sec, shows for a split second and then the screen becomes empty. I'm using a moderately old browser (FF 61.0.1) but come on, how hard it is to display some text?
I'm sure it does. Maybe it is unreasonable to expect a blog to be readable on a 2 years old browser, but it looks like it took some serious effort this time.
Be honest, treat us like adults and cut all the 'we're doing this to remain open' crap. You are a public company who wants to increase the cost of development to your competitors so you can increase your market share. That's it .
Maybe that is too cynical, but I recently went through a license shift (GPL to Apache) with TerminusDB and we were clear that honesty about motivation was the best formula for comms.