[callmeal]

That's a nice way to spread fud, when the complaint is that binary code was decompiled and copied.

>"Most of these instances of copying occurred before we opened our proprietary code last year, which means the Search Guard developers intentionally decompiled our binary releases in order to copy our code."

Hard to see how this could be anything other than deliberate infringement.

[geofft]

So, having read the court case (rather quickly, also thanks to 'Pyxl101 for uploading it to PACER - see https://www.courtlistener.com/recap/gov.uscourts.cand.347725...), my non-lawyer-but-software-engineer opinion is this shows vague signs of being an Oracle v. Google-ish case. Some of the examples of copied code look quite possibly like code where there's only one obvious way to implement them. The functions just use and connect some interfaces in a consistent way, and it might be the sort of thing like rangeCheck where the nature of the problem implies one correct implementation.

There is one suspicious part where there are five strings in a comment in Search Guard that are copied from five strings in X-Pack before X-Pack was open sourced. But that doesn't necessarily imply a decompiler / an attempt to copy X-Pack's implementation: they could have run a tool like 'strings' or even just monitored what APIs are called by X-Pack or something. And the strings in question appear to be API names, i.e., functional elements. I suspect it's possible that floragunn could say they legally reverse engineered X-Pack for the purpose of interoperability instead of decompiling it. On the one hand, if I were them I would stay away from X-Pack with a ten foot pole just so I wouldn't have to worry about it, but on the other hand, in my professional life I do run things like strings and strace and even gdb on closed-source binaries that we don't have a source license to, for the purpose of making them work / seeing why they're failing / etc., and I would be shocked if making use of what I learned from that counts as commercial copyright infringement.

Remember that floragunn's goal here is to produce a plugin that works with Elasticsearch, not a competitor to Elasticsearch as a whole, so it's unsurprising that they'd end up with similarly-shaped functions. And again while I would personally stay away from the product I'm trying to clone, doing so is not legally required - see e.g. Sony v. Connectix, where it was ruled legal for Connectix to copy and even disassemble the PlayStation BIOS for the purpose of producing a compatible reimplementation.

I'd like to see floragunn's defense. I agree it seems difficult for them to have a good one, but it's not impossible, so I'm curious to hear the story in their telling. And I'm also worried about the precedent here, in that there's a world in which Elastic wins the case, morally should have won the case, but also the court phrases it in a way that makes running gdb on proprietary code illegal.

[dvfjsdhgfv]

Elastic may present it this way, but it doesn't need to be. Personally I decompiled different binaries numerous times in order to understand how an implementation works, but it never occurred to me I could "copy" the code somehow - the decompiled version was usually a big mess, so I had to figure out what is essential and reimplement it myself. In may jurisdictions this is perfectly legal. The jurisdictions of the USA and EU explicitly allow decompilation for the sake of interoperability.