27 ms·

Licensing changes to Elasticsearch and Kibana

298 points by sl_ 6y ago

nopzor 6y ago
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. it's become the new normal. interesting times.
- npiit 6y ago
  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.
  - nopzor 6y ago
    at grafana labs, we are still pretty torn on what our go forward licensing regime should be. bsl is interesting, but license proliferation and familiarity is a big factor to consider. now that both elastic and mongo are both using sspl, it is more appealing. i think tsl from timescale is also a great and well thought out license.
    - dhd415 6y ago
      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.
      - nopzor 6y ago
        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. it's definitely a nuanced discussion internally.
    - npiit 6y ago
      I like Grafana and I wish you the best. Source-available to me is basically FOSS unless I want a free ride off your hard work.
- LukeEF 6y ago
  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.
  - dhd415 6y ago
    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 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.
    - DetroitThrow 6y ago
      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?!
  - mfreed 6y ago
    Thanks for the clarification, Luke. For a bit more background for the HN community: 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! https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines...
- yjftsjthsd-h 6y ago
  > 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".
  - nopzor 6y ago
    do you feel that the sspl is ambiguous on this point? if so, why?
    - yjftsjthsd-h 6y ago
      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.
- ecnahc515 6y ago
  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.
- valyala 6y ago
  > at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. It would be great to see a list of pros and cons for approaches taken by ElasticSearch, MongoDB, TimescaleDB regarding licensing. BTW, we at VictoriaMetrics do not plan to change license for published source code. All the VictoriaMetrics source code is published under Apache 2.0 license [1]. [1] https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/LICENSE https://github.com/VictoriaMetrics/VictoriaMetrics/blob/mast...
Pet_Ant 6y ago
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.
- ocdtrekkie 6y ago
  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.
- nopzor 6y ago
  i agree with your point on license proliferation. the osi has failed, in my opinion, for not approving sspl or something similar. i respect them a lot less for it than i used to. sspl does not technically impose any restrictions on any class of users; it’s just an extreme copy left license. instead, osi spent a time arguing about mongo business model, technical capabilities, and sales tactics. mongo eventually pulled their application to osi because (i think) they were so turned off by the process and politics.
  - z77dj3kl 6y ago
    SSPL is hostile and vague from the get go, you're making it sound like MongoDB were the righteous ones here.
- RcouF1uZ4gsC 6y ago
  > 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.
a_imho 6y ago
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?
- chrisan 6y ago
  an updated version of firefox loads fast without issue
  - a_imho 6y ago
    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.
- yjftsjthsd-h 6y ago
  That's not even an ESR version - forget pages breaking, running Firefox 61 in 2021 is a security nightmare.
arpinum 6y ago
"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."
- nopzor 6y ago
  contributing back can mean monetarily. i’m sure elastic would be willing to sell a commercial license to a cloud provider if the deal makes sense.
  - brasetvik 6y ago
    They already do. https://www.elastic.co/about/press/elastic-partners-with-alibaba-cloud-to-deliver-elasticsearch-on-alibaba-cloud https://www.elastic.co/about/press/elastic-partners-with-ali...
  - arpinum 6y ago
    Thats fine, but then don't title the blog post "Doubling down on open", make it "Creating a more profitable business model".
    - christophilus 6y ago
      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.
- shawnz 6y ago
  Elasticsearch couldn't exist without the open source Lucene project which is at its core. Lucene is licensed under the permissive Apache license which is why Elastic is able to release proprietary paid modules that link with it. Now they are closing the same holes that they themselves used to create their product. Contributing back is definitely the last thing on their minds.
LittlePeter 6y ago
What does it mean for Elasticsearch Service on AWS?
- dhd415 6y ago
  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.
  - darkwater 6y ago
    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. Edit: fixed typo
    - dhd415 6y ago
      I can't imagine they'd want their competitors to see any of the internals of their control plane or other internal infrastructure.
    - hbogert 6y ago
      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? The license is plain vague.
      - whoknew1122 6y ago
        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. And it's ES that's forcing AWS to do this.
      - darkwater 6y ago
