[HN Gopher] Licensing changes to Elasticsearch and Kibana
___________________________________________________________________
Licensing changes to Elasticsearch and Kibana
Author : sl_
Score : 175 points
Date : 2021-01-14 14:29 UTC (8 hours ago)
(HTM) web link (www.elastic.co)
(TXT) w3m dump (www.elastic.co)
| ForHackernews wrote:
| 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__ wrote:
| 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.
| lacker wrote:
| 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 wrote:
| 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.
| bevacqua wrote:
| Where does Elastic claim SSPL is open source?
| rektide wrote:
| "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 wrote:
| 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 wrote:
| > 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
|
| 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/
| frenchy wrote:
| Also, why is SSPL not open source? As far as I can tell, it
| mostly just seems like the APGL, but taken to 11. I can
| definitely appreciate why it's a problematic license, but I
| don't think "not open source" is its problem.
| lmc wrote:
| I found myself asking the same question a few weeks ago. The
| StackExchange link is probably more comprehensive, but I
| wrote a bit about it as well, here:
| https://blog.mcquade.dev/why-is-the-sspl-not-an-open-
| source-...
| tus88 wrote:
| Because you can't fork it and do whatever you want with it.
| frenchy wrote:
| You can't? I mean presumably you can't fork it and re-
| license the fork, but that's not exactly new.
| fabianhjr wrote:
| You can't "do whatever" with plain GPL-licensed code either
| yet linux is considered open and free source code.
| MaxBarraclough wrote:
| It seems it has neither the OSI's blessing as an Open Source
| licence, nor the FSF's blessing as a Free Software licence.
| Can anyone comment on why not, given that the AGPL has the
| blessing of both organisations?
|
| _edit_ Here 's an informative StackExchange comment. [0]
| Apparently it's a good deal stricter than the AGPL, and
| introduces much more legal uncertainty.
|
| [0] https://opensource.stackexchange.com/a/7523/
| frenchy wrote:
| Yes, I could see someone putting forward the argument that
| the SSPL is so unusable that ElasticSearch isn't actually
| expecting anyone to use it, and therefore it's more of a
| marketing gimmic than a license.
| Graphguy wrote:
| https://opensource.org/LicenseReview122018
| lovelearning wrote:
| 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.
| fiberoptick wrote:
| I wonder where this leaves the AWS-sponsored Open Distro 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 wrote:
| 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.
| robcowart wrote:
| The source code for the various components that make up Open
| Distro is already freely available under an Apache 2.0
| license. This change will have zero direct impact on Open
| Distro. The SSPL restrictions apply when the licensed
| software is used to provide a service.
|
| It is the AWS Elasticsearch Service that will be directly
| impacted. It will be limited to Elasticsearch 7.10.x as a
| foundation. Unless of course AWS makes available the code
| that they use to orchestrate and manage that service.
| Assuming that that code is sufficiently uncoupled from other
| systems, they could perhaps do exactly that. It would
| certainly be an entertaining counter-move from AWS.
| tus88 wrote:
| > The SSPL restrictions apply when the licensed software is
| used to provide a service.
|
| Wrong. It only affects code going forward. Elastic can't
| change the license of existing code.
| [deleted]
| kj4ips wrote:
| It looks like the way the license is written, they would
| have to release the source of the entire AWS console, and
| possibly everything that is AWS.
|
| IMO, the SSPL's cloud provision is a "Japanese No", it is
| so wide in possible interpretation, that only the Eclipse
| foundation could actually provide such a service.
| nopzor wrote:
| 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 wrote:
| AWS ES has major problems, have been a pain us for years.
| Pretty sure they cannot be competitive with a hard fork
| jamesblonde wrote:
| My guess, from AWS experience, is that you're right. What
| specific pain points did you experience?
| shawnz wrote:
| Presumably this change will impact Amazon's hosted
| Elasticsearch service, but why would it impact Open Distro?
|
| Although, I guess there will not be much of an incentive for
| Amazon to continue development of Open Distro after this
| change.
| davexunit wrote:
| "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 wrote:
| 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
|
| [2] https://github.com/meilisearch/MeiliSearch
|
| [3] https://github.com/valeriansaliou/sonic
| confiq wrote:
| > https://github.com/valeriansaliou/sonic
|
| This is actually very interesting project. Do we have some
| benchmark that sonic works on huge scale with lot of data?
| jabo wrote:
| Adding Typesense to the list as an easier-to-use alternative to
| ElasticSearch: 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 wrote:
| Exactly, the logs use case is what we use Elasticsearch for.
| z77dj3kl wrote:
| Do you really have to spam your project on every thread even
| remotely related?
| postalrat wrote:
| I didn't realize rust and the jvm solve the same problem.
| kam wrote:
| 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 wrote:
| 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.
| slaymaker1907 wrote:
| 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.
| ahachete wrote:
| So there's no big cloud offering MySQL-as-a-Service, right?
|
| And nobody uses Linux for their *-as-a-Service offering, no?
| choeger wrote:
| 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.
| Areading314 wrote:
| 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!
| rektide wrote:
| The license is quite long.
| 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.
| geofft wrote:
| 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 wrote:
| 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-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 wrote:
| more like the difference between GPL and Affero GPL.
|
| https://en.wikipedia.org/wiki/Affero_General_Public_License
| ignoramous wrote:
| 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_.
| alexfromapex wrote:
| 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
| CSDude wrote:
| They are dangerously vague. Is AWS at concern or the log as a
| service providers? Are you willing to take that risk?
| cheph wrote:
| 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 :
| 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.
| ajsharp wrote:
| Appreciate the clarification.
| Nican wrote:
| 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 wrote:
| 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.
| zmmmmm wrote:
| > using for client facing reports, a key feature of your
| application, is blocked.
|
| That seems a very pessimistic / overly conservative
| interpretation to me. They are clearly shooting for people
| selling Elastic itself as a hosted service here. Your
| client facing report being "Elastic Software or the
| features and functions of the Elastic Software" is unlikely
| to fall into "reasonable interpretation" space IMHO.
| latortuga wrote:
| 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 wrote:
| 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 wrote:
| I wish it would be explained that way
| slimsag wrote:
| 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/2164520b9e249fbae4e08e2bd
| f6e...
| 411111111111111 wrote:
| That's definitely not so clear from the quoted text
| though. The search field which just passes the content to
| elastic search definitely falls under that quote.
| ignoramous wrote:
| 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...
| Bombthecat wrote:
| Wait? Would even my devops pipeline fall under it?
|
| Or my monitoring? Deployment and management in kubernetes for
| example?
| catern wrote:
| Yes. That's the intent, that if you have some code (such as
| your devops pipeline) which is used to provide some service
| to an end user, the end user is able to
| use/modify/redistribute that code to provide the same
| service without you being able to obstruct what they do.
| ignoramous wrote:
| SSPL is a malicious source-available license, if there ever
| was one: 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
|
| [1] http://dtrace.org/blogs/bmc/2004/12/16/the-economics-
| of-soft...
|
| [2] https://www.gwern.net/Complement
|
| [3] https://www.joelonsoftware.com/2002/06/12/strategy-
| letter-v/
| matthewowen wrote:
| How true is this, in practice? I hear software folks say this
| sort of thing somewhat frequently, but I haven't heard it
| from a _legal_ person. And my general sense and understanding
| is that although an FAQ style clarification is not _perfect_,
| it _does_ carry non-trivial weight.
|
| Judges are not totally capricious people making arbitrary
| decisions: the notion that in a dispute they would just cast
| aside one party's _clear and well documented intent_ to
| narrow the scope of the burden they place on another is...
| well, it doesn't seem all that credible to me.
|
| Of course by the time you get to that point in a legal
| dispute you're already in some trouble.
|
| But IDK, I'm just a software person speculating. Is there a
| legal person interested in giving their "not legal advice"
| perspective on this?
| ignoramous wrote:
| I'd rather stick to the license text (than rely on mental
| gymnastics to justify any interpretation based on a _FAQ_ )
| to be upheld in the Court of Law.
|
| Btw, note how MPLv2 FAQ page clearly points out that the
| FAQ doesn't give anyone a license to freely interpret the
| license itself:
|
| > _...while this FAQ is intended to be accurate and
| helpful, it is not the license, and may not cover important
| issues that affect you and your specific situation. As a
| result, reading the FAQ should not serve as a substitute
| for reading the license itself, or for seeking legal advice
| from a lawyer._
|
| https://www.mozilla.org/en-US/MPL/2.0/FAQ/
| ender341341 wrote:
| > Judges are not totally capricious people making arbitrary
| decisions: the notion that in a dispute they would just
| cast aside one party's _clear and well documented intent_
| to narrow the scope of the burden they place on another
| is... well, it doesn't seem all that credible to me.
|
| My (non-lawyer) experience tells me the same, judges don't
| like people who try to argue one thing to a judge while
| clearly documenting on their website the opposite isn't
| going to go well, but as others pointed out that doesn't
| make it a smart choice to depend on, or that corporate
| lawyers will agree is worth the risk.
| halbritt wrote:
| In my experience, corporate lawyers don't really understand
| the distinction and will opt for the route of least risk,
| which generally entails a commercial relationship with the
| company. Unfortunately, neither Mongo nor Elastic really
| offer useful commercial relationships. That is, pay them a
| sum and be free to use the widely adopted open-source
| version of their thing.
|
| The overhead to those relationships for what they do offer
| is significant.
| dang wrote:
| Re "alarmist headline": the comment was originally posted in
| reply to https://news.ycombinator.com/item?id=25781695, but
| it's a good subthread so I moved it over when merging the
| threads.
| veselin wrote:
| 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 wrote:
| _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 wrote:
| 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 wrote:
| 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__ wrote:
| 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.
| emrah wrote:
| I find it hard to believe "people" would willingly do
| this but when it's faceless corporations, it can and does
| happen
| fabianhjr wrote:
| And they (ElasticSearch) rightfully excluded what they feel
| is taking advantage of them in an exploitative manner.
|
| I am quite sure they are open to a reciprocal licensing
| agreement with AWS et al.
| matthewmacleod wrote:
| They are welcome to do that if they feel that way. But
| it's not theft for people to use software under the terms
| of the license you offer it to them under, and it's a
| fucking stupid accusation to make.
| fabianhjr wrote:
| I agree, the sentiment was more akin to "taken advantage
| of" rather than "getting robbed".
| CSDude wrote:
| 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 wrote:
| 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 wrote:
| None. That's clearly not offering Elasticsearch-as-a-service.
| hbogert wrote:
| 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 wrote:
| 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.
| blacklight wrote:
| 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.
| andr wrote:
| 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/
| softwaredoug wrote:
| Is this because the Wordpress market is _huge_ (almost every
| website)? Whereas Elastic, Mongo, etc market share is not as
| huge?
| __blockcipher__ wrote:
| 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 wrote:
| That's great for Matt, but other companies like Elastic can't
| afford to go from >50% to 5% of their market.
| artembugara wrote:
| 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
| darkarmani wrote:
| Which means AWS is going to fork their own version of ES and
| not push their fixes upstream.
| mcintyre1994 wrote:
| 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.
| lacker wrote:
| _We use AWS 's ES. And, as far as I'm concerned they already
| open-source their version._
|
| Unfortunately for you, there's a decent chance that AWS freezes
| their support at a version before this license change, and
| never offers upgrades. As far as I know, AWS has never agreed
| to offer services based on code under the SSPL license.
| ignoramous wrote:
| SSPL isn't an open source license:
| 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
|
| MPLv2, EPLv2, xGPLv3 are strictly _libre_ even if not as wildly
| copyleft as SSPL.
| jameshilliard wrote:
| > 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 wrote:
| > 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?
| a_imho wrote:
| 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 wrote:
| an updated version of firefox loads fast without issue
| a_imho wrote:
| 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 wrote:
| That's not even an ESR version - forget pages breaking, running
| Firefox 61 in 2021 is a security nightmare.
| sciurus wrote:
| 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 wrote:
| SSPL is based on the GNU AFFERO GENERAL PUBLIC LICENSE
| 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-so...
| worldsayshi wrote:
| What will this entail for when you're building Elastic
| Plugins?
| brasetvik wrote:
| > 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-
| plu...
| z77dj3kl wrote:
| FAQ is not the license, it's their rosy interpretation.
| [deleted]
| craigching wrote:
| I'm wondering how this affects the distribution of x-pack. From
| what I'm reading, the new Free model probably includes it and
| we have to turn it off if we don't want it? I wish there was
| still an x-pack free distribution in this model.
| dhd415 wrote:
| Since the entire Elasticsearch codebase is now under SSPL,
| there's no more distinction between the former Apache-2 code
| and the x-pack code.
| craigching wrote:
| Yes, I understand that, but what I would like is a
| distribution without any x-pack code. I don't want to have
| to figure out how to turn off and remove x-pack. What I'm
| concerned about is that it's another vector for security
| vulnerabilities that I don't need.
| shawnz wrote:
| There are still proprietary modules only available under
| the Elastic License just as before.
|
| However it seems that they will be moving the free modules
| which were previously only licensed under Elastic License
| to be licensed under SSPL instead.
|
| At least, that is what this graph seems to be indicating to
| me. https://images.contentstack.io/v3/assets/bltefdd0b53724
| fa2ce...
| dhd415 wrote:
| You're right -- it's only the free "X-pack Basic" code
| that will now be available under SSPL. But that does mean
| that all Elasticsearch distributions will now include the
| former "X-pack Basic" features.
| shawnz wrote:
| That seems to be what they are suggesting by making the
| "free" box in the 3rd column span both the "free" and
| "free/basic" tiers of the previous columns.
|
| Unless they plan to make those modules paid which were
| previously free, which I doubt
| PeterZaitsev wrote:
| 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 wrote:
| Lets have a round of applause for the Lucene contibutors !
| wmf wrote:
| _Those folks have reasonably counted on having fruits of their
| labor to be available under Apache 2.0_
|
| Not really; the essence of permissive licenses is that
| proprietary extensions/versions are allowed. If you want to
| contribute code that will always remain open you need a
| copyleft license like GPL.
| darkarmani wrote:
| > Those folks have reasonably counted on having fruits of their
| labor to be available under Apache 2.0 and now they only get to
| use them with SSPL restrictions
|
| While i hate the change, that isn't true. They have access to
| their changes in the current and older versions of Elastic. You
| can lock yourself to the current version forever and create
| your own bug fixes.
| Xylakant wrote:
| elasticsearch had a contributor license agreement in place for
| about as long as I can think, requiring full copyright
| assignment for all changes you'd contribute.
| wylie wrote:
| That's not accurate: there is a contributor agreement but it
| does not assign copyright.
| https://www.elastic.co/contributor-agreement
| paxys wrote:
| I feel this way about all similar licensing changes (Redis,
| Elastic among many others). It's basically a large company vs
| much larger company fight, and the losers are the thousands of
| individual contributors not affiliated with either one who have
| worked for free and can no longer use their work in the way
| they want. Moves like this are definitely eroding trust in open
| source in the long term.
| dhd415 wrote:
| There's a fair amount of hyperbole in that statement. Most of
| the above products (Redis, Elasticsearch, MongoDB, etc.)
| don't have "thousands of individual contributors" and are
| developed primarily by employees of the backing companies.
|
| Second, external contributors can use it in their work in any
| way that they want so long as it's not in offering
| Elasticsearch-as-a-service. They can even use for offering
| Elasticsearch-as-a-service so long as it's based on the
| current Apache2-licensed code rather than the SSPL-licensed
| code that will be in effect as of the next Elasticsearch
| release.
|
| There are certainly valid criticisms of this decision, but a
| blanket statement that "thousands of individual contributors"
| are the losers here is an exaggeration.
| j1elo wrote:
| I raised precisely this concern a week ago:
| 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.
| soheil wrote:
| > 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 wrote:
| 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 wrote:
| Yes. Any version released under a given license remains under
| that license, it cannot be retroactively changed.
| Pet_Ant wrote:
| 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.
| RcouF1uZ4gsC wrote:
| > 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.
| nopzor wrote:
| it's not copyright violation. it's a license violation. they
| are completely different.
| fiberoptick wrote:
| Copyright law is the basis for the legal enforcement of
| software licenses. License violations usually get pursued
| under copyright law
| nopzor wrote:
| that's fair, but my point is that the analogy of linking
| to a newspaper article content doesn't really apply to
| this. it's apples:oranges.
| tannhaeuser wrote:
| > _This is similar to newspapers who claimed that having
| links to their site, violates copyright._
|
| No newspaper has claimed that ever to the best of my
| knowledge, and it would make absolutely no sense to. What's
| being criticized is so-called "rich linking", ie. previewing
| content such as Wikipedia articles from search engines or
| news articles from aggregators without taking viewers to the
| primary source/site. People having a radical anti-copyright
| agenda have conveniently named this "rich linking" to dilute
| the discussion, as have news aggregators to downplay the
| issue.
|
| As an aside, the way the EU copyright reform is being
| formulated into national law in Germany has been criticized
| as outright contrary to the whole purpose of the reform, and
| coming straight from pro-Google lobbyists [1].
|
| [1]: https://www.faz.net/aktuell/wirtschaft/eu-
| urheberrechtsrefor... (in German)
| Pet_Ant wrote:
| The issue should be whether there is a linking and not the
| nature of the linking. I mean if "over HTTP" was a get-out-
| of-jail card then you just need a C-ABI => JSON standard, and
| then you can link any library you want and only the server-
| linker needs to be opensourced (and probably would be as
| BSD).
|
| I believe this is why the GPL uses the term "derivative".
|
| > This is similar to newspapers who claimed that having links
| to their site, violates copyright.
|
| Making links to their site might violate the license by which
| they allow you to browse their site, but it doesn't break
| copyright. If the on their homepage had a pop-up "You must
| agree not to not share any links found on this site as a
| condition of using this site" that would be analogous.
| hodgesrm wrote:
| The problem I have with the SSPL is that Section 13. Offering
| the Program as a Service seems pretty vague. Here's the part I
| don't understand.
|
| > Making the functionality of the Program or modified version
| available to third parties as a service includes, without
| limitation, enabling third parties to interact with the
| functionality of the Program or modified version remotely
| through a computer network, offering a service the value of
| which entirely or primarily derives from the value of the
| Program or modified version, or offering a service that
| accomplishes for users the primary purpose of the Program or
| modified version.
|
| Does this include services you don't charge for? For example I
| might offer services for marketing reasons. At what point is
| the service no longer primarily derived from the Program? For
| example if I build an application that offers query
| capabilities but does not expose the Program API, does that
| count?
|
| For contrast GPL V2 worked because it tied virality to linking,
| which is pretty easy to validate.
| davexunit wrote:
| >Personally, I'd rather see a more aggressive AGPL where REST
| calls are considered linking and trigger virality
|
| Please don't compare a license to a virus. In any case, my
| understanding is that the AGPL _does_ cover this and is why it
| exists. If it didn 't cover this it would be useless.
| ocdtrekkie wrote:
| 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 wrote:
| 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.
| npiit wrote:
| >Personally, I'd rather see a more aggressive AGPL where REST
| calls are considered linking and trigger virality
|
| That's why I never understood the point of SSPL. Is this
| exactly what AGPLv3 is supposed to be for?
| LukeEF wrote:
| 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.
| PeterZaitsev wrote:
| Yep. It may totally make a "business sense" but positioning as
| great for Open Source community and "Doubling Down on Open"
| stinks
| [deleted]
| unethical_ban wrote:
| You are being too cynical.
|
| Their argument is, more charitably: "We built this, we released
| it for free. Our business model is professional support and
| hosted services. In order for us, the creators of this
| software, to continue building it, we cannot allow
| megacorporations to freely spin up a loss-leading competitive
| service and cut us out."
| __blockcipher__ wrote:
| Some observations:
|
| (1) It's interesting how much of the reasoning/argumentation
| for these restrictive licenses ultimately comes down to a
| more articulate form of "but that's not fair!". I also wonder
| how much the implicit beliefs that "unrestrained capitalism
| is a bad thing", "markets naturally lead towards monopolies",
| "antitrust law is legitimately necessary", etc are impacting
| peoples' reasoning here.
|
| (2) If they can't actually compete and provide superior value
| to whatever managed offering Amazon can scrounge together,
| that's actually their fault. AWS' managed elasticsearch
| offering is absolutely terrible, speaking from experience.
| They block access to important APIs like `reroute`, any minor
| cluster change results in a whole blue-green deployment which
| very frequently hits a race condition that prevents the newer
| cluster from ever coming up healthy, requiring a ticket to be
| filed that takes multiple days to respond to if you don't
| have premium support, etc.
|
| So functionally the idea that AWS is going to fleece them
| because they'll offer a just-as-good service for cheaper has
| not been the case. Elastic co's managed offering is simply
| far superior.
|
| ---
|
| Ultimately, Elastic has shown that they don't actually want
| to release FOSS. They want to release proprietary software,
| and that's why the (in hindsight very easy to foresee)
| usecase of a cloud provider offering a managed service angers
| them so much. They don't really breathe the FOSS mindset,
| because a true non-restrictive license (BSD, Apache 2.0 etc)
| means that a company can absolutely use your software to make
| money and that's okay.
|
| Anyway, Elasticsearch is incredible software and the Elastic
| team has made something truly incredible. I just wish they
| had a vision for monetization that aligned with their open-
| source beginnings. It's clear that they don't, and the sooner
| they stop pretending they're offering a free or open-source
| solution here, the better.
| Xylakant wrote:
| > 2) If they can't actually compete and provide superior
| value to whatever managed offering Amazon can scrounge
| together, that's actually their fault.
|
| The sad-funny thing is that elastics hosted cloud offering
| is clearly superior to AWS' hosted elasticsearch in pretty
| much all regards.
| mcintyre1994 wrote:
| Wouldn't getting logs from some AWS service into Elastic's
| hosted service (or anything not in AWS) be really expensive
| at scale though?
| [deleted]
| LukeEF wrote:
| 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 wrote:
| 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 wrote:
| It's not open source though.
| Drdrdrq wrote:
| 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.
| coagmano wrote:
| I think this is the right way to look at things, after
| all, these were the orignal "why" arguments in favour of
| open source. If we can get the same benefits while also
| protecting open products from megacorps like AWS, that's
| a better licence than a true open source licence
| __blockcipher__ wrote:
| > If we can get the same benefits while also protecting
| open products from megacorps like AWS, that's a better
| licence than a true open source licence
|
| That's your opinion, of course. IMO, there's a type of
| magic that happens when software is under a truly non-
| restrictive license. You get a level of quality and
| reliability in the software that is unmatched by what you
| get with any proprietary equivalent.
|
| Unfortunately, most people don't really believe in FOSS.
| And that's okay. But boy am I getting frustrated with
| these companies that are happy to preach about how "open
| source" is amazing, until someone else is making some
| profit with their software and then suddenly the
| (extremely vague) restrictive licenses start rolling out.
| AmericanChopper wrote:
| I don't think it's reasonable to attribute motive to the
| contributors in this way. Changes like this protect the
| elastic enterprise, whether they align with the motives of
| contributors would have to be evaluated on a per-
| contributor basis.
|
| I've made several contributions to ELK, and my only motive
| has been that it's useful open source software, and I want
| to make it more useful. I personally don't care who profits
| off the codebase, I think anybody should be free to. I
| personally would object to anybody trying to lock down how
| it can be used, and would see any attempt to do so as
| running completely counter to my personal motivations as a
| past contributor.
|
| Which is exactly what I see Elastic doing here.
| __blockcipher__ wrote:
| > I've made several contributions to ELK, and my only
| motive has been that it's useful open source software,
| and I want to make it more useful. I personally don't
| care who profits off the codebase, I think anybody should
| be free to. I personally would object to anybody trying
| to lock down how it can be used, and would see any
| attempt to do so as running completely counter to my
| personal motivations as a past contributor.
|
| This x 10000. I couldn't agree more, thanks for putting
| that so clearly.
|
| Frankly, I think a number of people in the Open Core
| movement have a psychological hangup around profit. They
| feel that if a company - particularly a large corporation
| - is making money using their software without
| "contributing back", that that should not be allowed.
| Well, if you don't want to allow it, fine, but don't
| pretend you're in the business of releasing free software
| - you're not. You want to be in the business of
| proprietary software, since only proprietary software
| lets you say "hey I don't want Jeff to profit off of my
| work without paying my for a proprietary license".
| AmericanChopper wrote:
| I very strongly agree. It's always seemed like a
| quintessential tragedy of the commons to me. Everybody
| benefits from open source software, no matter what
| they're doing. Proportionally, very few
| people/organisations contribute to open source, and I
| would guess that nobody contributes to every open source
| project that they consume. I've always seen one of the
| core aspects of the value of open source being the common
| utility they provide. The idea that an open source
| consumer should contribute back value in some way
| proportional to the value they derive runs counter to
| that. The moment you start to restrict access to open
| source software based on some model of deservedness, you
| start to undermine the principles of common good that a
| lot of open source values are based on.
| ignoramous wrote:
| F/OSS exists so that not everyone has to be subject to
| undifferentiated work, among serving other very high impact
| purposes. Think brew.sh, vim/Emacs, Eclipse IDE, Postgres,
| Java, Linux/Linaro etc;
|
| Substitute AWS for "a software developer" and see if you
| feel the same way.
|
| > _I feel so much for the hundreds of open source
| developers who toil everyday only to have other software
| developers make so much money out of it... while
| contributing nothing back to any of the open source
| projects. This has to be fixed..._
| draw_down wrote:
| 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.
| VoxPelli wrote:
| 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/
| opsunit wrote:
| It is interesting to note that elastic.co is hosted on Google
| Cloud: https://runson.cloud/search/elastic.co
| JarlUlvi wrote:
| The way I understand it, AWS has been creating derivative
| products that don't work very well based on ELK. AWS has also not
| been contributing back to the community anything, while raking in
| the millions for https://aws.amazon.com/elasticsearch-
| service/the-elk-stack/
|
| Many elastic pros recommend not using the AWS version because it
| doesn't operate properly.
|
| While I am pro OSS I can understand why a company based on OSS
| would not want to subsidize a much larger AWS who is extracting
| value, and also, their direct competitor.
|
| When I talked with AWS about an estimate for Managed ELK, and
| also, an EC2 based ELK, I received estimates > 50M a year. Crazy
| pricing
| mrkstu wrote:
| Which makes it sounds like AWS wasn't competing very well in
| the space, if it couldn't do so affordably.
| _msw_ wrote:
| 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/59563
| https://github.com/elastic/elasticsearch/pull/57271
| https://github.com/elastic/elasticsearch/pull/53643
| nkw wrote:
| So how is Elastic going to fare if Lucene makes a similar switch?
| robcowart wrote:
| 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 wrote:
| 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
| craigching wrote:
| Elastic is one of, if not the largest, contributor to Lucene
| anyway.
| z77dj3kl wrote:
| 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!
| nopzor wrote:
| 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.
| LukeEF wrote:
| 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 wrote:
| I don't think it's really that different. Elastic did that
| same thing about three years ago when they made all of their
| enterprise-only features source-available
| (https://www.elastic.co/blog/doubling-down-on-open).
| Timescale also made their enterprise features free of charge,
| but that's a business decision rather than a question of
| licensing. It's because their revenue model is based
| completely on their managed cloud offering while Elastic
| still gets non-trivial revenue from selling their enterprise
| features to customers who want them.
| mfreed wrote:
| 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-
| busines...
| Drdrdrq wrote:
| TimescaleDB licensing is mightily confusing. Instead of
| clarifying here, you might want to provide clear licensing
| info for all your products _on your webpage_.
|
| Happy (non-paying) user otherwise, but this is a bit shady
| in my eyes.
| npiit wrote:
| 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 wrote:
| 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.
| npiit wrote:
| 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.
| dhd415 wrote:
| 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.
| pietrovismara wrote:
| Honestly, every relevant FOSS project should adopt a similar
| license to prevent exploitation from corporations.
| darkarmani wrote:
| Every project can choose it at the beginning if they choose.
| But it will tremendously hurt adoption and community.
| gaius_baltar wrote:
| > Honestly, every relevant FOSS project should adopt a similar
| license to prevent exploitation from corporations.
|
| The correct FOSS way to do this is using a FOSS license, an
| SSPL is not one of these. AGPLv3 is and provides a nice
| protection.
| fabianhjr wrote:
| There is some discussion on the P2P Foundation regarding
| copyfarleft/copyfair/copyjustright however in my experience
| even the most popular copyfarleft isn't as adopted. (
| https://wiki.p2pfoundation.net/Copyfarleft )
|
| I have been gathering resources regarding copyfarleft licensing
| and projects here: https://github.com/LibreCybernetics/awesome-
| copyfarleft
| pietrovismara wrote:
| That's great, thank you for doing this!
|
| I already knew about the Anti-Capitalist Software License but
| didn't know about the others. Copyfarleft is a great concept.
|
| To make this work we need to build an ecosystem around these
| licenses and non-exploitative business models. The fist step
| is indeed to let people know such licenses/ideas exist.
| davexunit wrote:
| They would no longer be FOSS if they did that.
| pietrovismara wrote:
| In practice it would only affect corporate thieves, so I
| think it's actually necessary to protect the open source
| ecosystem.
| __blockcipher__ wrote:
| 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...
| ahachete wrote:
| > 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 wrote:
| 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...
| ignoramous wrote:
| Here's a thought experiment for folks finding themselves agreeing
| with Shay Banon and his rallying cry to dismiss the FUD
| _naysayers_ spread and trust him instead: Imagine how you 'd feel
| if the F/OSS IDE, Language, Toolchain, OS, Database, Browser you
| use changed overnight to SSPL?
| arpinum wrote:
| "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."
| eloff wrote:
| What do you expect them to do though? If they want to be viable
| as a business they need to place some restrictions so they can
| have a monopoly on some aspect in order to derive profit.
|
| If they're not viable as a business, they die and nobody
| benefits from that.
|
| It's this kind of all or nothing criticism that has made me
| rethink open source. I'm releasing a product this year, and
| it's going to start under a proprietary license. Because it
| seems you're damned if you do and damned if you don't. At least
| commercial closed source products don't attract this kind of
| criticism.
| arpinum wrote:
| I expect Elastic to not pretend they are doing this in the
| spirit of getting contributions back. Just say that this is
| in the interests of their business model.
| shawnz wrote:
| Agreed, if their hosted cloud services and premium features
| aren't viable as a business, and they don't have any
| intention to develop this software without a profit, then
| they shouldn't have positioned themselves as a free-and-open-
| source product in the first place.
| andlarry wrote:
| You can run the SSPL'd code, you can view the SSPL code, if
| you change the SSPL code then contribute back if you
| distribute your changes. If you run a service providing the
| SSPL code, contribute the management layer back as well.
|
| It gets more code into the open, where's the disconnect?
| shawnz wrote:
| I am not concerned with the code of other users'
| management layers. I am concerned with being able to use
| the code of this product in the way I want to use it.
| Copyleft is not important to me, I see permissive
| licensing as being a bigger priority for freedom.
| PeterZaitsev wrote:
| This "We need it for survival" is bullshit. With Elastic
| being public company you can see their revenue growing 60%
| last year.... with Apache 2.0 license. It is not the case
| what we've been loosing revenue for years due to AWS
| competition and this is the last action of the last resort.
| This is simply about speeding up the growth at expense of
| your users which is of course sugarcoated as "it is good for
| you"
| freedomben wrote:
| It's a vocal minority that slings the hate. There are tons of
| people that appreciate open source with exceptions to prevent
| managed offerings by cloud providers as long as self-hosting
| to support your own stuff is allowed (including ability to
| customize/extend/patch).
|
| I for one will (with a few exceptions) only pay for a product
| that is open source (at least enough so that I can self-host
| for my own product if I want should things change). Vendor
| lock-in is a serious problem and concern for many, and open
| source is how you address that concern. The best example is
| GitLab, which gets a _ton_ of money from me that would
| otherwise go to GitHub (which I like better) if GH were open
| source.
|
| By going proprietary you avoid the vocal minority on the
| internet, but you also (silently) shrink your potential
| customer pool. Especially with the AWS/Parler stuff, there
| are even more people that want the option to self-host in
| case they get de-platformed if the Overton Window continues
| to shift.
|
| May I ask what your product is? Just curious :-)
| eloff wrote:
| > It's a vocal minority that slings the hate.
|
| That's usually the case.
|
| > at least enough so that I can self-host for my own
| product ... Vendor lock-in is a serious problem
|
| I'm leery of vendor lock-in myself. Self-hosted will be the
| only way to run my product in the beginning, and the cloud
| service will follow when it's popular enough to make sense.
|
| > May I ask what your product is? Just curious :-)
|
| I haven't published the website yet (it will be at
| https://flowstate.dev), but it's a framework/runtime for
| building backend APIs using SQL and JavaScript. It lets you
| run SQL queries from the browser, among other things. Which
| sounds crazy, but it actually works well. Once I have a
| hosted cloud service it becomes a backend-as-a-service
| platform kind of like Parse or Firebase.
|
| I'm not against open-sourcing it down the road, but it
| can't be an OSI license, and I'll wait until it's big
| enough that I'm less worried about competitors just lifting
| my source code. I know copyright laws protect against that,
| but that only matters if you have the resources to
| litigate.
|
| I do want my users to be able to dig into the source if the
| documentation is lacking, and also to patch/modify it if
| they need to - so I need some kind of source-visible
| license down the road. I think I would also add a clause
| that if the company goes under or gets acquired and
| shutdown then all source code gets published under the
| Apache 2 license.
| shawnz wrote:
| 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.
| bevacqua wrote:
| Elastic contributes massively to Lucene, so this is a false
| dichotomy
| freedomben wrote:
| Thanks for pointing this out.
|
| Red Hat (my employer currently) is typically in the same
| boat here and it drives me crazy how people don't think
| about that before criticizing.
|
| People love to say, "Red Hat couldn't exist without
| <project>" which is true, but what they don't realize is
| that a ton (sometimes all) of the development of that
| upstream project is done by Red Hat employees. Without that
| a lot of projects may not even exist.
|
| There are no doubt "open source" companies that take more
| than they give, but it's a little more nuanced and
| complicated than people make it out to be.
| __blockcipher__ wrote:
| And guess what, when a corporation uses Elasticsearch in a
| serious way they will inevitably end up contributing back.
| It's actually easier to just get a change merged upstream
| rather than to manage a whole fork, unless the upstream is
| really hard to get patches merged with.
|
| The whole narrative of "company X is offering Elasticsearch
| as a service and not contributing back!" is ridiculous.
| First of all, the whole point of free software is that
| somebody somewhere is going to be making money with that
| software, and that's okay, regardless of contribution.
| Second of all, in practice companies like Elastic will
| always exaggerate the extent to which corporations aren't
| "contributing back".
|
| What they really mean is Amazon isn't contributing
| financially to Elastic Co. That's what they're pissed
| about, and that's why they clearly wish they were actually
| in the business of proprietary software (which they now
| are)
| ignoramous wrote:
| Would Elastic be in a position to "close source" / "re-
| license" their code if Lucene wasn't itself permissively
| licensed? Your argument's putting the cart before the
| horse.
| nopzor wrote:
| 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.
| arpinum wrote:
| Thats fine, but then don't title the blog post "Doubling down
| on open", make it "Creating a more profitable business
| model".
| christophilus wrote:
| 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.
| brasetvik wrote:
| They already do. https://www.elastic.co/about/press/elastic-
| partners-with-ali...
| tus88 wrote:
| I wonder what will happen to the AWS ElasticSearch offering.
| LittlePeter wrote:
| What does it mean for Elasticsearch Service on AWS?
| dhd415 wrote:
| 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 wrote:
| 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 wrote:
| I can't imagine they'd want their competitors to see any of
| the internals of their control plane or other internal
| infrastructure.
| hbogert wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-14 23:00 UTC)