3 ms·
Thanks for taking the time to put together such a good argument. I'm afraid that I won't have time to write another reply like this, so if it's not at all convi
by jsnell 15y ago
Thanks for taking the time to put together such a good argument. I'm afraid that I won't have time to write another reply like this, so if it's not at all convincing, we'll just need to agree to disagree.
The first point I'd make is that from the point of view of the investigators, what mattered were not copyright issues but a possible tournament rules violation. So they'd certainly not want to muddle the issue with issues of whether something was copied over verbatim or transcribed. On the other hand my interest is more in the GPL exploitation, since that actually matters outside the insignificant scope of computer chess politics.
It should be absolutely clear e.g. from the comparisons between pre-1.0 Rybka and Crafty that there was verbatim code copying going on. And not only in things like parsing code, but in actual game playing code. There is no other reasonable explanation for having exactly the same dead code around in exactly the same places (for example the double-zeroing bugs, comparisons to funny magic numbers that could never be true).
Also in places where arbitrary decisions needed to be made in the code, they were done exactly the same way as in Crafty (e.g. the numbering of pieces, the ordering of operations during evaluation). Now, this might not be proof of those parts of the code having been copied. It would be totally reasonable to argue that the author, having read the original source code, would naturally make the same arbitrary decisions.
But of course nobody cares about the code of that version of Rybka. It's mainly useful as context for what happened after Fruit was released, followed by a new version of Rybka.
First, there is again evidence of object code that exactly matches that of certain parts of Fruit. For example the command parsing, the decision of when to stop searching, or what to do when a result has been found. These are not as strong evidence of verbatim copying though as for the earlier copying from Crafty, since this code is at best idiosyncratic rather than clearly buggy or useless.
Likewise all of the earlier arbitrary decisions start to be made differently. Piece numbering changes from what was used in Crafty previously what Fruit uses. The main evaluation routine stops doing things in exactly the same order as Crafty did them, and starts doing them in exactly the same order as Fruit did them.
It's not really any longer a reasonable defense that this is just how he'd naturally do things after having read the source code and seen an example. Clearly he already had intimate knowledge with another source code base with different conventions. And even if this was just a matter of being inspired by the Fruit code why would he even be
rewriting all of this non-essential code rather than adding these concepts to his existing codebase.
From a copyright / GPL point of view, I think the argument for copying is fairly strong already at this point, and the question of how large the rewrites to the other code were is irrelevant. From a tournament rules viewpoint, it's the opposite.
So why isn't there equally strong evidence for verbatim copying in the game playing code as in the earlier Crafty case? Because the underlying board representation also changed from the representation used by Fruity to that used by Crafty, making establishing 1:1 correspondence between source and object code harder. So of course we can't reliably tell what kind of process produced this new code, e.g:
(a) modifying the Fruit code in-place
(b) using the Fruit code as a constant guide when writing a new version using a different data structure
(c) reading the Fruit code and then at some later point writing entirely new code
(d) at some point modifying his old code to use the concepts learned from Fruit
From a copyright / GPL point of view I don't think there's much difference between (a) and (b), but I could be wrong. In either case it doesn't seem like a very creative endeavor. Case (d) should be acceptable to anyone, but seems like a remote possibility at best, since the engine lost a number of game playing features of Crafty exactly at the same time as gaining a set matching those of Fruit very well. From a copyright point of view case (c) seems totally fine to me, but from a chess playing creativity point less so. Further, given the established flagrant pattern of copying, it does seem a lot more likely that he would have been taking the expedient road out in this particular instance as well.
I did not find the chessbase article very persuasive due to a few things.
First of all, it was framing the situation of a witch-hunt where a group of jealous sub-peers saw that their only chance of ever being successful again would be to destroy the superior competition by legal means. To an outsider this kind of naked emotional appeal seems very suspicious. Further, trying to suggest that e.g. Ken Thompson would have been motivated by these ulterior motives is just ridiculous.
Second, it's making the argument that really plagiarism is just the accepted custom of computer chess, or at least should be, and that this is therefore selective application of the rules. Knowing whether this is true would require much more intimate knowledge of the computer chess politics than I have any interest in acquiring. However, some of the evidence such as the evaluation feature comparison is certainly suggestive that the level of copying was much more significant in this case than was the norm. Certainly for this verdict to be fair, the reverse engineered and slightly tweaked versions of Rybka should not be allowed to compete in the tournament either.
Third, it tries to establish non-relatedness by the decision dendogram. That's clearly a fallacious argument. A graph like this could show evidence of copying, assuming they were using a sufficiently large amount of positions as input (I presume they did). But it can't possibly be used as evidence of non-copying. That's because a few small changes could easily have an effect on the evaluation results of a large number of positions. Sure, making those small changes are a creative act. But that doesn't mean that the combined work is any less derivative of the original.
Fourth, when discussing the actual evidence, it's considering every bit of evidence totally isolated. "Oh, but it could have happened like this in a totally innocent way". But that's clearly nonsense, you have to consider the totality of the evidence. At some point there are too many coincidences to explain away.
What would convince me to change my mind? It depends on what exactly. I don't think that anything could convince me otherwise of the copyright violations, beyond somebody showing that the investigators lied, and that reported similarities don't exist at all. Of the copyright violations extending to the core evaluation routines? The missing source code would be the best proof, since it could show whether the similarities extended to things like ordering and naming of functions. Of Rybka being unfairly singled out, since everybody was doing exactly the same copying from Fruit? Somebody would need to show that this really happened, and that the other rules violators are getting a free pass.
- dalke 15y agotl;dr - the disassembly for the UCI position/fen parser in the Watkins PDF is clearly NOT a verbatim copy from Fruit. The Watkins disassembly from Rybka does not and cannot match the Fruit source code. I know you don't have much time, but please tell me where I made a mistake in this conclusion! (BTW, I'm taking it as granted that we are talking about copyright issues. I accept that it violates the uniqueness requirement.) I looked again at the parsing code analysis described in http://www.chessvibes.com/plaatjes/rybkaevidence/RYBKA_FRUIT_Mar11.pdf http://www.chessvibes.com/plaatjes/rybkaevidence/RYBKA_FRUIT... . Did you realize that the two codes are different? Fruit does a strstr for "fen " and "moves " while Rybka does a search for "fen" and "moves". Note the difference in the trailing space. Is that a typo in the analysis? Yet there is such furor over the use of a "0." when it should be a "0". I'll assume that the analysis report (and associated disassembly) contain typos. Note then the different call order between those two code snippets. Fruit calls "board_from_fen" only if fen != NULL, while in the disassembled Rybka code, it always calls the labeled "board_from_fen(), for startpos", and if v1 and v3 are not NULL, it calls the same function again. Here's the quoted assembly code, as provided by Watkins: 0x406958: callq 0x40cc40 # strstr call for "fen" 0x40695d: lea 0x25d798(%rip),%rdx # 0x6640fc "moves" 0x406964: mov %rbx,%rcx 0x406967: mov %rax,%rdi # rdi has fen strstr ptr 0x40696a: callq 0x40cc40 # strstr call for "moves" 0x40696f: lea 0x25d74a(%rip),%rcx # 0x6640c0 "rnbqkbnr..." 0x406976: mov %rax,%rbx # rbx has moves strstr ptr 0x406979: callq 0x402980 # board_from_fen("rnbqkbnr...") 0x40697e: test %rdi,%rdi # if fen != NULL 0x406981: je 0x406998* [0x406995] 0x406983: test %rbx,%rbx # if moves != NULL 0x406986: je 0x40698c 0x406988: movb $0x0,-0x1(%rbx) # moves[-1] = 0 The "0x406979: callq 0x402980" is always called, and it doesn't correspond to any code from Fruit. This is important because in the Fruit code, board_from_fen is passed "fen+4", so fen cannot be NULL, which means "callq 0x402980" cannot be the same as "board_from_fen". This means the execution order difference in the above assembly code cannot be the result of a compiler optimization. Which means this assembly code cannot be generated from a verbatim copy of the Fruit source code! Not only that, but while my assembly isn't so good, it looks like only _one_ argument passed to the Rybka equivalent of board_from_fen, which takes _two_ parameters in Fruit. I'm guessing that the input board data structure in Rybka is a global. Seriously? You count this as evidence for a copyright violation? The author of the PDF calls that NUL insertion "odd". I couldn't understand why. It's something I've done in my own code. It's a very handy sanity check because it ensures there can be no buffer overrun. The PDF author goes on "In any case, the fact that “something is done” here that (in the end) serves no purpose makes this a mentionable commonality." However, there's no indication of why there's no purpose to it. So I downloaded the 2.1 code. I can tell the there's no purpose for it in Fruit now. There's no evidence, however, that it wasn't useful while bootstrapping the parser. There's no evidence for why it's not needed in Rybka. Looking at the code, I realize that the PDF author omitted important code in the analysis. Here is the actual code from Fruit 2.1: if (fen != NULL) { // "fen" present if (moves != NULL) { // "moves" present ASSERT(moves>fen); moves[-1] = '\0'; // dirty, but so is UCI } board_from_fen(SearchInput->board,fen+4); // CHANGE ME } else { // HACK: assumes startpos board_from_fen(SearchInput->board,StartFen); } Notice the "HACK" section? It was left out of the analysis. This defines the "startpos" case if the fen string isn't present. The equivalent code in the Rybka code could be easily written as: parse_fen(startpos_board); // Make sure we always have a valid board if (fen && moves) { moves[-1] = 0; // Ensure no overrun parse_fen(fen); } Notice how it always parses the startpos, and then only if the fen is available does it parse the fen? This is different code. The order of operations is different, the function call parameters are different. Here too I used a different coding style, so the code doesn't even look the same, even though the final assembly code will look very similar. In other words, the command parsing does NOT "exactly [match] that of certain parts of Fruit", even though you say it does, because in Rybka: - the strstr search strings don't end with a space - the "startpos" board is always parsed, instead only when there is no fen string - the parse function appears to take one parameter instead of two, and use a global data structure Please explain this discrepancy. How could that assembly come from the Fruit source code?