fiberoptick 6y ago
I wonder where this leaves the AWS-sponsored Open Distro for Elasticsearch? (https://opendistro.github.io/for-elasticsearch/ https://opendistro.github.io/for-elasticsearch/) Seems to me that they have no choice but to hard fork off of the last Apache-licensed release of Elasticsearch et al
- binarymax 6y ago
  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.
  - nopzor 6y ago
    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.
    - CSDude 6y ago
      AWS ES has major problems, have been a pain us for years. Pretty sure they cannot be competitive with a hard fork
      - jamesblonde 6y ago
        My guess, from AWS experience, is that you're right. What specific pain points did you experience?
        CSDude 6y ago
        Other services are great. Aws es is just put together. It goes down, blue green updates take forever, arbitrary disk limits etc.
LukeEF 6y ago
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.
- LukeEF 6y ago
  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!
  - victor106 6y ago
    This. 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
    - tus88 6y ago
      It's not open source though.
      - Drdrdrq 6y ago
        Yes, it is not. But who cares? What I care about as a user is repairability: * can I inspect source and build it myself? * can I fix it? * can I share modifications with others? Many of the new "cloud protection licenses" offer this, yet they are (by definition) not opensource.
nkw 6y ago
So how is Elastic going to fare if Lucene makes a similar switch?
- craigching 6y ago
  Elastic is one of, if not the largest, contributor to Lucene anyway.
- robcowart 6y ago
  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.
  - PeterZaitsev 6y ago
    What you're really saying is you should have more trust to foundation governed Open Source because it is less likely it will change a license
    - robcowart 6y ago
      "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.
sciurus 6y ago
Here's the actual change: > 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.
- sytse 6y ago
  SSPL is based on the GNU AFFERO GENERAL PUBLIC LICENSE https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf https://webassets.mongodb.com/_com_assets/legal/SSPL-compare... 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-source_software_licences#General_comparison https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...
  - worldsayshi 6y ago
    What will this entail for when you're building Elastic Plugins?
    - deleted 6y ago
      [deleted]
    - brasetvik 6y ago
      > 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. - https://www.elastic.co/pricing/faq/licensing#im-building-plugins-for-elasticsearch-or-kibana-how-does-this-change-affect-me https://www.elastic.co/pricing/faq/licensing#im-building-plu...
davexunit 6y ago
"The list of improvements under this new free and open, yet proprietary, license, is overwhelming." "Free" and "open" have established definitions in the software space, neither of which mean "proprietary." This is just open-washing nonsense.
xvilka 6y ago
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. [1] https://github.com/toshi-search/Toshi https://github.com/toshi-search/Toshi [2] https://github.com/meilisearch/MeiliSearch https://github.com/meilisearch/MeiliSearch [3] https://github.com/valeriansaliou/sonic https://github.com/valeriansaliou/sonic
- jabo 6y ago
  Adding Typesense to the list as an easier-to-use alternative to ElasticSearch: https://github.com/typesense/typesense https://github.com/typesense/typesense 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.
  - craigching 6y ago
    Exactly, the logs use case is what we use Elasticsearch for.
  - z77dj3kl 6y ago
    Do you really have to spam your project on every thread even remotely related?
    - akshaykumar90 6y ago
      If it is even remotely related, it is not spam.
- postalrat 6y ago
  I didn't realize rust and the jvm solve the same problem.
  - 6y ago
andr 6y ago
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. [0] https://fs.blog/knowledge-project/matt-mullenweg/ https://fs.blog/knowledge-project/matt-mullenweg/
- softwaredoug 6y ago
  Is this because the Wordpress market is huge (almost every website)? Whereas Elastic, Mongo, etc market share is not as huge?
  - __blockcipher__ 6y ago
    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.
- wmf 6y ago
  That's great for Matt, but other companies like Elastic can't afford to go from >50% to 5% of their market.
  - __blockcipher__ 6y ago
    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
    - wmf 6y ago
      People will just switch to OpenDistro.
    - jaymee 6y ago
lovelearning 6y ago
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.
- catern 6y ago
  Such businesses can continue providing their service, they just have to provide the code to their users.
  - Bedon292 6y ago
    Publicly release, not just to their users.
    - catern 6y ago
      Technically, they only have to provide it to their users, but they have to give their users the freedom to redistribute it. But yes that's effectively publicly releasing it.
PeterZaitsev 6y ago
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
- manishsharan 6y ago
  Lets have a round of applause for the Lucene contibutors !
- j1elo 6y ago
  I raised precisely this concern a week ago: https://news.ycombinator.com/item?id=25631073 https://news.ycombinator.com/item?id=25631073 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.
  - __blockcipher__ 6y ago
    > 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.
- 6y ago
ForHackernews 6y ago
Sounds good to me. This is clearly targeted at big cloud providers who have been free-riding for years on the work of open source projects.
- __blockcipher__ 6y ago
  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.
  - ForHackernews 6y ago
    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.
bevacqua 6y ago
Where does Elastic claim SSPL is open source?
- rektide 6y ago
  "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. your doubt is unbecoming, bevacqua.
- teraflop 6y ago
  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.)
  - fabianhjr 6y ago
    > denoting software for which the original source code is made freely available and may be redistributed and modified. ~ Oxford Or the Open Source Definition from https://opensource.org/osd https://opensource.org/osd 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. Here is Google rejection of APGL on this basis: https://opensource.google/docs/using/agpl-policy/ https://opensource.google/docs/using/agpl-policy/
