Ferdy wrote:Note that item (a) refers to copied code from other author which is inside the participating program, and item (b) refers to copied ideas from others which is inside the participating program. I just consider here, copied ideas equals derived codes.
Not necessarily. If your program has the idea of LMR in it, and you implement that LMR in a certain way, and I read your source code and learn that idea and then go back to my program and implement LMR in a very similar (even identical) way, that does not necessarily mean my code is a derivative.
At the other extreme, if I copy a large chunk of your code (e.g. your pv search routine) then that would be derivative.
In the middle is a large grey area where its hard to tell what should count as a derivative and what shouldn't. In copyright law in the U.S., they use something called the
Abstraction-Filtration-Comparison test. The idea is to screen out the parts that aren't novel enough to deserve copyright protection (e.g. things that are just facts, or bits of code that needs to be that can only be practically written in one way because of requirements like interoperability) and then compare whatever's left. Courts will take into account the amount of protectible code that appears to have been copied, and the relative importance of those copied parts of the whole.
In cases of blatant copying, if you compare the two programs, the copied parts are usually obvious. But with derived works, its much harder to tell.
In the case of Rybka 1.0 Beta, the eval of Fruit 2.1 was translated to bitboards, so it was not just a copy-and-paste of the code. Also, we did not have the Rybka source code to look at, so the comparison was done the hard way: by reverse-engineering the Rybka binaries. This work was largely done by Zach Wegner and Mark Watkins. They produced annotated disassemblies showing what each routine was doing, and these were then compared to the equivalent routines in Fruit 2.1. Structurally, they turned out to be very similar: e.g. they both had nearly all of the same eval features, in the same order. There was enough evidence to conclude that Rybka 1.0 Beta's eval was derived from Fruit.
But what about, e.g. Rybka vs. Ippolit? Many people suspect Ippolit is derived from a reverse-engineered Rybka, but it might be quite hard to prove it. Everything has been modified in the Ippolit code. It's not easy to point to any single part of the code and show that its directly derived from Rybka. When reading the code though, it just feels Rybka-like to me. But a feeling is not evidence.