9 ms·

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

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.
  - latortuga 6y ago
    Even worse, Elasticsearch is a great product for adding "search" to your webapp. I don't see how integrating it doesn't run afoul of: Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network...
    - treis 6y ago
      I'm not sure if people are really confused about this or sowing FUD. Using Elasticsearch to search your own webapp is not providing Elasticsearch as a service. It's using Elasticsearch to provide functionality in your application. Providing Elasticsearch as a service means allowing people to upload their own data and giving them an Elasticsearch instance to search it. There's some grey area where it's a question if you're providing an application with a search feature or just hosting Elasticsearch. Like if you provide a way to upload logs and then search them that's Elasticsearch as a service. But if you provide an automated upload, is that enough?
      - confiq 6y ago
        I wish it would be explained that way
        slimsag 6y ago
        It can be, they just chose not to (with ulterior motives or not, I cannot say.) For my side project, I am using a dual-licensed MIT/Apache (your choice) but with an exclusion which prohibits companies like AWS from offering it alone as a service. Here's a copy of the (quite human-readable) license: https://gist.github.com/slimsag/2164520b9e249fbae4e08e2bdf6eb09d https://gist.github.com/slimsag/2164520b9e249fbae4e08e2bdf6e...
ignoramous 6y ago
TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. > It’s not a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal. There are those who will point to the FAQ for the SSPL and claim that the license isn’t interpreted in that way because the FAQ says so. Unfortunately, when you agree to a license you are agreeing to the text of that license document and not to a FAQ. If the text of that license document is ambiguous, then so are your rights and responsibilities under that license... This ambiguity puts your organisation at risk. See also: 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...
- Bombthecat 6y ago
  Wait? Would even my devops pipeline fall under it? Or my monitoring? Deployment and management in kubernetes for example?
  - ignoramous 6y ago
    SSPL is a malicious source-available license, if there ever was one: https://news.ycombinator.com/item?id=18301116 https://news.ycombinator.com/item?id=18301116 I reserve special hate for Commons Clause [0] too but SSPL is downright offensive. A reminder that F/OSS works very well for a lot of reasons [1]. The number one of which is if you want to commodize your product's complement [2][3]. Don't be a knob and F/OSS your core product if you plan to make billions or whatever. [0] https://news.ycombinator.com/item?id=17814386 https://news.ycombinator.com/item?id=17814386 [1] http://dtrace.org/blogs/bmc/2004/12/16/the-economics-of-software-redux/ http://dtrace.org/blogs/bmc/2004/12/16/the-economics-of-soft... [2] https://www.gwern.net/Complement https://www.gwern.net/Complement [3] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
dang 6y ago
Re "alarmist headline": the comment was originally posted in reply to https://news.ycombinator.com/item?id=25781695 https://news.ycombinator.com/item?id=25781695, but it's a good subthread so I moved it over when merging the threads.
veselin 6y ago
The author says in the end that the problem is not Amazon. Then links to a post where he suggests that companies maintaining the open source should have "invested the resources to build stronger communities around them. They would have reached out to Amazon, encouraged them to contribute back to the projects, and helped them to do so." Of course, they should "encourage" Amazon not to steal their product and business model. Right.
- matthewmacleod 6y ago
  Of course, they should "encourage" Amazon not to steal their product and business model. Right. It is not possible to steal something from someone who deliberately and freely offers that thing to you.
  - veselin 6y ago
    I highly doubt elastic intended to offer it for free to the cloud providers from the start. They wanted to offer it for free to end users. This is why I expect new products will now start with these more restrictive licenses.
    - matthewmacleod 6y ago
      I highly doubt anybody chooses an explicitly free and open source license without intending to offer their software to users under the terms of that license.
      - __blockcipher__ 6y ago
        And to flip it around, the question isn't whether Elastic envisioned use case X. The whole meaning behind FOSS is that you're explicitly saying "I don't care what your use case is, you're free to use it". So to later turn around and say "hey we never envisioned Amazon et all turning around and selling Elasticsearch as a service" is looking at it backwards. When you release something under Apache 2 (or a similar non-restrictive license) you're intentionally telling people to do what they want with it. Anyway, my thoughts on these kinds of situations is that it usually implies there's some disconnect between how Elastic Co wants to make money versus how they actually are making money. --- There's a related issue of open source maintainers/devs feeling "exploited". Now while having users submitting issues with unfortunate tone/wording that implies that you're obligated as the maintainer to spend your time fixing their issues is frustrating, it's also part of the game. I'm getting really frustrated with the whole "it's not fair that company X is using my free software without contributing back". That's literally what you agreed to have happen when you released under a non-restrictive license! If you want a restrictive license, that's fine, but don't release under Apache 2 or BSD and then turn around and act shocked when people use your free software for free. It is unreasonable to put something out there for free and then suddenly expect money for it. That doesn't mean that companies shouldn't be contributing back to software they rely on - that's a no-brainer as far as I'm concerned - but it does mean that nobody should be surprised when someone does choose to "consume" software without contributing back.