Areading314 6y ago
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. Edit: Not a lawyer!
- alexfromapex 6y ago
  I think these are relevant from the Elastic blog post: - no impact on the overwhelming majority of our user community - no impact on our cloud customers or self-managed software customers Also, this helped calm my nerves: https://www.elastic.co/pricing/faq/licensing https://www.elastic.co/pricing/faq/licensing
  - CSDude 6y ago
    They are dangerously vague. Is AWS at concern or the log as a service providers? Are you willing to take that risk?
- ajsharp 6y ago
  Appreciate the clarification.
- Nican 6y ago
  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.
  - edoceo 6y ago
    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.
CSDude 6y ago
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?
- cduzz 6y ago
  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?
  - dhd415 6y ago
    None. That's clearly not offering Elasticsearch-as-a-service.
    - hbogert 6y ago
      how is that clearly? What if your UI over time provides the mechanisms which are isomorphic to the functionality provided by ES? This will be a nightmare if ever tried in court.
- EwanToo 6y ago
  This is the crux of the problem. If you're purely processing internal logs on an internal service, you're probably good. If you're exposing an API or a UI to paying customers which calls Elastic search to run a query, then it's maybe not great. Everything needs to be caveated with "maybe" or "possibly", because nobody knows how it'd go in court.
artembugara 6y ago
It's just a change to make sure that those who resell ES as a service share their code. We use AWS's ES. And, as far as I'm concerned they already open-source their version. SSPL is actually helping the open-source community here
- jameshilliard 6y ago
  > 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.
- tus88 6y ago
  > their code Meaning the entire codebase of the infrastucture that provides the offering. I.e. the underlying code behind AWS. Not a big deal right?
- mcintyre1994 6y ago
  From the link: > 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.
  - jameshilliard 6y ago
    > they have a massive amount of closed source stuff running behind their ES service GPL licenses are not SSPL compatible, so it would likely still be impossible to comply even if their ES service was entirely open source.
- ignoramous 6y ago
  SSPL isn't an open source license: https://hub.packtpub.com/mongodb-withdraws-controversial-server-side-public-license-from-the-open-source-initiatives-approval-process/ https://hub.packtpub.com/mongodb-withdraws-controversial-ser... ...and it isn't helping anyone (other than the licensor) let alone the F/OSS community: https://news.ycombinator.com/item?id=18301116 https://news.ycombinator.com/item?id=18301116 MPLv2, EPLv2, xGPLv3 are strictly libre even if not as wildly copyleft as SSPL.
soheil 6y ago
> It can remain on version 7.10, but then it will no longer receive future updates Does this mean anyone using version 7.10 or lower is not bound by SSPL license and Apache2 still applies?
- l3s2d 6y ago
  I think this is true in general. Any code that is made available an open source license is available under that license in perpetuity.
- Xylakant 6y ago
  Yes. Any version released under a given license remains under that license, it cannot be retroactively changed.
draw_down 6y ago
Just because cloud services make it basically impossible to get resources for your project doesn't mean you're allowed to actually do something about it. Apparently.
JarlUlvi 6y ago
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/ 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
- mrkstu 6y ago
  Which makes it sounds like AWS wasn't competing very well in the space, if it couldn't do so affordably.
