This is the commit containing the code that Elastic says was copied by Search Guard:<p><a href="https://github.com/floragunncom/search-guard-enterprise-modules/commit/93b491a182c2f8ff4d0b7ac72cb4bda0c6eb12d2" rel="nofollow">https://github.com/floragunncom/search-guard-enterprise-modu...</a><p>In particular, the change to getLiveDocs(): <a href="https://github.com/floragunncom/search-guard-enterprise-modules/commit/93b491a182c2f8ff4d0b7ac72cb4bda0c6eb12d2#diff-1e087c32ad166566456e9a43991a57caR407-R429" rel="nofollow">https://github.com/floragunncom/search-guard-enterprise-modu...</a><p>and numDocs():
<a href="https://github.com/floragunncom/search-guard-enterprise-modules/commit/93b491a182c2f8ff4d0b7ac72cb4bda0c6eb12d2#diff-1e087c32ad166566456e9a43991a57caR437-R469" rel="nofollow">https://github.com/floragunncom/search-guard-enterprise-modu...</a><p>EDIT:<p>At least in the case of numDocs(), both Elastic and Search Guard's implementations seem to be based on this bit of Apache-licensed code from Lucene (or perhaps this is just a common pattern for counting live documents?):<p><a href="https://github.com/apache/lucene-solr/blob/branch_6_3/lucene/misc/src/java/org/apache/lucene/index/PKIndexSplitter.java#L146-L158" rel="nofollow">https://github.com/apache/lucene-solr/blob/branch_6_3/lucene...</a>
Unfortunately, since June 2018, we have witnessed significant intermingling of proprietary code into the code base. While an Apache 2.0 licensed download is still available, there is an extreme lack of clarity as to what customers who care about open source are getting and what they can depend on. For example, neither release notes nor documentation make it clear what is open source and what is proprietary. Enterprise developers may inadvertently apply a fix or enhancement to the proprietary source code. - from amazon's opendistro announcement.
Search Guard site is here: <a href="https://search-guard.com/company/" rel="nofollow">https://search-guard.com/company/</a><p>My gut feeling here is that Elastic is probably right. The SQ team is very small, while that doesn't mean anything it does make you wonder.<p>On the other hand, does anyone know if a company that small has any viable way to defend themselves against someone with deep pockets like Elastic?
Those are some bold accusations. Looking forward to hearing the response from Search Guard. I wonder if there were attempts to resolve this quietly before going to the courts (and blogs).
I was working with first ElasticSearch versions when Shay was the only developer. At that time, I was impressed how Shay was responsive, friendly and overall ES had good design, compared to Katta [1] we used in our product.<p>ES was my go-to search engine since, but something fishy started to happen with elastic.co from 2018. They changed the license, started to use dark patterns for downloads and product names and this message from Shay, where he invites Search Guard users to use 'free security features' (which aren't free at all) from elastic.co, is low blow, not for Search Guard devs/users, but for ES users as well. If I develop a custom plugin for ES and charge support for enterprise users, how will I know they will not come after me simply because they have similar addon?<p>As one comment noticed, alleged code is too common and can be found in Lucene as well.<p>I'm hoping this will end well, but elastic.co brand isn't going to be the same.<p>(Also, elastic.co isn't immune to taking over other work as well [2]).<p>[1] <a href="http://katta.sourceforge.net/" rel="nofollow">http://katta.sourceforge.net/</a><p>[2] <a href="https://discuss.elastic.co/t/vector-modules-going-apache-xpack-license-despite-community-help/197335" rel="nofollow">https://discuss.elastic.co/t/vector-modules-going-apache-xpa...</a><p>EDIT: added link to vector module issue
From a first impression, this seems entirely reasonable.<p>It is unfortunate when "freemium" companies hide essential features like security behind their paywall, and I don't love Elastic for doing that, but code copying is code copying.
We have analyzed the claim, and it has no merit.<p>Out of 10s of thousands of code they're bringing just a few snippets here and there which frankly only deal with APIS (netty, Lucene) in a way that is simply normal to do.<p>A shameful FUD, Looking forward to read the official rebuttal.
I am not sure about the merits of the case to comment on this directly (blog post is sparse on details), but this is certainly unfortunate for the ElasticSearch community.<p>I want to share Arc - <a href="https://github.com/appbaseio/arc" rel="nofollow">https://github.com/appbaseio/arc</a>, an API gateway for ElasticSearch with security features that we have been actively developing starting this year. It's Apache 2.0 licensed, built in Go and we use it for providing security features for all of our customers. It's not as feature-rich as X-Pack / SearchGuard today, but we're happy to accept any PRs.
It's already known elastic made elastic search code base proprietary. So if anyone who uses their distribution without proprietary license will likely be sued.<p>It's very difficult in a mixed proprietary and open source code to figure out which one and which one is not proprietary. Also given the terms and conditions and license text is written broadly, it can be changed at will.<p>I will not side with sun guard or elastic here. Use Vespa or solr or some other software if one wants to use open source. Don't touch ELK with encumbered license.
> Whether open source or proprietary, any responsible creator must protect their work.<p>What does that even mean in this context? It seems to just be there to have the subtext "So don't blame us for not being open source, we would be doing something like this even if we were!"<p>Which isn't entirely true. If the code were released under an open source license, someone else could copy it so long as they respected the license. So you wouldn't be suing someone for copying your code; you might for violating your license. Hard to say if the alleged infringer would have been happy to copy the code with an open source license, who knows.<p>Not saying it's "okay" to copy proprietary code (for varying definitions of okay), just challenging the implication that "this has nothing to do with it being open source or not" -- it surely does. And I can't see any point of that otherwise nonsequitor statement except that implication.
It seems a special kind of doublethink to release some software as free and some as proprietary.<p>Software isn’t property, and applying property rights to it is fundamentally unjust. This is the point of free software.<p>To then turn around and also license proprietary software simultaneously means that you were doing free software for the wrong reasons entirely.