Doubling down on permissive licensing and the Elasticsearch lockdown(crate.io)
crate.io
Doubling down on permissive licensing and the Elasticsearch lockdown
https://crate.io/a/cratedb-doubling-down-on-permissive-licensing-and-the-elasticsearch-lockdown/
94 comments
> We shouldn't take anyone seriously who promulgates a license but won't use it themselves in an inbound=outbound way.
I would just treat them as proprietary. With access to code and opened gate to provide also code, if you are paying someone and they still do not care about your bug.
What may be better than fully proprietary and unavailable source.
I would not dismiss for example Windows just because they are not open source.
I would just treat them as proprietary. With access to code and opened gate to provide also code, if you are paying someone and they still do not care about your bug.
What may be better than fully proprietary and unavailable source.
I would not dismiss for example Windows just because they are not open source.
It's worth noting that Crate isn't contesting that SSPL is a perfectly legitimate open source license, it's the GPL part that's the issue for them.
GPL and AGPL are just as much used to "poison the well" for potential competitors to a product also released as open source, and dual licensing strategies are a well-known part of open source businesses. This hasn't changed with SSPL at all, there's just a lot of pearl-clutching about the fact that the high and mighty OSI has not signed off on it.
GPL and AGPL are just as much used to "poison the well" for potential competitors to a product also released as open source, and dual licensing strategies are a well-known part of open source businesses. This hasn't changed with SSPL at all, there's just a lot of pearl-clutching about the fact that the high and mighty OSI has not signed off on it.
> GPL and AGPL are just as much used to "poison the well"
But it is also legitimately outside of the purpose as well... unlike the SSPL. The Linux kernel for example. No one has ever looked at the SSPL and said “I want to work on that project” unlike the the GPL, which I believe is the GP’s point.
> There is no one on the planet yet who has agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License.
But it is also legitimately outside of the purpose as well... unlike the SSPL. The Linux kernel for example. No one has ever looked at the SSPL and said “I want to work on that project” unlike the the GPL, which I believe is the GP’s point.
> There is no one on the planet yet who has agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License.
Many of the people who are enthusiasts for the GPL should be similarly enthusiastic about the copyleft protections afforded by the SSPL. It, like the GPL, discourages commercial use by encouraging users of the software to open source any software they want to build on top of this software.
RMS would not be upset that the GPL poisons the well because companies don't want to open source their code, RMS would say they are denying user freedoms by failing to open source their code. The SSPL merely builds on this.
The only real sticking point here seems to be the OSI, and probably some manner of lobbying by tech firms to keep the SSPL from being accepted more widely as an open source license.
RMS would not be upset that the GPL poisons the well because companies don't want to open source their code, RMS would say they are denying user freedoms by failing to open source their code. The SSPL merely builds on this.
The only real sticking point here seems to be the OSI, and probably some manner of lobbying by tech firms to keep the SSPL from being accepted more widely as an open source license.
Isnt sspl just agpl with "addtional" requirement only if you are a cloud service provider just for the benefit of their users? If am an end user of say Amazon, am I not getting more freedoms with respect to the source code of Amazon stack? Isnt that GPL is supposed to provide ?
"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."
Doesn't particularly specify what type of business you have to be running, though it's obviously partially related to whatever type of software you licensed under the SSPL.
The GPL affects projects which embed GPL code into them, and the SSPL effectively does the same, it just draws the borders wider, to anything used to provide it as a service to others. In a copyleft sense, that promotes providers of it to also contribute to the ecosystem of tools around it.
Doesn't particularly specify what type of business you have to be running, though it's obviously partially related to whatever type of software you licensed under the SSPL.
The GPL affects projects which embed GPL code into them, and the SSPL effectively does the same, it just draws the borders wider, to anything used to provide it as a service to others. In a copyleft sense, that promotes providers of it to also contribute to the ecosystem of tools around it.
I dont think GPL forces anyone to contribute upstream. I am asking about the idea of freedom the end user enjoys with GPL code.
Does sspl build on it, give more freedom to end user or restrict that freedom.
If it gives more freedom, isnt that a good thing ? Why should people be up with pitchforks ?
> like the GPL, discourages commercial use
Comments of this sort was comme il faut in the 90s. But now, more than two decades later, GPL has proven its commercial value so many times over it's hard to take such arguments seriously.
Tit-for-tat business models grow faster than those staking out islands. Linux won. We need to move on from this.
Comments of this sort was comme il faut in the 90s. But now, more than two decades later, GPL has proven its commercial value so many times over it's hard to take such arguments seriously.
Tit-for-tat business models grow faster than those staking out islands. Linux won. We need to move on from this.
By "discourages commercial use", I refer to the very-real-today fact that plenty of organizations won't touch GPL or especially AGPL code because of the copyleft restrictions. This is largely the same for SSPL.
Amazon could use SSPL-licensed Elasticsearch on AWS, if they wanted to open source AWS, and they'd probably still make bank on it. But they don't want to, so hence going to SSPL, like GPL, discourages their use.
Amazon could use SSPL-licensed Elasticsearch on AWS, if they wanted to open source AWS, and they'd probably still make bank on it. But they don't want to, so hence going to SSPL, like GPL, discourages their use.
I think that nails it.
I will happily contribute to a permissively-licensed code base for a project, although I'm aware that my contributions might be used in some closed-source platform later on. Exchanging my contributions for the ability to do whatever I want with the software is a reasonable trade.
I'm also willing to contribute to projects using copyleft licenses, on the basis that a project that requires all contributors to leave all of their contributions and derivatives of the product in the open offers a fair playing field.
I am way less interested in contributing to this new breed of semi-open projects, which require me to sign over my contributions in exchange for access under a license which stops me from using the project in certain ways, but grants one entity special privileges to use it in that way.
I think the evidence suggests that both GPL and permissively-licensed projects can be wildly successful. There are good reasons for both approaches, with different benefits and trade-offs. It's also legitimate to be irritated at "bad neighbours" who take without contributing back. I'm not convinced that this semi-open licensing approach is a benefit to anyone.
I will happily contribute to a permissively-licensed code base for a project, although I'm aware that my contributions might be used in some closed-source platform later on. Exchanging my contributions for the ability to do whatever I want with the software is a reasonable trade.
I'm also willing to contribute to projects using copyleft licenses, on the basis that a project that requires all contributors to leave all of their contributions and derivatives of the product in the open offers a fair playing field.
I am way less interested in contributing to this new breed of semi-open projects, which require me to sign over my contributions in exchange for access under a license which stops me from using the project in certain ways, but grants one entity special privileges to use it in that way.
I think the evidence suggests that both GPL and permissively-licensed projects can be wildly successful. There are good reasons for both approaches, with different benefits and trade-offs. It's also legitimate to be irritated at "bad neighbours" who take without contributing back. I'm not convinced that this semi-open licensing approach is a benefit to anyone.
> I'm not convinced that this semi-open licensing approach is a benefit to anyone.
It may be better than fully closed source? Just that it should be self-described as proprietary, with source available.
It may be better than fully closed source? Just that it should be self-described as proprietary, with source available.
> 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.
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.
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.
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.
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?
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.
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.
That doesn't sound quite right: MIT/BSD licenses are GPL compatible; you could trivially release MIT code under the GPL. I believe that's what https://www.hyperbola.info/ is doing, for example.
It's compatible, but if Postgresql wanted to go harder copyleft and switch the license for future releases, they'd need to get pretty broad agreement, and that would be difficult, there are a lot of corps / enterprise players in the ecosystem, and things like (a)GPLv3 are often totally banned. Is GPLv3 software even allowed in the Apple iphone App Store? The Windows Phone app store?
GPL is a big hammer you can use to force back contribution into the project and ensure that folks that use the software actually contribution to it continuing to be available and relevant - if Postgres has been able to sustain themselves for all these years with a more permissive license then why would they risk going GPL and scaring off a lot of their customers just to ensure that each customer that remains can be forced to back-contribute any innovations they make.
(please note that GPL doesn't in actuality force anyone to back-contribute but in effect it tends to work that way - it actually puts a lot of responsibility on the original authors to re-acquire improved versions of the library but it does ensure that those improved versions are accessible in some manner)
(please note that GPL doesn't in actuality force anyone to back-contribute but in effect it tends to work that way - it actually puts a lot of responsibility on the original authors to re-acquire improved versions of the library but it does ensure that those improved versions are accessible in some manner)
GPL does not necessarily ensure that those improved versions are accessible to the original project, people receiving the source code to improved versions could simply keep those versions secret. See the controversy around grsecurity for an example of this, although one old version of their code did get leaked.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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...
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...
> Even LGPL software was considered off-limits, because one wrong linker flag and now it's statically linked into the resulting binary...
Then, to get compliance, you just have to fix the linker flag. Providing the source code is not the only way to get compliance.
Then, to get compliance, you just have to fix the linker flag. Providing the source code is not the only way to get compliance.
I think they're suggesting that the statically-linked version of the binary might have ended up published as a release to the public Internet. At which point, it's unclear whether it's possible to "undo" the copyleft infection simply by "unpublishing" the release. People have already potentially downloaded the "infected" release.
Once you are in violation, you have two ways to fix it: stop publishing the software with the violation (and, optionally, publish a version without the violation instead) or give access to the source code. The main problem with accidental violation is that, with GPLv2, you need to have an agreement with the copyright holder to unterminate your license. With GPLv3, you have a grace period and major copyright holders (like Redhat) told they would also use a grace period for GPLv2.
[deleted]
> 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.
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.
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?
> 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?
> 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.
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.
> 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.
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.
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.
• 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.
The distinction between GPL and LGPL seems completely lost on you.
LGPL existed since 1991. Also large libraries and frameworks.
LGPL existed since 1991. Also large libraries and frameworks.
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.
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.
Re:
> it was to inhibit Cathedral-style codebases from using GPLed software at all.
I'm surprised at the notion that RMS ever had the intention of inhibiting GPL use in Cathedral-style codebases. And I agree with others that big frameworks existed back then also.
I'm surprised at the notion that RMS ever had the intention of inhibiting GPL use in Cathedral-style codebases. And I agree with others that big frameworks existed back then also.
Especially since the term cathedral was popularized by esr to call out the development style of the GNU project.
Sure, big frameworks existed back then, but they were all either
1. literally "frameworks" in the inversion-of-control sense — where your code is a script that runs "inside" the framework — and you don't ship the framework to your customers as part of your product, but rather walk them through getting it from its own vendor as a prerequisite step to installing your product (e.g. TeX); or
2. proprietary, not copyleft-licensed (e.g. game-console SDKs.)
If anyone has a good counter-example, I'm all ears :)
1. literally "frameworks" in the inversion-of-control sense — where your code is a script that runs "inside" the framework — and you don't ship the framework to your customers as part of your product, but rather walk them through getting it from its own vendor as a prerequisite step to installing your product (e.g. TeX); or
2. proprietary, not copyleft-licensed (e.g. game-console SDKs.)
If anyone has a good counter-example, I'm all ears :)
>Instead we got locked-down privacy-breaching smartphones, IoT devices, SaaS, where only the manufacturer benefits from OSS.
You forget the user.
You forget the user.
i will bite.
How does the user benefit from having a phone built on top of open source software, that they cannot update a well known security vulnerability because the manufacturer can't bother to run a build with the last upstream version?
How does the user benefit from having a phone built on top of open source software, that they cannot update a well known security vulnerability because the manufacturer can't bother to run a build with the last upstream version?
> How does the user benefit from having a phone built on top of open source software, that they cannot update a well known security vulnerability because the manufacturer can't bother to run a build with the last upstream version?
Well, depending on the incentives and restrictions involved, an ecosystem of 3rd-party builds is a potentially viable escape hatch for the user from the manufacturer's grip.
Of course the sticking point is the degree to which the hardware requires proprietary and opaque binary blobs in order to enable important user-facing features. But then, that isn't anything really new, as open source PC operating systems have been dealing with this issue since forever, with the caveat that PC hardware is mostly modular, so having or swapping in well-supported components is an option, whereas smartphones are an integrated slab of metal, plastic, and glass, with "no user serviceable parts inside" as the status quo.
But even that caveat has precedents, in non-PC devices such as consumer networking gear that only became well supported through aggressive GPL license enforcement actions that freed some of the necessary code.
Well, depending on the incentives and restrictions involved, an ecosystem of 3rd-party builds is a potentially viable escape hatch for the user from the manufacturer's grip.
Of course the sticking point is the degree to which the hardware requires proprietary and opaque binary blobs in order to enable important user-facing features. But then, that isn't anything really new, as open source PC operating systems have been dealing with this issue since forever, with the caveat that PC hardware is mostly modular, so having or swapping in well-supported components is an option, whereas smartphones are an integrated slab of metal, plastic, and glass, with "no user serviceable parts inside" as the status quo.
But even that caveat has precedents, in non-PC devices such as consumer networking gear that only became well supported through aggressive GPL license enforcement actions that freed some of the necessary code.
You guys are missing the point that some company already cornered the market by using open source code and not contributing back their work. they have a head start from everyone that can ever be involved.
They can backport the patch for the security fix themselves and rebuild the old version, or band together with other users to do the same.
that would be a full GPL compliant product, which is not what the comment was talking about.
Someone said companies use GPL software, add their business logic or drivers, and never contribute back: e.g. android phones.
Then someone else said the insane thing that the user benefits.
I pointed out that if there is a security flaw, you CANNOT build/path because you do not have all the source (e.g. alternative android OS cannot use the camera or radio for lack of kernel drivers)
Someone said companies use GPL software, add their business logic or drivers, and never contribute back: e.g. android phones.
Then someone else said the insane thing that the user benefits.
I pointed out that if there is a security flaw, you CANNOT build/path because you do not have all the source (e.g. alternative android OS cannot use the camera or radio for lack of kernel drivers)
Your post above doesn't mention GPL compliance, only vendors using ancient versions of open source code. If you don't have the source, of course you can't do anything. So you ask the vendor for source and if they refuse then you contact the Linux kernel community to enforce GPL compliance. At some point the source will come out, even if the vendor has to get sued in order to do it.
https://sfconservancy.org/copyleft-compliance/
https://sfconservancy.org/copyleft-compliance/
The user does not care, he throws it away. But the user cares about having a good operating system and good apps and those are built on OSS.
No, I did not forget the user. The user is the victim.
Can you clarify why the GPL doesn't work for you. Clearly you release all the source code for your product. Is it that you have downstream customers that make modifications to your source code, and they don't want to have to release their changes for their products?
Yes, we have customers using CrateDB as part of their proprietary product.
Also the SSPL is so vague, that we probably would not only have to release CrateDB itself - which we already do, but also everything we use for the services we provide. Also we could never make any kind of deals with OEMs, etc.
Also the SSPL is so vague, that we probably would not only have to release CrateDB itself - which we already do, but also everything we use for the services we provide. Also we could never make any kind of deals with OEMs, etc.
> 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..).
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..).
> 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.
We do run Linux :)
But there is a difference between building on and building with.
The problem is not using a GPL software internally, but using it in a product that you'd want to sell and at this point be forced to opensource your entire product.
Despite what some people like to pretend there's basically no scalable business model outside of SaaS that will make you any money selling GPL-licensed software so this situation is extremely undesireable.
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.
> 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.
I think they appear to be surviving just fine - they are switching forks not shuttering their doors or even withdrawing ES compatibility.
Suddenly changing licenses to increase how restrictive it is absolutely is a nightmare scenario to a lot of businesses and it quite rationally is so. We share software and build on each other's shoulders, to reject that and build everything from scratch is silly and fiscally irresponsible.
I'm very confused why this is so strongly stated when it's likely that most of us have, at one point, sat down with two pieces of libraries and gone with the less useful one due to licensing issues.
I think they appear to be surviving just fine - they are switching forks not shuttering their doors or even withdrawing ES compatibility.
Suddenly changing licenses to increase how restrictive it is absolutely is a nightmare scenario to a lot of businesses and it quite rationally is so. We share software and build on each other's shoulders, to reject that and build everything from scratch is silly and fiscally irresponsible.
I'm very confused why this is so strongly stated when it's likely that most of us have, at one point, sat down with two pieces of libraries and gone with the less useful one due to licensing issues.
GPL has the well-known web services loophole, that effectively makes copy-left protections moot. Without that, Wordpress and other GPL-licensed web CMS/frameworks would never have taken off like they have.
As for MySQL, notice how no one builds anything on top of it (like TimescaleDB and others did with PostgreSQL), but just uses MySQL as-is without modifying it, also rendering copy-left moot.
As for MySQL, notice how no one builds anything on top of it (like TimescaleDB and others did with PostgreSQL), but just uses MySQL as-is without modifying it, also rendering copy-left moot.
>> 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
I work in a consultancy for enterprise-scale customers - every.single.one prohibits the use of GPL libraries and frameworks.
> Which is completely new to me
I work in a consultancy for enterprise-scale customers - every.single.one prohibits the use of GPL libraries and frameworks.
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?
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.
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.
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?
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.
For about 6 years of that past decade it has been a major offering of AWS. You can't claim it would be as popular without AWS by just pointing to it's popularity during the period of time that AWS has used it. A significant amount of it's current popularity occured after AWS began offering it.
Even without that, how many would have adopted it without it's permissive licenses? Probably none of the major cloud offerings, which would have severely limited growth given the continuing sig ificant shift from on-prem to cloud during that period of time.
Even without that, how many would have adopted it without it's permissive licenses? Probably none of the major cloud offerings, which would have severely limited growth given the continuing sig ificant shift from on-prem to cloud during that period of time.
It was pretty popular before AWS had it as SaaS. Not everyone needs it, of course.
Well, consequently a huge portion of computing has migrated to the cloud since 2014. But we were running ES in prod on self hosted instances back in 2012. It was very well known then. With or without Amazon's ES service it would have thrived. The reality is, ES solves a core problem for application developers. If you have that problem and you need indexed search capability, you go find it, because building it yourself is difficult and time consuming to do. Agreed that permissive licensing was a big part of its adoption, but people would just be putting it on EC2 themselves without Amazon's managed offering (and many probably still are).
It's not about whether it would have thrived without AWS, it's about 1) Would it have thrived at all under a more restrictive license that could have reduced adoption; 2) During it's old license, did it thrive more than it would have without AWS adoption.
Counterfactuals like this are difficult to answer. However, more permissively licensed software does seem to reach widespread adoption more easily. Elastic's download rates seem to have approached hockey stick growth trend around the time of AWS adoption, and Elastic's revenue significantly increased afterwards as well. It might have been on track for that anyway, but 5 years of linear growth did turn sharply upwards around AWS.
It seems like Elastic as a company has a decent probability of faster growth and more revenue due to market penetration and name recognition assisted by AWS usage.
Had Elastic been restrictive.from the start, it's entirely possible that the industry would have focussed on and driven improvements in something like solr instead. As you said, elastic solved problems people had, it's not unreasonable to think they would have solved them some other way without elastic.
Counterfactuals like this are difficult to answer. However, more permissively licensed software does seem to reach widespread adoption more easily. Elastic's download rates seem to have approached hockey stick growth trend around the time of AWS adoption, and Elastic's revenue significantly increased afterwards as well. It might have been on track for that anyway, but 5 years of linear growth did turn sharply upwards around AWS.
It seems like Elastic as a company has a decent probability of faster growth and more revenue due to market penetration and name recognition assisted by AWS usage.
Had Elastic been restrictive.from the start, it's entirely possible that the industry would have focussed on and driven improvements in something like solr instead. As you said, elastic solved problems people had, it's not unreasonable to think they would have solved them some other way without elastic.
> people would just be putting it on EC2 themselves without Amazon's managed offering
Which seems to negate the core argument Elastic is giving for the change.
Which seems to negate the core argument Elastic is giving for the change.
I'm not saying I agree with Elastic's change at all. I'm just saying that their success is not due to Amazon.
I put that into the unknowable column. If history were different and AWS hadn't used them, perhaps the critical mass wouldn't have happened. Or perhaps it would have.
Red Hatter speaking. You can be quite succesful with GPL licensed code. #justsayin
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.
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.
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.
> The real question is whether Elastic will continue the benefit of externals creating pull requests against their (now) non OSS code base.
SSPL is still open source, it's just aggressively copyleft. (Note that Crate is upset about them going GPL, not going SSPL.)
As for the question, depends how much their code diverges... Shoudln't be any reason Elastic can't continue to absorb contributions made to Amazon's Apache-licensed fork, until they move too far apart for the code to be relevant.
SSPL is still open source, it's just aggressively copyleft. (Note that Crate is upset about them going GPL, not going SSPL.)
As for the question, depends how much their code diverges... Shoudln't be any reason Elastic can't continue to absorb contributions made to Amazon's Apache-licensed fork, until they move too far apart for the code to be relevant.
It is not and it never has been.
It's not an OSI endorsed license. Elastic insists on copyright transfers for any code contributions as well, so that makes contributing under a different license not possible (their choice).
Crate is upset because they've created a significant derivative work which complicates their business under the new license. Apache 2.0 is intentionally designed to support this kind of thing; which is why it is a popular license for companies working together on OSS projects.
Copyright transfers like Elastic is practicing are of course a big risk for such companies. IMHO, any such projects has long term challenges. Most long lived OSS projects have a multitude of copyright holders. E.g. re-licensing Linux would be very impractical as it as many thousands of contributors some of whom have passed away (i.e. their families inherited the copyright). That's a strength of that project; it's forever stuck on GPL2, which provides enough wiggle room that the likes of Google, Samsung, and many others can use it to create software for their products.
Amazon's work is of course less significant but this license is designed to prevent derivative works from being likely to succeed commercially. Even Amazon's use which technically did not involve actually modifying the source code (not a single line, they used a binary OSS release provided by Elastic and added plugins) would be illegal under this license. That's not open; sorry.
Crate is upset because they've created a significant derivative work which complicates their business under the new license. Apache 2.0 is intentionally designed to support this kind of thing; which is why it is a popular license for companies working together on OSS projects.
Copyright transfers like Elastic is practicing are of course a big risk for such companies. IMHO, any such projects has long term challenges. Most long lived OSS projects have a multitude of copyright holders. E.g. re-licensing Linux would be very impractical as it as many thousands of contributors some of whom have passed away (i.e. their families inherited the copyright). That's a strength of that project; it's forever stuck on GPL2, which provides enough wiggle room that the likes of Google, Samsung, and many others can use it to create software for their products.
Amazon's work is of course less significant but this license is designed to prevent derivative works from being likely to succeed commercially. Even Amazon's use which technically did not involve actually modifying the source code (not a single line, they used a binary OSS release provided by Elastic and added plugins) would be illegal under this license. That's not open; sorry.
The fact that the OSI has failed as an organization doesn't change that it provides all of the same freedoms the GPL does.
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
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
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.
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.
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.
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.
> when they download our default distribution from elastic.co
1. elastic.co
2. Products
3. Elasticsearch
4. Ignore three buttons, click the link "Or download and get started"
5. Ignore six buttons, click the link "Visit our downloads page"
6. Ignore twenty other links, find "The pure Apache 2.0 licensed distribution is available here." six paragraphs into the 'Notes' section.
7. Download it.
There's your any and all feedback, I'm looking forward to being let know _how_ welcome it was.
1. elastic.co
2. Products
3. Elasticsearch
4. Ignore three buttons, click the link "Or download and get started"
5. Ignore six buttons, click the link "Visit our downloads page"
6. Ignore twenty other links, find "The pure Apache 2.0 licensed distribution is available here." six paragraphs into the 'Notes' section.
7. Download it.
There's your any and all feedback, I'm looking forward to being let know _how_ welcome it was.
That said, amazing that the other 10% apparently tracked thought an actual open-source licence was worth it enough to make their way through that.
How do you get to that 90%+ number? I.e. how do you account for installations through Linux distro repos etc (which will likely cease to be an option for most) when describing this? Only counting your downloads is an extremely disingenuous measure of use of open-source software.
And for open-source users things definitively do not "remain as they are", given even your blog post admits it's not an open-source license.
But well, not particularly surprising you don't consider such users as "your users". Disappointing, but not surprising. Good reminder to check the CLAs required by any project I consider using.
And for open-source users things definitively do not "remain as they are", given even your blog post admits it's not an open-source license.
But well, not particularly surprising you don't consider such users as "your users". Disappointing, but not surprising. Good reminder to check the CLAs required by any project I consider using.
Both for DEB and RPM the packages are coming from our own registry (https://artifacts.elastic.co) and not from the Linux distributions. We also maintain our own Docker registry (and mirror that to Docker Hub though they provide some numbers). So we have a good picture about licenses, versions, operating systems,...
Philipp from Elastic.
Philipp from Elastic.
> 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.
This is the most important statement, yet they don't explain why it kills their business model
Also, did I miss something in the SSPL wording? is the consensus really that SSPL equates to GPL? I can see the similarity to GPLv3 in the sense that you have to provide a lot of the environment on which you run the software,but the article just equates SSPL to GPL after the first paragraph, which is a pity imo.
> 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
You should feel fine using GPLv2 in your business, if your are really opensource company (if there is such a thing.) That's really an opinionated statement by someone who doesn't even have business, but please comment; why would they care if they're the ones making the FOSS plugins and will only see changes going back upstream.
This is the most important statement, yet they don't explain why it kills their business model
Also, did I miss something in the SSPL wording? is the consensus really that SSPL equates to GPL? I can see the similarity to GPLv3 in the sense that you have to provide a lot of the environment on which you run the software,but the article just equates SSPL to GPL after the first paragraph, which is a pity imo.
> 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
You should feel fine using GPLv2 in your business, if your are really opensource company (if there is such a thing.) That's really an opinionated statement by someone who doesn't even have business, but please comment; why would they care if they're the ones making the FOSS plugins and will only see changes going back upstream.
This is the great, concise callout that is clearer than hundreds of messages in HN discussions.
That's because Elastic did their own great, concise callout, it's just a little bit hard to find for those not following things closely:
Announcement from 2018:
> "We did not change the licence of any of the Apache 2.0 code of Elasticsearch [...] and we never will"
Edited announcement in 2021:
> "We did not change the licence of any of the Apache 2.0 code of Elasticsearch [...] and we never will¹"
> ¹ [...] we announced a further change to our licensing strategy.
Announcement from 2018:
> "We did not change the licence of any of the Apache 2.0 code of Elasticsearch [...] and we never will"
Edited announcement in 2021:
> "We did not change the licence of any of the Apache 2.0 code of Elasticsearch [...] and we never will¹"
> ¹ [...] we announced a further change to our licensing strategy.
The thing is, that all the arguments they now bring up for the move, have been true in 2018 as well ...
While I have no problem with copyleft licenses (at least those approved by the OSI) and in fact think that they should probably use the AGPL, I commend them for sticking to their guns and commitment to open source.
Kudos!
Highly recommended article [1] about what the ES move realy means
1. https://anonymoushash.vmbrasseur.com/2021/01/14/elasticsearc...
1. https://anonymoushash.vmbrasseur.com/2021/01/14/elasticsearc...
That article makes good points, but doesn't even mention the obvious alternative: join the fork that Amazon immediately announced, the need for which has also been supported by other significant contributors besides CrateDB like Logz.io and Aiven. See https://www.zdnet.com/article/aws-as-predicted-is-forking-el...
SS Public License + CLA is basically Elastic (or Mongo) making their software “open source for me, but not for thee”.
They are free to use the contributions of everyone for any purpose they wish, but everyone else is curtailed and limited.
It’ll be interesting to see if their “eat the cake and have it too” move works. I hope not.
They are free to use the contributions of everyone for any purpose they wish, but everyone else is curtailed and limited.
It’ll be interesting to see if their “eat the cake and have it too” move works. I hope not.
So the conclusion is we need a Apache v2 license with a extra "this software as a service" forbidding clause...
Aside from this particular fracas, it's fascinating to see the proponents of "copyleft" and "permissive" licenses argue again about who is "freer": Elastic announced the license change with a blog post titled "Doubling down on open" (https://www.elastic.co/blog/licensing-change). Then these guys come along with a blog post "Doubling Down on Permissive Licensing and the Elasticsearch Lockdown" which accuses Elastic of "locking down" their code because they switched to a non-permissive license which in their view is "less free".
Reminds me of Trump trying to steal the election by accusing the other side of stealing the election. But in that case it was at least easier to find out who was lying...
Reminds me of Trump trying to steal the election by accusing the other side of stealing the election. But in that case it was at least easier to find out who was lying...
The only thing I haven't seen said succinctly, although it's been hinted at by many, is this:
There is no one on the planet yet who has agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License.
That really says it all. Whatever your view about copyleft licenses generally: legitimate and well-intentioned copyleft licenses (e.g., CC-BY-SA, GPL, and Affero GPL) have many projects that use the license in an inbound=outbound contributor licensing fashion. All (two of the) SS Public License uses have a strict CLA that give the publishing entity non-SS-Public-Licensed rights to the contributions. We shouldn't take anyone seriously who promulgates a license but won't use it themselves in an inbound=outbound way. Period. I suggest we all try to not give further interest to this clearly risible licensing proposals from MongoDB and Elastic.
If there's energy to focus here, I'd say it's toward figuring out how to handle good governance of forks of these two projects. I hope folks can maintain the discipline to discern and bifricate these two very different issues.