- _msw_ 6y ago
  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: https://github.com/elastic/elasticsearch/pull/61400 https://github.com/elastic/elasticsearch/pull/61400 https://github.com/elastic/elasticsearch/pull/59563 https://github.com/elastic/elasticsearch/pull/59563 https://github.com/elastic/elasticsearch/pull/57271 https://github.com/elastic/elasticsearch/pull/57271 https://github.com/elastic/elasticsearch/pull/53643 https://github.com/elastic/elasticsearch/pull/53643
pietrovismara 6y ago
Honestly, every relevant FOSS project should adopt a similar license to prevent exploitation from corporations.
- davexunit 6y ago
  They would no longer be FOSS if they did that.
  - pietrovismara 6y ago
    In practice it would only affect corporate thieves, so I think it's actually necessary to protect the open source ecosystem.
    - __blockcipher__ 6y ago
      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...
      - cthor 6y ago
        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. [1]: https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up.html#bounty https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up.h...
        __blockcipher__ 6y ago
tus88 6y ago
I wonder what will happen to the AWS ElasticSearch offering.
kam 6y ago
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".
- lacker 6y ago
  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.
  - ahachete 6y ago
    So there's no big cloud offering MySQL-as-a-Service, right? And nobody uses Linux for their *-as-a-Service offering, no?
  - slaymaker1907 6y ago
    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.
- choeger 6y ago
  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.
ahachete 6y ago
> 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"?
- confiq 6y ago
  I assume if you run ES in your own datacenter or you use SaaS, you will be fine! I guess they target AWS but not AWS users...
  - ahachete 6y ago
    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. And you're not AWS in either them.
    - confiq 6y ago
      I'm not sure that if I use ES in my datacenter I would be effected as long as it's internal tool for analysing data. I'm not lawyer but this is what I understand from their statement.
lacker 6y ago
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.
- jethro_tell 6y ago
  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.
- paxys 6y ago
  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.
opsunit 6y ago
It is interesting to note that elastic.co is hosted on Google Cloud: https://runson.cloud/search/elastic.co https://runson.cloud/search/elastic.co
VoxPelli 6y ago
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? Good post on BSL: https://perens.com/2017/02/14/bsl-1-1/ https://perens.com/2017/02/14/bsl-1-1/
- remram 6y ago
  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.
  - VoxPelli 6y ago
    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?
    - remram 6y ago
      I see. It's a really wide range of licenses then.
- VoxPelli 6y ago
  Also, note that Google prohibits all use of SSPL just like it prohibits use of AGPL: https://opensource.google/docs/thirdparty/licenses/#agpl-affero-gpl-and-sspl-not-allowed https://opensource.google/docs/thirdparty/licenses/#agpl-aff... 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.
z77dj3kl 6y ago
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!
deleted 6y ago
[deleted]
blacklight 6y ago
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.
lazyant 6y ago
Am I interpreting this correctly that on and after v7.11 users won't be able to use Amazon Elasticsearch Service (unless AWS contributes back)?
- paxys 6y ago
  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.
metreo 6y ago
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.
Keyframe 6y ago
How's Solr these days, guys? Any drop-in replacement, especially the query language?
jrochkind1 6y ago
> 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?
- erezsh 6y ago
  I can answer that. 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.
  - jrochkind1 6y ago
    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.org/philosophy/programs-must-not-limit-freedom-to-run.html https://web.archive.org/web/20130509151342/https://www.gnu.o...)
luord 6y ago
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.
thayne 6y ago
> 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.
- thayne 6y ago
  I think the licensing change is more likely to fracture the community than a third party distribution.
Illniyar 6y ago
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.
- philtar 6y ago
  Then oracle will change it to whatever license they want regardless of what the original license was.
  - CameronNemo 6y ago
    Elastic does require a CLA.
ddevault 6y ago
What a spit in the face to anyone who contributed to Elastic's codebase. This is an Oracle-grade move.
poobears 6y ago
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.
monkeybonkers 6y ago
Well at least their CEO will be OK https://finance.yahoo.com/news/elastic-nv-estc-ceo-chairman-001503382.html https://finance.yahoo.com/news/elastic-nv-estc-ceo-chairman-...
chikens 6y ago
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.
yannovitch 6y ago
Some food for thoughts : - https://drewdevault.com/2021/01/19/Elasticsearch-does-not-belong-to-Elastic.html https://drewdevault.com/2021/01/19/Elasticsearch-does-not-be... - http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts-its-midlife-crisis/ http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...

