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