rektide 6y ago
The license is quite long. https://www.mongodb.com/licensing/server-side-public-license https://www.mongodb.com/licensing/server-side-public-license Trying to determine what offering as a service is or implies is a bit difficult. If Discord used it to enable full text search, does they need to release their management layers too? Why or why not? How excited to defend your rationalization/decision to the court are you, if some disagreement arises? The ask, that companies open source their management layer, concerns me because it's unclear in many circumstances what does & doesn't need to go into that box. A management layer is often a rather sprawling piece of software. Trying to disentangle & release the Elastic Search or Kibana management layer from the other management /deployment/control systems could be quite onerous. I do think the intent is not "bad", but it's so hard & murky, there's so much peering into the crystal ball to guess whether, some day in the future, a once "open source" company that may, a decade down the road become aggressive/ligitious (not presently the case!) continues to find your particular use does or not does qualify as offering the product as a service, and does or does not expose you to a long complex obligation.
cheph 6y ago
The problem is, SSPL is heavily based of GPL, using the same concepts, and inheriting similar problems. GPL does not clearly define where the boundaries of a program is, but there is a fair bit of basis in the GPL FAQ and other writings from the FSF that suggesting that in their opinion, if I write a program B, that specifically depends on program A, then program A and B is part of the same program, regardless of whether or not it is linking in terms of C or if it is using it over the network. https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation : What is the difference between an “aggregate” and other kinds of “modified versions”? (#MereAggregation) > By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
- sokoloff 6y ago
  I think it’s more complex than that. If your program B is, as an example, a formatting-in-HTML wrapper around program A (say gnu grep), then you can ship B in binary-only, non-GPL form that calls A, so long as the end user can replace A with a later version or their own patched version of A and B continue to work. (This preserves the freedom of the user with respect to A.) In that case, B specifically depends on A (for filtering functionality), yet is still (likely, IANAL) considered a mere aggregate as I read things.
geofft 6y ago
Isn't it equally true that if they moved to being entirely proprietary but free-of-charge software, or if they had a "all rights reserved but you can look at the source if you want" license, or whatever, there would be no impact on most customers either? If so, why bother leaning into the word "open"? Just call it freeware.
confiq 6y ago
AFAIRemember, RedHat dropped MongoDB because of "controversial SSPL" > So essentially, anyone is free to modify MongoDB. It’s only when you offer MongoDB as a commercial service that the conditions of the SSPL state that you must open source the entire service. 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... Is this a difference like GPLv2 and GPLv3? Does this means that AWS now must open internal service (probably not but I'm trying to be devil advocate)
- baq 6y ago
  more like the difference between GPL and Affero GPL. https://en.wikipedia.org/wiki/Affero_General_Public_License https://en.wikipedia.org/wiki/Affero_General_Public_License
  - confiq 6y ago
    I'm not sure that I can't follow them all :(
    - ignoramous 6y ago
      Long but may be helpful: https://www.oreilly.com/library/view/understanding-open-source/0596005814/ch03.html https://www.oreilly.com/library/view/understanding-open-sour... Not an expert but usually F/OSS licenses are mainly about: - Patent grants (either grants patent-use or doesn't) - Copyleft (should modifications be open sourced. ex: AGPL is the strongest FOSS copyleft, whilst SSPL builds on it to make it even more stronger) - Copyright (owners who are licensing the code) - Warranty and Liability - Terms of use (ex: FOSS licenses don't enforce restrictions on commercial use like CommonsClause does) Ref: https://choosealicense.com/ https://choosealicense.com/
- ignoramous 6y ago
  AWS wouldn't, I presume, touch the 7.11 dual-licensed Elasticsearch release with a ten-foot pole. They would have to hard-fork it here on, or Gold+ partner with Elastic.co to sell Elasticsearch Service under the relatively more permissive Elastic License.
pabs3 6y ago
Hmm, the Apache httpd folks didn't complain when web hosting services around the world started making money offering web hosting using it, without modifying it nor contributing back financially.
sfifs 6y ago
I wonder if non-ElasticCo contributors to Elastic Search who disagree with the SSPL license change can sue to have their contributions removed. Could even be a class action lawsuit if quite a few contributors disagree.
- luord 6y ago
  All their contributions up until this point are still under the Apache license, so they'd have no reason to sue, I think. And anyone is of course free to fork that code and call it something else. Now, it's very likely that many of them will stop contributing for versions 7.11 and up.
  - sfifs 6y ago
    > All their contributions up until this point are still under the Apache license, so they'd have no reason to sue, I think Ah right - makes sense.

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.
- latortuga 6y ago
  Even worse, Elasticsearch is a great product for adding "search" to your webapp. I don't see how integrating it doesn't run afoul of: Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network...
  - treis 6y ago
    I'm not sure if people are really confused about this or sowing FUD. Using Elasticsearch to search your own webapp is not providing Elasticsearch as a service. It's using Elasticsearch to provide functionality in your application. Providing Elasticsearch as a service means allowing people to upload their own data and giving them an Elasticsearch instance to search it. There's some grey area where it's a question if you're providing an application with a search feature or just hosting Elasticsearch. Like if you provide a way to upload logs and then search them that's Elasticsearch as a service. But if you provide an automated upload, is that enough?
    - confiq 6y ago
      I wish it would be explained that way
      - slimsag 6y ago
        It can be, they just chose not to (with ulterior motives or not, I cannot say.) For my side project, I am using a dual-licensed MIT/Apache (your choice) but with an exclusion which prohibits companies like AWS from offering it alone as a service. Here's a copy of the (quite human-readable) license: https://gist.github.com/slimsag/2164520b9e249fbae4e08e2bdf6eb09d https://gist.github.com/slimsag/2164520b9e249fbae4e08e2bdf6e...

ignoramous 6y ago

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. > It’s not a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal. There are those who will point to the FAQ for the SSPL and claim that the license isn’t interpreted in that way because the FAQ says so. Unfortunately, when you agree to a license you are agreeing to the text of that license document and not to a FAQ. If the text of that license document is ambiguous, then so are your rights and responsibilities under that license... This ambiguity puts your organisation at risk. See also: 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...

Bombthecat 6y ago
Wait? Would even my devops pipeline fall under it? Or my monitoring? Deployment and management in kubernetes for example?
- ignoramous 6y ago
  SSPL is a malicious source-available license, if there ever was one: https://news.ycombinator.com/item?id=18301116 https://news.ycombinator.com/item?id=18301116 I reserve special hate for Commons Clause [0] too but SSPL is downright offensive. A reminder that F/OSS works very well for a lot of reasons [1]. The number one of which is if you want to commodize your product's complement [2][3]. Don't be a knob and F/OSS your core product if you plan to make billions or whatever. [0] https://news.ycombinator.com/item?id=17814386 https://news.ycombinator.com/item?id=17814386 [1] http://dtrace.org/blogs/bmc/2004/12/16/the-economics-of-software-redux/ http://dtrace.org/blogs/bmc/2004/12/16/the-economics-of-soft... [2] https://www.gwern.net/Complement https://www.gwern.net/Complement [3] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

dang 6y ago

Re "alarmist headline": the comment was originally posted in reply to https://news.ycombinator.com/item?id=25781695 https://news.ycombinator.com/item?id=25781695, but it's a good subthread so I moved it over when merging the threads.

veselin 6y ago

The author says in the end that the problem is not Amazon. Then links to a post where he suggests that companies maintaining the open source should have "invested the resources to build stronger communities around them. They would have reached out to Amazon, encouraged them to contribute back to the projects, and helped them to do so." Of course, they should "encourage" Amazon not to steal their product and business model. Right.

matthewmacleod 6y ago
Of course, they should "encourage" Amazon not to steal their product and business model. Right. It is not possible to steal something from someone who deliberately and freely offers that thing to you.
- veselin 6y ago
  I highly doubt elastic intended to offer it for free to the cloud providers from the start. They wanted to offer it for free to end users. This is why I expect new products will now start with these more restrictive licenses.
  - matthewmacleod 6y ago
    I highly doubt anybody chooses an explicitly free and open source license without intending to offer their software to users under the terms of that license.
    - __blockcipher__ 6y ago
      And to flip it around, the question isn't whether Elastic envisioned use case X. The whole meaning behind FOSS is that you're explicitly saying "I don't care what your use case is, you're free to use it". So to later turn around and say "hey we never envisioned Amazon et all turning around and selling Elasticsearch as a service" is looking at it backwards. When you release something under Apache 2 (or a similar non-restrictive license) you're intentionally telling people to do what they want with it. Anyway, my thoughts on these kinds of situations is that it usually implies there's some disconnect between how Elastic Co wants to make money versus how they actually are making money. --- There's a related issue of open source maintainers/devs feeling "exploited". Now while having users submitting issues with unfortunate tone/wording that implies that you're obligated as the maintainer to spend your time fixing their issues is frustrating, it's also part of the game. I'm getting really frustrated with the whole "it's not fair that company X is using my free software without contributing back". That's literally what you agreed to have happen when you released under a non-restrictive license! If you want a restrictive license, that's fine, but don't release under Apache 2 or BSD and then turn around and act shocked when people use your free software for free. It is unreasonable to put something out there for free and then suddenly expect money for it. That doesn't mean that companies shouldn't be contributing back to software they rely on - that's a no-brainer as far as I'm concerned - but it does mean that nobody should be surprised when someone does choose to "consume" software without contributing back.

rektide 6y ago

The license is quite long. https://www.mongodb.com/licensing/server-side-public-license https://www.mongodb.com/licensing/server-side-public-license Trying to determine what offering as a service is or implies is a bit difficult. If Discord used it to enable full text search, does they need to release their management layers too? Why or why not? How excited to defend your rationalization/decision to the court are you, if some disagreement arises? The ask, that companies open source their management layer, concerns me because it's unclear in many circumstances what does & doesn't need to go into that box. A management layer is often a rather sprawling piece of software. Trying to disentangle & release the Elastic Search or Kibana management layer from the other management /deployment/control systems could be quite onerous. I do think the intent is not "bad", but it's so hard & murky, there's so much peering into the crystal ball to guess whether, some day in the future, a once "open source" company that may, a decade down the road become aggressive/ligitious (not presently the case!) continues to find your particular use does or not does qualify as offering the product as a service, and does or does not expose you to a long complex obligation.

cheph 6y ago

The problem is, SSPL is heavily based of GPL, using the same concepts, and inheriting similar problems. GPL does not clearly define where the boundaries of a program is, but there is a fair bit of basis in the GPL FAQ and other writings from the FSF that suggesting that in their opinion, if I write a program B, that specifically depends on program A, then program A and B is part of the same program, regardless of whether or not it is linking in terms of C or if it is using it over the network. https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation : What is the difference between an “aggregate” and other kinds of “modified versions”? (#MereAggregation) > By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

sokoloff 6y ago
I think it’s more complex than that. If your program B is, as an example, a formatting-in-HTML wrapper around program A (say gnu grep), then you can ship B in binary-only, non-GPL form that calls A, so long as the end user can replace A with a later version or their own patched version of A and B continue to work. (This preserves the freedom of the user with respect to A.) In that case, B specifically depends on A (for filtering functionality), yet is still (likely, IANAL) considered a mere aggregate as I read things.

geofft 6y ago

Isn't it equally true that if they moved to being entirely proprietary but free-of-charge software, or if they had a "all rights reserved but you can look at the source if you want" license, or whatever, there would be no impact on most customers either? If so, why bother leaning into the word "open"? Just call it freeware.

confiq 6y ago

AFAIRemember, RedHat dropped MongoDB because of "controversial SSPL" > So essentially, anyone is free to modify MongoDB. It’s only when you offer MongoDB as a commercial service that the conditions of the SSPL state that you must open source the entire service. 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... Is this a difference like GPLv2 and GPLv3? Does this means that AWS now must open internal service (probably not but I'm trying to be devil advocate)

baq 6y ago
more like the difference between GPL and Affero GPL. https://en.wikipedia.org/wiki/Affero_General_Public_License https://en.wikipedia.org/wiki/Affero_General_Public_License
- confiq 6y ago
  I'm not sure that I can't follow them all :(
  - ignoramous 6y ago
    Long but may be helpful: https://www.oreilly.com/library/view/understanding-open-source/0596005814/ch03.html https://www.oreilly.com/library/view/understanding-open-sour... Not an expert but usually F/OSS licenses are mainly about: - Patent grants (either grants patent-use or doesn't) - Copyleft (should modifications be open sourced. ex: AGPL is the strongest FOSS copyleft, whilst SSPL builds on it to make it even more stronger) - Copyright (owners who are licensing the code) - Warranty and Liability - Terms of use (ex: FOSS licenses don't enforce restrictions on commercial use like CommonsClause does) Ref: https://choosealicense.com/ https://choosealicense.com/
ignoramous 6y ago
AWS wouldn't, I presume, touch the 7.11 dual-licensed Elasticsearch release with a ten-foot pole. They would have to hard-fork it here on, or Gold+ partner with Elastic.co to sell Elasticsearch Service under the relatively more permissive Elastic License.

pabs3 6y ago

Hmm, the Apache httpd folks didn't complain when web hosting services around the world started making money offering web hosting using it, without modifying it nor contributing back financially.

sfifs 6y ago

I wonder if non-ElasticCo contributors to Elastic Search who disagree with the SSPL license change can sue to have their contributions removed. Could even be a class action lawsuit if quite a few contributors disagree.

luord 6y ago
All their contributions up until this point are still under the Apache license, so they'd have no reason to sue, I think. And anyone is of course free to fork that code and call it something else. Now, it's very likely that many of them will stop contributing for versions 7.11 and up.
- sfifs 6y ago
  > All their contributions up until this point are still under the Apache license, so they'd have no reason to sue, I think Ah right - makes sense.