298 points by sl_ 6y ago

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. it's become the new normal. interesting times.

npiit 6y ago
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.
- nopzor 6y ago
  at grafana labs, we are still pretty torn on what our go forward licensing regime should be. bsl is interesting, but license proliferation and familiarity is a big factor to consider. now that both elastic and mongo are both using sspl, it is more appealing. i think tsl from timescale is also a great and well thought out license.
  - dhd415 6y ago
    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.
    - nopzor 6y ago
      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. it's definitely a nuanced discussion internally.
  - npiit 6y ago
    I like Grafana and I wish you the best. Source-available to me is basically FOSS unless I want a free ride off your hard work.
LukeEF 6y ago
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.
- dhd415 6y ago
  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 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.
  - DetroitThrow 6y ago
    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?!
- mfreed 6y ago
  Thanks for the clarification, Luke. For a bit more background for the HN community: 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! https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines...
yjftsjthsd-h 6y ago
> 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".
- nopzor 6y ago
  do you feel that the sspl is ambiguous on this point? if so, why?
  - yjftsjthsd-h 6y ago
    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.
ecnahc515 6y ago
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.
valyala 6y ago
> at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. It would be great to see a list of pros and cons for approaches taken by ElasticSearch, MongoDB, TimescaleDB regarding licensing. BTW, we at VictoriaMetrics do not plan to change license for published source code. All the VictoriaMetrics source code is published under Apache 2.0 license [1]. [1] https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/LICENSE https://github.com/VictoriaMetrics/VictoriaMetrics/blob/mast...

Pet_Ant 6y ago

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.

ocdtrekkie 6y ago
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.
nopzor 6y ago
i agree with your point on license proliferation. the osi has failed, in my opinion, for not approving sspl or something similar. i respect them a lot less for it than i used to. sspl does not technically impose any restrictions on any class of users; it’s just an extreme copy left license. instead, osi spent a time arguing about mongo business model, technical capabilities, and sales tactics. mongo eventually pulled their application to osi because (i think) they were so turned off by the process and politics.
- z77dj3kl 6y ago
  SSPL is hostile and vague from the get go, you're making it sound like MongoDB were the righteous ones here.
RcouF1uZ4gsC 6y ago
> 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.

a_imho 6y ago

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?

chrisan 6y ago
an updated version of firefox loads fast without issue
- a_imho 6y ago
  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.
yjftsjthsd-h 6y ago
That's not even an ESR version - forget pages breaking, running Firefox 61 in 2021 is a security nightmare.

arpinum 6y ago

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

nopzor 6y ago
contributing back can mean monetarily. i’m sure elastic would be willing to sell a commercial license to a cloud provider if the deal makes sense.
- brasetvik 6y ago
  They already do. https://www.elastic.co/about/press/elastic-partners-with-alibaba-cloud-to-deliver-elasticsearch-on-alibaba-cloud https://www.elastic.co/about/press/elastic-partners-with-ali...
- arpinum 6y ago
  Thats fine, but then don't title the blog post "Doubling down on open", make it "Creating a more profitable business model".
  - christophilus 6y ago
    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.
shawnz 6y ago
Elasticsearch couldn't exist without the open source Lucene project which is at its core. Lucene is licensed under the permissive Apache license which is why Elastic is able to release proprietary paid modules that link with it. Now they are closing the same holes that they themselves used to create their product. Contributing back is definitely the last thing on their minds.

LittlePeter 6y ago

What does it mean for Elasticsearch Service on AWS?

dhd415 6y ago
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.
- darkwater 6y ago
  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. Edit: fixed typo
  - dhd415 6y ago
    I can't imagine they'd want their competitors to see any of the internals of their control plane or other internal infrastructure.
  - hbogert 6y ago
    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? The license is plain vague.
    - whoknew1122 6y ago
      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. And it's ES that's forcing AWS to do this.
    - darkwater 6y ago

fiberoptick 6y ago

