[HN Gopher] Doubling down on permissive licensing and the Elasti...
___________________________________________________________________
Doubling down on permissive licensing and the Elasticsearch
lockdown
Author : carlotasoto
Score : 58 points
Date : 2021-01-27 18:23 UTC (4 hours ago)
(HTM) web link (crate.io)
(TXT) w3m dump (crate.io)
| anderspitman wrote:
| I find it fascinating to wonder whether it's better to go
| permissive and risk Amazon "stealing" your work vs going copyleft
| and risk never getting big enough for Amazon to care. Even if
| Amazon is making 10x more money than your off your code, you
| might still be making more than you otherwise would, due to
| exposure. Anyone aware of any hard numbers/research on this?
| cardanome wrote:
| The issues is not so much Amazon making money from it but
| Amazon acting as a direct competitor against their own cloud
| offering.
|
| Personally I am happy about their decisions, as it stops the
| bleeding caused by big monopolistic corporations while
| protecting the freedom of users like me.
| anderspitman wrote:
| But the question is would you have ever even known it existed
| or trusted it if Amazon hadn't picked it up and made it big?
| chrisco255 wrote:
| Elasticsearch? Of course you would, it's the most well
| known open source search tool and has been for the better
| part of a decade.
| berkes wrote:
| > What is "not ok" is the fact that switching to a GPL based
| license forces projects depending on the code like CrateDB to use
| a fork since it kills the business model.
|
| If your business model cannot survive when a critical upstream
| piece of your infrastructure moves to GPL, you probably have a
| bad business model to begin with.
|
| They say:
|
| > We would never have chosen Elasticsearch in the first place,
| had it been licensed under the GPL as some of our customers (and
| many large enterprises do by default) banned GPL licensed
| software from their application stacks for legal risks.
|
| Which is completely new to me. There are numerous examples of
| software that has a successfull business model, and is GPL or GPL
| compatible. From WordPress to MySQL, and from ProtonMail to
| PostgreSQL (GPL compatible). Used in enterprise, and other large
| organisations, just fine.
|
| It sounds like they are making up excuses for not wanting to
| fully Open Source their code; which is fine. But don't blame
| upstream for your reluctance or inability to adhere to this.
| proddata wrote:
| > If your business model cannot survive when a critical
| upstream piece of your infrastructure moves to GPL, you
| probably have a bad business model to begin with.
|
| To be clear CrateDB started out as OSS and we decide to stay
| OSS. Elasticsearch used the Apache License and so did CrateDB.
| All in the spirit of OSS. Elastic are however now the ones how
| decided, that their business model isn't viable anymore.
|
| > It sounds like they are making up excuses for not wanting to
| fully Open Source their code
|
| We do want to make it fully open source! Everything that was
| under a more restrictive License is going to be offered under
| Apache License.
| berkes wrote:
| Thanks for correcting me!
|
| > We do want to make it fully open source!
|
| This begs the question: isn't "a restrictive OSS licence" not
| less "fully open source" than a more permissive licence like
| GPL, MIT or BSD?
|
| If you are fully committed to OSS, why not go full-oss,
| instead of retaining control through a restrictive OSS
| licence?
|
| Is that really only because of some enterprises not liking
| GPL?
| eeZah7Ux wrote:
| > why not go full-oss, instead of retaining control through
| a restrictive OSS licence?
|
| The main point of copyleft is to pass down freedoms to
| use/modify/distribute all the way to the end user.
|
| Instead we got locked-down privacy-breaching smartphones,
| IoT devices, SaaS, where only the manufacturer benefits
| from OSS.
| derefr wrote:
| Copyleft licensing was invented in an era when most
| things were written in C, and software fell into roughly
| four categories:
|
| * Unix-ish black-box "primitive" tools, that were so
| focused on accomplishing one fundamental job that they
| were essentially "final" in their interfaces, with there
| being no point to extending them any further; where you
| reused them by _executing_ them, not by integrating with
| them.
|
| * A library for such Unix-ish black-box tools to use.
| Most tools that used any libraries at all, would use _one
| main_ library to accomplish their _one primary_ purpose,
| effectively making the tool a "driver program" for the
| library.
|
| * Academic data-science/statistics code.
|
| * Cathedral-style highly-integrated software, e.g.
| Windows.
|
| Copyleft was mostly devised _for_ the purpose of
| licensing the codebases of the first two types.
|
| As Unix tools are self-contained, they only "infect"
| direct forks. The GPL _originally_ intentionally avoided
| infecting the things that called (i.e. interacted with)
| those tools -- because, back then, a downstream project
| that "uses" a tool wasn't vendoring in its own version,
| but rather relying on the _system installation_ of that
| tool, through that tool 's known API; and it wouldn't
| make sense for a license to be infectious through a
| standardized API.
|
| It was intentional that libraries would infect their
| downstream clients with copyleft; but downstream clients,
| back then, were mostly just those single-purpose tools.
| It wouldn't make sense for e.g. libgit to be GPL-
| licensed, but for git(1) to be proprietary.
|
| Of course, there was also an awareness that the
| Cathedral-style codebases would have their whole monolith
| infected if they used the GPLed library. The idea there,
| though, wasn't to actually cause that infection -- it was
| to inhibit Cathedral-style codebases from using GPLed
| software at all.
|
| (With the parallel awareness that such entities could
| always reach out to the project maintainers, and buy a
| separate license, just like you can purchase a license
| from any IP-holder. There were few-enough contributors
| per project, back then, that "copyright assignment" and
| such wasn't a concern; you could just get a proprietary
| license from the one dude who built the whole thing.)
|
| And that same consideration was implicit with academic
| use of GPLed software. FOSS programmers, back then,
| considered academic (or non-profit)
| integration/derivation of their software to be something
| they'd grant a free license for if asked; and academics
| knew this, and so didn't bother to ask for such licenses,
| because they knew they'd almost assuredly get one, for
| free, if-and-when it ever became important to do so.
|
| ---
|
| The GPL was well-suited to this early-90s software IP
| ecosystem. It doesn't fit nearly as well in the modern
| software IP ecosystem.
|
| There's a whole fifth category of software -- semi-
| Cathedral, semi-Bazaar mega-tools, like youtube-dl or
| Calibre; or mega-libraries, like Qt, or LLVM, or WebKit;
| which both _are_ components while also _consuming_ many
| components themselves. The GPL never "expected" this
| type of software. This kind of software just didn't exist
| back then; only its entirely-Cathedal final-product
| equivalent did.
|
| Which is a problem, because it's impossible to build
| something like WebKit or LLVM in a self-contained, "you
| call it over a standard interface" sort of way, where
| it's non-infectious. These days, lot more projects are
| infectious, even when "integrated" at a much higher level
| of abstraction, than the GPL was ever _intended_ to
| require.
| eeZah7Ux wrote:
| The distinction between GPL and LGPL seems completely
| lost on you.
|
| LGPL existed since 1991. Also large libraries and
| frameworks.
| derefr wrote:
| I'm not talking about the GPL or the LGPL specifically,
| but rather I'm talking about the thing that was in
| Stallman's head before either of them existed -- the
| _concept_ of copyleft, of an infectious "Free" license.
|
| Yes, you can create different implementations of that
| concept, that are variously infectious. But the reason I
| laid out the whole state of the ecosystem as RMS would
| have seen it when he was still just _conceptualizing_
| copyleft, is that in that ecosystem, "infectiousness"
| was something that's almost _trivial_ , toothless.
|
| In the ecosystem of the early 90s, licensing a codebase
| was just a consideration of who you _trusted_ to freely
| use and modify your thing ( "us", hackers); vs. who you
| wanted to _not_ use your thing, unless they paid you (
| "them", corporate.) Copyleft neatly prevented "them" from
| swiping and profiting off of the software created by
| "us", while not really inhibiting anything that "us
| hackers" wanted to do with that same software.
|
| Contrast to the ecosystem of today: there's an entire
| category of people -- individuals who start projects _as_
| hackers or academics, but then _build_ huge software
| businesses around them -- that didn 't even _exist_ back
| in the 90s.
|
| Google is the epitome of this: at its inception, BackRub
| (Google Search) was exactly the type of project that
| copyleft was designed to _avoid_ restricting. But it
| evolved, through commercialization, patenting, SaaS-
| ification, and scale, into exactly the type of project
| that copyleft _wants_ to "shun out of" the FOSS
| ecosystem. (Not that Google Search integrated any FOSS
| libraries; just that it could have.)
|
| Google's story, is the story of _most_ software projects
| today. _Every_ developer is considering their project as
| a potential "open core" for a SaaS, or considering
| having an "enterprise version" of their tool, or
| considering licensing their algorithm as a plugin to some
| big studio to redistribute. Which is exactly why many
| programmers avoid integrating copyleft software into even
| their hobby projects. Why build on GCC when you can build
| on LLVM, and ensure that there'll be no legal problem
|
| Modern copyleft licenses are ever-more-strained legal
| contortions to make a _design_ that 's no longer very
| applicable to the modern software IP ecosystem, work for
| it anyway. They're licenses with epicycles.
|
| Sure, I _can_ in fact link AGPLed and LGPLed system
| libraries in my language runtime; and in a pinch -- if
| there 's no equally-good alternative -- I'll take the
| time, work out the precise legal implications, and go
| ahead with it.
|
| But if there's a BSD or MIT-licensed (or even Apache-
| licensed) alternative to those libraries? I'll choose
| that one. Because, in the modern landscape, by doing so,
| I'm saving myself, my future self, and my future
| hypothetical SaaS's future hypothetical lawyers, a lot of
| time and effort.
| proddata wrote:
| > This begs the question: isn't "a restrictive OSS licence"
| not less "fully open source" than a more permissive licence
| like GPL, MIT or BSD?
|
| We gonna change CrateDB fully to Apache License v2 ;) I
| would say that counts as a "more permissive" license.
|
| > Is that really only because of some enterprises not
| liking GPL?
|
| There are various reasons for the change. A big part is
| definitely also the spirit of many our contributors. We
| built CrateDB on open source software and also want to make
| the software available as open source. It also was planned
| for quite some time to be more open.
| tracker1 wrote:
| MySQL is a poor example... for a while, their client library
| license was GPL and insisted that anything not using a
| commercial license needed to be GPL, which is one of the
| reasons I pushed against MySQL for a long time, one of a long
| list of reasons over the years.
| temp667 wrote:
| PostgreSQL is explicitly NOT GPL (it's basically a very
| permissive BSD / MIT style license). More here:
| https://www.postgresql.org/about/licence/
|
| See section and links for "Why not the GNU General Public
| License?"
|
| It's not GPL for some of the same reasons described here and
| enterprise does like it.
| fartcannon wrote:
| Hmm, I went to go find the 'why not GPL' section but they
| just say, 'because' and then link to their mailing lists..
| but not (as far as I can see) to the relevant thread. Do you
| happen to know where it's located? Is there not an html
| version somewhere?
| temp667 wrote:
| I think they got tired of having folks argue with them
| about the license.
|
| In short though - was developed at berkeley so released
| under a BSD license. The license has served them well
| (there are a lot of commercial entities supporting
| postgresql development, and lots of others with various
| forks). And finally, it would be hard to change at this
| point and they don't see a gain.
|
| A note - in contrast to Elastic, there is no one copyright
| holder with postgresql. So this makes it much hard to get a
| relicense to for example a situation where one commercial
| entity has a special right to the terms / relicensing
| power.
| ArchOversight wrote:
| > It sounds like they are making up excuses for not wanting to
| fully Open Source their code; which is fine. But don't blame
| upstream for your reluctance or inability to adhere to this.
|
| They are changing the license on ALL of their source code. How
| is this making up excuses?
|
| Second, I know plenty of companies where MySQL or Wordpress are
| not allowed to be used because they are GPL.
|
| PostgreSQL is NOT GPL and thus is allowed.
| ForHackernews wrote:
| > Second, I know plenty of companies where MySQL or Wordpress
| are not allowed to be used because they are GPL.
|
| The fact that some companies have incompetent legal teams
| isn't a good argument against the GPL. There's no reason you
| can't use Wordpress to back a commercial website.
| derefr wrote:
| It's not about "backing a commercial website"; it's about
| selling a solution for your own customers to use, where
| WordPress might be a component of that offered solution,
| customized into being something else (e.g. a control
| panel.)
|
| There are concerns that doing so, in the context of a
| monorepo, might infect your entire codebase -- including
| the components that have nothing to do with the control-
| panel, and so never touch the Wordpress stuff -- with GPL.
|
| Of course, you can architect code to get around that, e.g.
| building your shared architecture that the control-panel
| uses as a library, and then pulling that lib in from your
| isolated Wordpress control-panel codebase. But enterprises
| don't want to be forced into (possibly sub-optimal)
| architectures just because one component legally requires
| it. They'd rather just not use that component, so that
| their architecture can be totally determined by what's best
| for their development.
| ForHackernews wrote:
| Sure, okay, fine.
|
| I realize this is an ideological position (and not
| necessarily a popular one on this board) but that's the
| point of the GPL. If certain companies lose out because
| they're afraid to share, then they have no one to blame
| but themselves.
|
| The pitch is that the world of free software can,
| collectively, build better software for everyone sharing,
| than the proprietary islands who selfishly cut themselves
| off from that ocean.
| ArchOversight wrote:
| It's a risk assessment calculation, and usually the
| lawyers make that call.
|
| At a previous company I worked at legal considered it
| cheaper to reinvent the wheel if necessary to avoid GPL
| software than to potentially have to deal with a lawsuit
| around GPL being used in our software.
|
| Even LGPL software was considered off-limits, because one
| wrong linker flag and now it's statically linked into the
| resulting binary...
| e12e wrote:
| > We would never have chosen Elasticsearch in the first place,
| had it been licensed under the GPL as some of our customers
| (and many large enterprises do by default) banned GPL licensed
| software from their application stacks for legal risks.
|
| So, they don't run Linux, don't use glibc? That can't be all
| that common? (I mean sure, there's the bsds.. But still..).
| proddata wrote:
| > So, they don't run Linux, don't use glibc? That can't be
| all that common? (I mean sure, there's the bsds.. But
| still..).
|
| We do run Linux :)
|
| But there is a difference between building on and building
| with.
| temp667 wrote:
| The Elasticsearch SPPL is going to be pretty incompatible with
| many or most contributors business models and personal needs. The
| question is will the community harmonize around 1-2 forks or will
| the there not be enough critical mass in a fork to keep things
| going.
| jasontedor wrote:
| Jason from Elastic here.
|
| I want to clarify one aspect here. Elasticsearch and Kibana
| will be dual licensed under the Elastic License or the SSPL
| license, not _only_ SSPL. The distributions that we provide
| will be licensed under the Elastic License, which does not have
| the copyleft requirements that are sometimes concerning to
| legal teams.
|
| That is, if you download our distribution and run it in your
| infrastructure, you are subject to the Elastic License. The
| same license that most (90%+) of our users are already running
| under today, when they download our default distribution from
| elastic.co. This is why we say the vast majority of our users
| are not impacted by this change.
|
| Note: we are considering making changes to the Elastic License
| to simplify it. Please see more on our [blog][0].
|
| Disclaimer: I am on the Elasticsearch team and work for
| Elastic; I welcome any and all feedback.
|
| [0]: https://www.elastic.co/blog/license-change-clarification
| temp667 wrote:
| Sure.
|
| The Elastic license is also a change from Apache 2.0, and is
| also not an OSI approved license as far as I am aware.
|
| Doesn't the elastic license specifically limit use of
| software to basic features, prohibit modification of
| licensing control mechanisms etc. I haven't dug through it,
| but it seemed FAR FAR different than a normal open source
| license.
|
| One question I had - is the Elastic license transferable? Ie,
| if you run a startup and are bought out with an asset buyout,
| can you transfer the stack including the Elastic licensed
| software to the acquiring party (assuming in the interim
| elastic has ceased to offer new elastic licenses so they
| can't get their own). Can you sell software built out on
| elastic licensed code and transfer the elastic license to the
| users so they can also use it? Or does everyone need to go
| back to elastic to get these licenses.
|
| A lot of discussion about being open, but reading the details
| - seems far from open at first glance.
| Xylakant wrote:
| How is the elastic license any more compatible with the needs
| of other open source projects than the SSPL? Before,
| elasticsearch and/or kibana were usable together with (A)GPL
| licensed code. That's no longer the case, neither under SSPL
| nor under the elastic license.
|
| The fact that most users use the basic license may well be
| explained by two things:
|
| A) Your website offers it as the primary download.
|
| B) Elasticsearch without the basic licensed modules lacks
| severely when it comes to security features. It doesn't even
| offer basic auth, let alone TLS or similar.
| jillesvangurp wrote:
| The real question is whether Elastic will continue the benefit
| of externals creating pull requests against their (now) non OSS
| code base. I for one have some reservations about that. Kind of
| the whole point of having an OSS code base is getting externals
| to put in their time and effort.
|
| I'm hardly a major contributor but I have provided some fixes
| over the years. This license is a bit of a deal breaker for me
| and I'm not likely to volunteer more time on this. I charge
| premium rates for commercial software development. I'm sure
| most bigger companies would also not be very eager to put any
| time and effort into this code base under this license where in
| the past this would have been less controversial with e.g.
| legal departments doing due diligence.
|
| No amount of "clarifications" is going to fix that. It's not a
| problem of people stubbornly misunderstanding: it's people
| disagreeing with them. They'll be dealing with negative press
| and FUD for years to come around essentially any press release,
| announcement, or other bit of news in the foreseeable future.
| IMHO it's actually bad for business. And it seems the stock
| price is trending down the last few days; so maybe it's not
| just me. Not to late to correct this mistake, just saying. I
| assume share holder value was the driving force here. Not
| served by any of this apparently.
|
| As for forks, I don't think Amazon has the right people
| currently to do anything more than very minor/trivial updates.
| I doubt that they will fix this by putting a large product team
| together to actually try to innovate. That would involve
| poaching people from Elastic or other projects. Easy to
| predict, because so far they haven't in the two years of
| opendistro having been around. I don't know about crateDB but I
| think they are a fair bit smaller than Amazon; so it's doubtful
| they can keep up much. I guess for them, the key thing is
| actually keeping up with Lucene updates.
| jwildeboer wrote:
| Red Hatter speaking. You can be quite succesful with GPL licensed
| code. #justsayin
| galkk wrote:
| This is the great, concise callout that is clearer than hundreds
| of messages in HN discussions.
| rafaelturk wrote:
| Kudos! Highly recommended article [1] about what the ES move
| realy means
|
| 1.
| https://anonymoushash.vmbrasseur.com/2021/01/14/elasticsearc...
___________________________________________________________________
(page generated 2021-01-27 23:00 UTC)