The post feels very self-entitled and needlessly inflammatory.
Elastic's changing their license. No contributions are being stripped of their open source license. You always have the last open source licensed version to go back to and fork if you like.
What this author is upset about is that Elastic are no longer providing updates under a license the author feels they are entitled to.
Maybe the author should fork the project and maintain it under an open license themselves?
Doesn't matter who has contributed to the project - whoever they are they own rights to keep the code base open and licensed open, but they don't own the name or the trademark rights. It would be well within Elastic's rights to change the name on the repo.
Does not being able to call itself Elasticsearch make a fork inoperable? I don't think wanting to protect a brand they've been investing in for years is unreasonable.
Don't get me wrong. It would be great if Elastic, Redis and co didn't have to do this (change license) but AWS does pose an existential threat to their business models long term. I'd rather a standardised, so there's less fear around interpretations, more restrictive license than the businesses and _future_ ones becoming unviable.
Is it? Do you really feel AWS' model is healthy for free software in the long term if business models around the creation and maintenance of open source projects disappear?
I would say Google's approach of partnering with maintainers instead of competing with them is healthier, though only just.
I don't know if open-source _businesses_ are healthy for open-source. It seems to fit much better with community volunteer projects without the pressure of trying to develop a business model around them: which feels like the root of the problem. Sponsoring developers with Patreon and donation runs has worked in the past and given us great projects.
I'm genuinely interested in examples of great projects from those funding sources.
When I think about OSS databases for example I can't think of any widely used ones that don't have at least one commercial entity that provides maintenance and support which funds development.
There's difference between a) having a big corporate backer for an open-source project vs b) a company and business built around that open-source project.
The incentives and existential threats towards the project are completely different.
There is evidence to the contrary that seems to be relevant here.
To wit, it's an "open-source business" providing the open source software people apparently feel very strongly about, not a "community volunteer project without the pressure".
The business model of having a monopoly on hosting Elastic was never compatible with open source in the first place.
Open source in a business context is built on the premise of several suppliers competing on the same product. I can't help but notice that the increased competition made the product severely less neutered, as Amazon did publish their Elastic distribution as open source just as the model prescribes, and this put pressure on Elastic to reduce some on the limitations from theirs. No Tivoization seemed to have taken place.
While partnering would have been much better for Elastic, I'm not sure Google would have done it better in this case.
I am not interested in models. I'm interested in actions.
You want some guarantee that AWS, Google, or Elastic will treat the OSS community right. That guarantee doesn't exist. People bought in to Elastic's "guarantee" on this front years ago, and that did not pay off. There's no such thing as a model that stands the test of time; there's only today. Does it solve your problems? Is it licensed in a way that preserves the freedom of its users and maintainers? Is there recourse if that changes?
I'm surprised to see the reaction here on HN, but I'm starting to realize I'm from an older generation of open source contributors and don't share the values of some here.
The point of open source wasn't to enable viable business models for companies like Elastic. The ASL is commercial-friendly, but the design of the license wasn't to enable any specific business model. It was to ensure the widest range of freedoms.
A lot is made of the way Amazon is "taking advantage" of the license, but they aren't. They're doing exactly what is allowed, what anyone is allowed.
IMHO, if you're releasing your work under an ASL-like license, then you're making a specific promise to the community about the freedoms related to your code. You're making a promise to all the adopters and contributors. The license is a promise (literally a contract) about what to expect from each other so that we can all contribute on the project together.
When an actor unilaterally changes that agreement, it's understandable some may be upset.
And while I know it's trendy of HN to discount non-profits like Apache as out of touch or old-school, they serve an important function in the open source ecosystem. As a non-profit, Apache doesn't really care too much what Amazon or any big or small tech company does with the code, as long as the original code remains open source and there is a community that can continue to work on it. The continuation of the community is paramount, above and beyond any one company's business model. We want software, particularly internet middleware, to be stable and last for generations.
When we take a long term view for the health of the interview, Elastic's move is great for Elastic, but not for the internet as a whole. Consider where we'll be if/when Elastic collapses. Right now, Elastic has plenty of fans, but we have no guarantee that they will remain competent, competitive, and innovative over time. If their hosted service suffers, their new license ensures that no one else can compete.
The advantage of broadly supported open source projects is that they can out last any one company (e.g. Sun) or any one person, so that we can build a technical commons for the future.
It's a sticky situation, because while these restricted licenses are clearly worse for user freedom, they are also "better than nothing" if you assume there are too few volunteer contributors and funding sources for the paid employees to continue development.
I would love to know whether these quazi-open licenses will be considered successful for the companies that switch to them. There's a short term cost here, in creating market confusion and fragmentation and general uncertainty - the potential benefits can only be realized down the road, a few years once the dust has settled and the offering has enough compelling improvements to what AWS gives. Are those benefits real?
My intuition is that, if you consider yourself in the business of competing against an Amazon hosted version of your own software, you've already lost. Amazon will destroy you in the end, regardless of whether they can directly use your code or whether they need to implement their own alternative (either from scratch or based on a different solution on a different OSS product).
To me, this sort of license change kind of reads as desperation.
> A lot is made of the way Amazon is "taking advantage" of the license, but they aren't. They're doing exactly what is allowed, what anyone is allowed.
Elastic is also not "taking advantage" of the license. Apache License 2.0 can be combined for example with GPLv3 or as in this case Server Side Public License. This is the freedom that Apache License 2.0 provides. Both companies do what they are allowed to do under the license.
You may not like the freedoms that Apache 2.0 provides, but then you should not contribute to projects under that license. GPLv3 does not grant you the freedom to easily change license terms, so probably you should contribute to projects with that license or similar.
> If their hosted service suffers, their new license ensures that no one else can compete.
How does it ensure that no one can compete? If you release the infrastructure code you can compete.
I should perhaps do a bit better clarifying between:
a) The code
b) The community
The issue is more that the open source work had been happening under the support and auspices of Elastic with a certain license. Elastic is relicensing and the rest of the community is within rights to not want to support Elastic's now non-open source fork.
The problem is that there are /two/ aims; one which people agree on, and the second which people disagree on.
The first is source /must/ be available and /modifiable/; on that all proponents of FOSS are agreed; exactly for the reasons you've stated.
The second is that we want /more/ FOSS software; not less. How we achieve that is essentially where people differ. The issue with big companies which contribute nothing or very little back to the ecosystem is the tragedy of the commons. Eventually, the number of people working on FOSS will dwindle and we won't /have/ FOSS alternatives or communities.
For the record, I don't even think that AWS are the worst offenders. I've worked at places which refused to even contribute bug reports or patches to upstream systems.
The license does not deny others the right to build on the software. The license is a fork of the AGPL and adds a clause that requires you to open source not only software, but supporting software that is used to run the service. One could argue that this license would result in more publicly available software, not less.
Here is the clause for reference:
> 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. 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 Software or modified version.
Right. But the point here wasn't that Amazon is doing something wrong in respect to the license. They release their modifications to Elastic, and they could theoretically release whatever "functionality" is required to "interact with the functionality of the Program".
What was being argued was that it was ethically wrong of Amazon to engage in this business without some sort of blessing from (and, one would imagine, revenue sharing with) the original developers. Under that argument, their misdoing isn't releasing too little, but doing the work in the first place.
Something like the AGPL can absolutely be a tool for more FOSS in the world. But I think there was two things being argued here.
I am currently struggling a bit to understand this, so please correct me if I am wrong.
So if I understand this right: Elasticsearch was under the Apache 2.0 license, which, contrary to FOSS-licensed (GPL and co.), allows derivatives to be under a different license. Now they changed to a proprietary source-available license, because Amazon.
If that is true, then I don't understand this: Contributors that have contributed to an open-source Apache 2.0 licensed project should have understood, that contributing to such a project means that they don't have the same protections to their work as with a FOSS project and that big companies can just take your contributions and give nothing in return.
It doesn't actually have anything to do with the choice of the Apache license, though you would still be correct in that case. Elastic made users sign a CLA which signs over contributor rights for distribution without any conditions whatsoever, which means that for all they care Elastic could have relicensed it as closed-source, proprietary software.
The point is not that they couldn't do this, but that it's a dick move which betrays the trust of their community, and is ultimately harmful to the goals of open source.
> The point is not that they couldn't do this, but that it's a dick move which betrays the trust of their community, and is ultimately harmful to the goals of open source.
I understand that a re-licensing to proprietary from upstream it self is really annoying and hurtful to the open-source project itself. However the only distinction of upstream doing this with a CLA and somebody else is that upstream can reuse use the project name, infrastructure, etc.
Or are there any other consequences of upstream doing this vs. someone else?
It could also be the beginning of something new: See OpenOffice vs. LibreOffice.
>Or are there any other consequences of upstream doing this vs. someone else?
Yep: the community is built around the upstream project, and has a lot invested in their continued existence as an open source entity. This move will force the community to start from scratch to build a new entity which continues to meet those guarantees - something Elastic plans to capitalize on by capturing more users on its paid offering while the open source community struggles to set up a new entity at the same level of sophistication from scratch.
The community is not without options, but that doesn't change the fact that what Elastic has done is wrong.
Note: HN has been rate limiting me rather strictly today, so I'm losing my ability to keep up with this discussion. Sorry.
> Yep: the community is built around the upstream project, and has a lot invested in their continued existence as an open source entity.
Ok, that was what I meant with 'upstream can reuse use the project name, infrastructure, etc.'. Probably a very big 'etc.' here.
So your point is more about that the contributors and the community helped build the brand and recognition of ElasticSearch, which is now, taken away from them.
That is a fair critique, IMO.
However, that Elastic as upstream of the project suddenly disappears for the community, I find is something, that unfortunately, many open source projects have to go through sooner or later.
>the community helped build the brand and recognition of ElasticSearch
and the software itself. Elasticsearch accepts patches from the public, albiet accompanied by a signature on the CLA that grants Elastic unfettered rights to do anything they want with the code.
>However, that Elastic as upstream of the project suddenly disappears for the community, I find is something, that unfortunately, many open source projects have to go through sooner or later.
Maybe, but it still doesn't make it right. This wasn't an accident, or the consequence of a company gradually succumbing to attrition. It was deliberately done for the profit motive in an already profitable company, and excused away with gaslighting and misinformation. This is why I chose to criticize them on my blog.
Often when licenses change, the old versions of the repositories, that are still under the old license are still available. Isn't that the case here as well?
Granted, employees of Elastic, might have unknowingly written code that is now under a proprietary license. But code of most other external contributors should still be under the APL2.0, right?
> Maybe, but it still doesn't make it right. This wasn't an accident, or the consequence of a company gradually succumbing to attrition. It was deliberately done for the profit motive in an already profitable company, and excused away with gaslighting and misinformation.
You are blaming a for-profit company for making supposedly for-profit decisions, which is nothing new. If you could show that their actions where dictated by short term greed (which is mismanagement in a for profit company), then this argument would bite more IMO.
A good argument for your critique is also their press release, where they try to explain 'nothing has changed' while in fact the license has.
> This is why I chose to criticize them on my blog.
Of course its a very annoying situation and IMO you are right in criticize them for causing it.
I agree that this should be a lesson about licenses and especially CLAs, which I address directly in the article. That doesn't prevent me from criticizing Elastic for what they've done.
> Elasticsearch was under the Apache 2.0 license, which, contrary to FOSS-licensed (GPL and co.), allows derivatives to be under a different license.
No. Copyright prohibits you from changing the license on copyrighted code. Do some licenses allow binary redistribution? Sure. Do Some licenses allow source redistribution? Sure.
Can you include Apache 2.0 licensed code in a GPL project? Yes. But you can't change the original license for the code.
> Elastic has spit in the face of every single one of 1,573 contributors, and everyone who gave Elastic their trust, loyalty, and patronage.
It seems more likely that people were using Elastic because it works well and is free, not because it's open source. Still, companies are indeed their own best friends first and friends of their customers and employees second.
Users don't generally care that the source is available for the purposes of reading it, or even modifying it. They care that the source is available because its a signal of their freedom to use the software how they wish; whether that's hosting with Elastic, hosting with AWS, or hosting it themselves.
Any license which restricts a user's ability to use the software how they wish is no open source license. And the OSI has so far supported this; the SSPL is not an OSI approved license, despite being submitted for approval by MongoDB then retracted a year later.
> Any license which restricts a user's ability to use the software how they wish is no open source license
That's the thing though. The only thing (from my naive understanding) that SSPL limits is a business (Like Amazon) from offering Elasticsearch as a service. If an organization (Like Amazon) wanted to use Elasticsearch internally (to say, power some part of their shopping platform), they are free to do so with this license.
It's essentially protecting Elastic's business model, which quite honestly, should be the bare minimum offered by any open source product.
There's nothing wrong with using a licensing model like the one you describe. If don't want Amazon to use your software, then license it as such, whatever. However, that software is not open source.
Furthermore, if you change a project which is open source, to a licensing model which is not, it's a dick move.
It's not important if the needs of the business are "reasonable", we could argue about that but it's beside the point. Open source has no relationship with the requirements of your business. It has a specific meaning, and if you betray those principles, you betray the people who trusted you on those terms.
AGPL does not restrict how you use the software, rather, it requires that you offer the same freedoms to your users as the original license offered to you. You can sell AGPL'd software.
> AGPL does not restrict how you use the software, rather, it requires that you offer the same freedoms to your users as the original license offered to you. You can sell AGPL'd software.
But doesn't SSPL allow you to offer ElasticSearch-as-a-Service as long as you contribute the source code that makes it work? Many have commented on how that requirement is a no-go for AWS however they are not a priori forbidden by the license from doing so.
But in practice, there are zero options for managed hosting of MongoDB 4.0+ outside of Atlas that I'm aware of (and we looked, everywhere). By my understanding, from speaking with some sales/product engineers at third-party companies which previously hosted MongoDB or currently host 3.6, the terms of the SSPL are so vague that its effectively a card that reads "you can host MongoDB, but if you become a threat to Mongo's business, we'll find a reason to sue you, and we'll win". So, no one does managed hosting anymore, or they're still on 3.6 with no intention of upgrading.
Its possible that, if a hosting provider were to try and meet the terms of the SSPL, and succeed in doing that, and get some kind of validation of that success from Mongo or Elastic, then some form of precedent could be reached and that would increase confidence in the SSPL being defensible from a vendor standpoint. But, that never happened with Mongo. Maybe it'll happen with ES, given ES is far more popular.
Another possibility is that those managed hosting providers could obtain another license for Mongo. (Dual licensing between (A)GPL and a commercial license does happen, for example with Qt framework)
Mongo has tried to get the OSI to approve it, but ultimately withdraw the license. The precise semantics of how much or how little the license diverges from the requirements of open source is an interesting topic for another time. For one, no other license, copyleft or otherwise, extends your obligations to software which is not actually a derivative work, which if nothing else requires a novel interpretation of the OSD. For now, though, I'd rather focus on the conclusion: this license does not qualify as open source, and that betrays those who choose to use or contribute to Elastic on the basis of its open source nature. They didn't get on board with the project in order to see how a dubious new license would hold up under scrutiny. This change was made for dubiously-justified commercial reasons on the false presumption that Elastic has the sole right to exploit Elasticsearch (and Kibana) for profit, software that they have shared ownership over (including in terms of copyright) with the broader community. They were allowed to do this, by the letter of the law, but it is fucked up regardless.
> For one, no other license, copyleft or otherwise, extends your obligations to software which is not actually a derivative work, which if nothing else requires a novel interpretation of the OSD.
Copyfarleft[1] has been discussed for almost a decade now and has spinoffs like Copyfair[2].
> The precise semantics of how much or how little the license diverges from the requirements of open source is an interesting topic for another time.
There is definitely a gray area there but the comment I originally replied to naively equated open source with the more permissive licenses.
> They were allowed to do this, by the letter of the law, but it is fucked up regardless.
The only criticism I would levy is that those licenses haven't been polished by time nor copyright-license-experienced lawyers.
Their recognition from FSF/OSI is not their goal and and argumnt can be made that copyfarleft / copyfair pushes the boundaries of open/free/libre source software so they might not pursue recognition from the get go.
I don't think that these licenses are relevant. If we can agree that they are not open source, then we can agree to the point I'm trying to make: changing from an open-source to a non-open-source license is a significant change which, when done without the consent of the community, is wrong.
I don't agree that they are not open source, I only agreed that it is a gray area and even on the previous comment mentioned that it is "pushing the boundaries". For eg, I maintain an "awesome-copyfarleft" list: https://github.com/LibreCybernetics/awesome-copyfarleft
> changing from an open-source to a non-open-source license is a significant change which, when done without the consent of the community, is wrong.
I don't think consensus is possible and even a 2/3 supermajority on a license change seems out of reach. I can imagine some are pushing for permissive licenses like MIT/BSD, others for GPL/AGPL, others to remain as Apache 2.0, etc.
Sorry, you are simply wrong on this matter. It's not a subjective issue, it s a statement of fact that these licenses are not open source. There was a recent attempt to change this within the OSI, which badly failed.
>I don't think consensus is possible and even a 2/3 supermajority on a license change seems out of reach. I can imagine some are pushing for permissive licenses like MIT/BSD, others for GPL/AGPL, others to remain as Apache 2.0, etc.
Correct. That doesn't mean that they can choose to change the license anyway. That means that changing the license is not right in the first place.
> That doesn't mean that they can choose to change the license anyway.
Under Apache 2.0 and as they did retaining the contributions as Apache 2.0 they can though. As far as I have seen there havent been any legal challenges to the licensing change on this comment section.
> That means that changing the license is not right in the first place.
This is a non sequitur though, the premise that precedes it (that "they can't change the license (legally or under the terms of Apache 2.0)") is false.
> That doesn't mean that they can choose to change the license anyway.
I have already repeatedly stated that they were within their legal rights, including in one of my replies to you. I assumed this was a given. When I said they "can't", I did not mean "can't (legally do this)", but "can't (do this in good concience)."
Not forbidden, but SSPL goes beyond AGPL in a key way by defining the source that must be released as wider, including any code necessary to offer the covered code as a service, such as user interfaces, backup mechanisms, provisioning etc. That might indeed be more than AWS is willing to do
Its also worth saying, at least in Mongo's case, AWS's managed offering (DocumentDB) is not, in any way except the API, MongoDB. Internally its based on Aurora. But, by my understanding, the SSPL also covers MongoDB's API, so this is why DocumentDB has not attained anything higher than 3.6 compatibility (and even its 3.6 compatibility is ish, but that's not for legal reasons by my understanding).
Amazon definitely doesn't want to open source Aurora. Not only is it a massive moat for their cloud, its an extremely powerful database, but there's enough evidence to conclude that its so internal-AWS-reliant that it would be almost useless to anyone not running on AWS.
I honestly don't understand how this got so out of control.
First of all while there are so many contributors the vast majority of commits seem to be by elastic team members.
Secondly, elastic provides a lot more than just the code.
Third, they're a for profit company and have been from the beginning.
So with all of that in mind to me the change seemed perfectly reasonable.
Materially it doesn't really change much for anyone other than Amazon.
Last year CockroachDB did the exact same thing and I don't recall anywhere near the outrage. Perhaps it might be because it's significantly less popular but everyone out on their soap boxes now surely should have been making noise then as well.
Furthermore, a lot of these arguments seem to be very black and white. You either are or aren't open source. Surely there are shades. Surely the OSI definition isn't the only one. Surely being able to contribute, modify and run for your own purposes still counts for something.
It really is the case that everyone wants OSS but no one wants to pay for it.
Keeping personal opinions aside, Elastic has all the rights what they are doing and from the point of view of an organization, I respect their move.
We always have the last liberally/permissive open-sourced version of it which we can fork and do whatever we want.
Not sure why you were downvoted, but this is exactly correct. "Open Source" doesn't (just) mean "You have access to the source code." It's actually a pretty specific thing.
And before anybody says it - yes, we all know that OSI doesn't have a registered trademark on "Open Source." Doesn't matter. We're talking about a de-facto definition, not de-jure. And among people who actually care about the definition of "Open Source" the OSD is the de-facto definition.
The parent is the author (but not the submitter) and is pointing to the definition that has complete concensus outside of fringe opinions (which still maybe correct: "fringe" is descriptive, not a judgement). How this comment can be downvoted is beyond me as the author's definition is surely relevant to discussion of this article.
Yes, but only for ElasticSearch as a service so having ElasticSearch on your backend won't generally require the distribution of the linked source code.
So there is a distinction between running a ElasticSearch engine with custom changes in your backend and offering a ElasticSearch engine with custom changes to others as a backend?
For a non-lawyer that seems very sketchy... I could understand that people would need some legal advice for that, to understand this stuff in detail...
The new SSPL license requires them to open source a lot more, including user interfaces, backup mechanisms, and anything else necessary to offer the service
Call it whatever you like, but it's not "pragmatic FOSS", it's not "FOSS" at all. It is neither free (by the FSF's definition, which goes back to at least 1986), nor open source (by the definition first published in 1998, derived from the DFSG published in 1997).
> for the real world
The "real world" in which Elastic's revenues, as the article points out, were $427 million last year. And please don't use this cheap rhetorical trick wherein anyone with different priorities must get back to the "real world" (defined loosely as "whatever I say it is").
Source? I don't remember the url, but the other day someone posted a link to an opinion posted by someone at OSI back when Elastic was thinking of getting certification that basically said: "This licence would probably satisify the OSI defintion, but it's a bad license because it's too vague and you should use the AGPL-3 instead".
I have not read the opinion you refer to, but Elastic themselves admit "it is not an OSI approved license and is not considered open source".[0]
> but it's a bad license because it's too vague
That has historically[1] been a reason for the free & open source communities to reject licenses; nobody wants cavernous uncertainties about what you can and cannot do under a license's terms.
Some years ago, I chose Elasticsearch for the main search engine at one of my previous jobs. Hoping to support open source, I avoided Amazon's offering and paid for hosting from Elastic, telling management that not only would it support the company that created the software, but also would put us in contact with engineers that knew the product extremely well. I even went to Elasticon!
It worked really well, but as our query rate increased, our queries' geographic component, which we would search using Elastic's geohashing, created high CPU usage on our cluster. We soon learned the CPU demands for each query were significantly higher compared to more traditional full-text search queries.
Elastic simply had no way to allow us to optimize for CPU heavy workloads in their hosted product. We talked with their product team and engineers, and they were good, and promised they were working on it, but ultimately my team needed to move to a hosted solution that offered better instance selection so we could optimize for our particular workload while keeping costs under control. So, we moved to AWS. This required navigating some weirdness with request signing, but overall worked great.
While I'm sure the hosting issues have since been addressed, this lesson taught me that the licensing of the software impacts my ability as an engineer to find alternative hosts with a variety of hosting and pricing models, and this move to a more restrictive license will likely add friction for those providers that will reduce the number of companies that will offer hosted Elasticsearch. I think this is a material practical concern.
It does leave an open question about how to fund open source, which is also a practical concern. It's probably another discussion, but I have a hunch that rather than forcing third-parties to open source their hosting stack, it makes more sense for the open-source business to make their hosting stack proprietary (Elastic's already is, IIRC), and provide an awesome developer experience with the hosted product, so hosting providers can compete on the SaaS experience and share the underlying open-source product. Just a hunch, though.
If I fork the commit before license change, rename everything to not clash with trademarks, can I then pick commits from their repo into my still-Apache licensed forks?
EDIT: Can I use SSPL licensed software in my commercial server-side application for free?
Nope, but he is a well known Open Source developer and he is good with words.
To give the story a bit more context, I always felt that Elastic built on Lucene without giving much back.
And, while Lucene is not the standard for clarity itself, the open source code of Elastic is very hard to understand and it has very few comments, AFAIR. It did not feel like the core team was proudly sharing.
>To give the story a bit more context, I always felt that Elastic built on Lucene without giving much back.
I would love to understand why you have this perspective? Investing in and contributing to Lucene is a core part of the Elasticsearch team. We contribute more to Lucene than any other organization, some of our employees are amongst the top committers, and several of our employees are members of the Lucene PMC. We give back to and [celebrate][0] Lucene openly. We love Lucene.
Disclaimer: I am an engineer on the Elasticsearch team; I welcome any and all feedback.
Elastic's changing their license. No contributions are being stripped of their open source license. You always have the last open source licensed version to go back to and fork if you like.
What this author is upset about is that Elastic are no longer providing updates under a license the author feels they are entitled to.
Maybe the author should fork the project and maintain it under an open license themselves?