I wonder where this leaves the AWS-sponsored Open Distro for Elasticsearch? (https://opendistro.github.io/for-elasticsearch/ https://opendistro.github.io/for-elasticsearch/) Seems to me that they have no choice but to hard fork off of the last Apache-licensed release of Elasticsearch et al

binarymax 6y ago
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.
- nopzor 6y ago
  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.
  - CSDude 6y ago
    AWS ES has major problems, have been a pain us for years. Pretty sure they cannot be competitive with a hard fork
    - jamesblonde 6y ago
      My guess, from AWS experience, is that you're right. What specific pain points did you experience?
      - CSDude 6y ago
        Other services are great. Aws es is just put together. It goes down, blue green updates take forever, arbitrary disk limits etc.

LukeEF 6y ago

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.

LukeEF 6y ago
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!
- victor106 6y ago
  This. 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
  - tus88 6y ago
    It's not open source though.
    - Drdrdrq 6y ago
      Yes, it is not. But who cares? What I care about as a user is repairability: * can I inspect source and build it myself? * can I fix it? * can I share modifications with others? Many of the new "cloud protection licenses" offer this, yet they are (by definition) not opensource.

nkw 6y ago

So how is Elastic going to fare if Lucene makes a similar switch?

craigching 6y ago
Elastic is one of, if not the largest, contributor to Lucene anyway.
robcowart 6y ago
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.
- PeterZaitsev 6y ago
  What you're really saying is you should have more trust to foundation governed Open Source because it is less likely it will change a license
  - robcowart 6y ago
    "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.

sciurus 6y ago

Here's the actual change: > 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.

sytse 6y ago
SSPL is based on the GNU AFFERO GENERAL PUBLIC LICENSE https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf https://webassets.mongodb.com/_com_assets/legal/SSPL-compare... 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-source_software_licences#General_comparison https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so...
- worldsayshi 6y ago
  What will this entail for when you're building Elastic Plugins?
  - deleted 6y ago
    [deleted]
  - brasetvik 6y ago
    > 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. - https://www.elastic.co/pricing/faq/licensing#im-building-plugins-for-elasticsearch-or-kibana-how-does-this-change-affect-me https://www.elastic.co/pricing/faq/licensing#im-building-plu...

davexunit 6y ago

"The list of improvements under this new free and open, yet proprietary, license, is overwhelming." "Free" and "open" have established definitions in the software space, neither of which mean "proprietary." This is just open-washing nonsense.

xvilka 6y ago

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. [1] https://github.com/toshi-search/Toshi https://github.com/toshi-search/Toshi [2] https://github.com/meilisearch/MeiliSearch https://github.com/meilisearch/MeiliSearch [3] https://github.com/valeriansaliou/sonic https://github.com/valeriansaliou/sonic

jabo 6y ago
Adding Typesense to the list as an easier-to-use alternative to ElasticSearch: https://github.com/typesense/typesense https://github.com/typesense/typesense 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.
- craigching 6y ago
  Exactly, the logs use case is what we use Elasticsearch for.
- z77dj3kl 6y ago
  Do you really have to spam your project on every thread even remotely related?
  - akshaykumar90 6y ago
    If it is even remotely related, it is not spam.
postalrat 6y ago
I didn't realize rust and the jvm solve the same problem.
- 6y ago

andr 6y ago

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. [0] https://fs.blog/knowledge-project/matt-mullenweg/ https://fs.blog/knowledge-project/matt-mullenweg/

softwaredoug 6y ago
Is this because the Wordpress market is huge (almost every website)? Whereas Elastic, Mongo, etc market share is not as huge?
- __blockcipher__ 6y ago
  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.
wmf 6y ago
That's great for Matt, but other companies like Elastic can't afford to go from >50% to 5% of their market.
- __blockcipher__ 6y ago
  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
  - wmf 6y ago
    People will just switch to OpenDistro.
  - jaymee 6y ago

lovelearning 6y ago

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.

catern 6y ago
Such businesses can continue providing their service, they just have to provide the code to their users.
- Bedon292 6y ago
  Publicly release, not just to their users.
  - catern 6y ago
    Technically, they only have to provide it to their users, but they have to give their users the freedom to redistribute it. But yes that's effectively publicly releasing it.

PeterZaitsev 6y ago

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

manishsharan 6y ago
Lets have a round of applause for the Lucene contibutors !
j1elo 6y ago
I raised precisely this concern a week ago: https://news.ycombinator.com/item?id=25631073 https://news.ycombinator.com/item?id=25631073 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.
- __blockcipher__ 6y ago
  > 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.
6y ago

ForHackernews 6y ago

Sounds good to me. This is clearly targeted at big cloud providers who have been free-riding for years on the work of open source projects.

__blockcipher__ 6y ago
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.
- ForHackernews 6y ago
  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.

bevacqua 6y ago

Where does Elastic claim SSPL is open source?

rektide 6y ago
"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. your doubt is unbecoming, bevacqua.
teraflop 6y ago
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.)
- fabianhjr 6y ago
  > denoting software for which the original source code is made freely available and may be redistributed and modified. ~ Oxford Or the Open Source Definition from https://opensource.org/osd https://opensource.org/osd 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. Here is Google rejection of APGL on this basis: https://opensource.google/docs/using/agpl-policy/ https://opensource.google/docs/using/agpl-policy/

Areading314 6y ago

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. Edit: Not a lawyer!

alexfromapex 6y ago
I think these are relevant from the Elastic blog post: - no impact on the overwhelming majority of our user community - no impact on our cloud customers or self-managed software customers Also, this helped calm my nerves: https://www.elastic.co/pricing/faq/licensing https://www.elastic.co/pricing/faq/licensing
- CSDude 6y ago
  They are dangerously vague. Is AWS at concern or the log as a service providers? Are you willing to take that risk?
ajsharp 6y ago
Appreciate the clarification.
Nican 6y ago
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.
- edoceo 6y ago
  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.

CSDude 6y ago

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?

cduzz 6y ago
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?
- dhd415 6y ago
  None. That's clearly not offering Elasticsearch-as-a-service.
  - hbogert 6y ago
    how is that clearly? What if your UI over time provides the mechanisms which are isomorphic to the functionality provided by ES? This will be a nightmare if ever tried in court.
EwanToo 6y ago
This is the crux of the problem. If you're purely processing internal logs on an internal service, you're probably good. If you're exposing an API or a UI to paying customers which calls Elastic search to run a query, then it's maybe not great. Everything needs to be caveated with "maybe" or "possibly", because nobody knows how it'd go in court.

artembugara 6y ago

It's just a change to make sure that those who resell ES as a service share their code. We use AWS's ES. And, as far as I'm concerned they already open-source their version. SSPL is actually helping the open-source community here

jameshilliard 6y ago
> 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.
tus88 6y ago
> their code Meaning the entire codebase of the infrastucture that provides the offering. I.e. the underlying code behind AWS. Not a big deal right?
mcintyre1994 6y ago
From the link: > 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.
- jameshilliard 6y ago
  > they have a massive amount of closed source stuff running behind their ES service GPL licenses are not SSPL compatible, so it would likely still be impossible to comply even if their ES service was entirely open source.
ignoramous 6y ago
SSPL isn't an open source license: https://hub.packtpub.com/mongodb-withdraws-controversial-server-side-public-license-from-the-open-source-initiatives-approval-process/ https://hub.packtpub.com/mongodb-withdraws-controversial-ser... ...and it isn't helping anyone (other than the licensor) let alone the F/OSS community: https://news.ycombinator.com/item?id=18301116 https://news.ycombinator.com/item?id=18301116 MPLv2, EPLv2, xGPLv3 are strictly libre even if not as wildly copyleft as SSPL.

soheil 6y ago

> It can remain on version 7.10, but then it will no longer receive future updates Does this mean anyone using version 7.10 or lower is not bound by SSPL license and Apache2 still applies?

l3s2d 6y ago
I think this is true in general. Any code that is made available an open source license is available under that license in perpetuity.
Xylakant 6y ago
Yes. Any version released under a given license remains under that license, it cannot be retroactively changed.

draw_down 6y ago

Just because cloud services make it basically impossible to get resources for your project doesn't mean you're allowed to actually do something about it. Apparently.

JarlUlvi 6y ago

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

mrkstu 6y ago
Which makes it sounds like AWS wasn't competing very well in the space, if it couldn't do so affordably.
_msw_ 6y ago
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: https://github.com/elastic/elasticsearch/pull/61400 https://github.com/elastic/elasticsearch/pull/61400 https://github.com/elastic/elasticsearch/pull/59563 https://github.com/elastic/elasticsearch/pull/59563 https://github.com/elastic/elasticsearch/pull/57271 https://github.com/elastic/elasticsearch/pull/57271 https://github.com/elastic/elasticsearch/pull/53643 https://github.com/elastic/elasticsearch/pull/53643

pietrovismara 6y ago

Honestly, every relevant FOSS project should adopt a similar license to prevent exploitation from corporations.

davexunit 6y ago
They would no longer be FOSS if they did that.
- pietrovismara 6y ago
  In practice it would only affect corporate thieves, so I think it's actually necessary to protect the open source ecosystem.
  - __blockcipher__ 6y ago
    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...
    - cthor 6y ago
      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. [1]: https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up.html#bounty https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up.h...
      - __blockcipher__ 6y ago

tus88 6y ago

I wonder what will happen to the AWS ElasticSearch offering.

kam 6y ago

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

lacker 6y ago
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.
- ahachete 6y ago
  So there's no big cloud offering MySQL-as-a-Service, right? And nobody uses Linux for their *-as-a-Service offering, no?
- slaymaker1907 6y ago
  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.
choeger 6y ago
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.

ahachete 6y ago

> 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"?

confiq 6y ago
I assume if you run ES in your own datacenter or you use SaaS, you will be fine! I guess they target AWS but not AWS users...
- ahachete 6y ago
  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. And you're not AWS in either them.
  - confiq 6y ago
    I'm not sure that if I use ES in my datacenter I would be effected as long as it's internal tool for analysing data. I'm not lawyer but this is what I understand from their statement.

lacker 6y ago

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.

jethro_tell 6y ago
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.
paxys 6y ago
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.

opsunit 6y ago

It is interesting to note that elastic.co is hosted on Google Cloud: https://runson.cloud/search/elastic.co https://runson.cloud/search/elastic.co

VoxPelli 6y ago

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? Good post on BSL: https://perens.com/2017/02/14/bsl-1-1/ https://perens.com/2017/02/14/bsl-1-1/

remram 6y ago
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.
- VoxPelli 6y ago
  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?
  - remram 6y ago
    I see. It's a really wide range of licenses then.
VoxPelli 6y ago
Also, note that Google prohibits all use of SSPL just like it prohibits use of AGPL: https://opensource.google/docs/thirdparty/licenses/#agpl-affero-gpl-and-sspl-not-allowed https://opensource.google/docs/thirdparty/licenses/#agpl-aff... 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.

z77dj3kl 6y ago

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!

deleted 6y ago

[deleted]

blacklight 6y ago

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.

lazyant 6y ago

Am I interpreting this correctly that on and after v7.11 users won't be able to use Amazon Elasticsearch Service (unless AWS contributes back)?

paxys 6y ago
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.

metreo 6y ago

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.

Keyframe 6y ago

How's Solr these days, guys? Any drop-in replacement, especially the query language?

jrochkind1 6y ago

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

erezsh 6y ago
I can answer that. 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.
- jrochkind1 6y ago
  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.org/philosophy/programs-must-not-limit-freedom-to-run.html https://web.archive.org/web/20130509151342/https://www.gnu.o...)

luord 6y ago

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.

thayne 6y ago

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

thayne 6y ago
I think the licensing change is more likely to fracture the community than a third party distribution.

Illniyar 6y ago

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.

philtar 6y ago
Then oracle will change it to whatever license they want regardless of what the original license was.
- CameronNemo 6y ago
  Elastic does require a CLA.

ddevault 6y ago

What a spit in the face to anyone who contributed to Elastic's codebase. This is an Oracle-grade move.

poobears 6y ago

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.

monkeybonkers 6y ago

Well at least their CEO will be OK https://finance.yahoo.com/news/elastic-nv-estc-ceo-chairman-001503382.html https://finance.yahoo.com/news/elastic-nv-estc-ceo-chairman-...

chikens 6y ago

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.

yannovitch 6y ago

Some food for thoughts : - https://drewdevault.com/2021/01/19/Elasticsearch-does-not-belong-to-Elastic.html https://drewdevault.com/2021/01/19/Elasticsearch-does-not-be... - http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts-its-midlife-crisis/ http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...