The Minix/Linux example seems like a good parallel. Linus ran (and didn't like) Minix on his hardware. I know Minix had a textbook which described the design and implementation details, which is how many people in the early 1990s learned kernel development. I wouldn't be surprised if some of that design thinking affected the Linux development, and if you wanted to look for apparent violations, I'm sure you could find some equally suspicious parts, like where the ordering of arbitrary operations was very similar to the Minix version.
However, as the SCO-Linux controversies page on Wikipedia states, "In order for copyright to be violated, several conditions must be met. .. Second, all or a significant part of the source must be present in the infringing material. There must be enough similarity to show direct copying of material." I mention this because SCO repeatedly insisted that there was copyright violation, with examples, but which upon a more complete analysis proved groundless.
So far, in the limited study of the evidence I've done, it does not at all appear that there is "a significant part of the source" in Rybka to justify a claim of copyright violation.
In the SCO dealings you do see that there is a "group of jealous sub-peers" working together against Linux. I refer here to Microsoft's funding of SCO, which was "widely seen in the press as a boost to SCO's finances which would help SCO with its lawsuit against IBM." Why would the chess programmer community be any different?
Similarly, in the two analyses I've reviewed, both are flawed. While one came directly from the chessbase article and hence has bias error, the parsing example clearly shows that 1) there is no copyright violation for that code, and 2) the analysis report emphasized one minor point of the code but justifying its presumed importance, and omitted obvious mitigating factors.
That is, why would someone change the strstr function arguments, the number of parameters to the fen parse function, and the ordering of the fen parse calls, but leave the s[-1]=0 in the code? (For purposes of copyright law, these are all creative endeavors.) Does the s[-1]=0 technique occur elsewhere in Rybka? It occurs twice in the Fruit code; does Rybka also use it in that spot, and only that spot? Without that test, which double checks that the analysis method is itself valid, the conclusion must be suspect.
The point of the analysis is that there is deep algorithm similarity between the two codes. I'm willing to say that there is. But for reasons I listed before, it is not and cannot be plagiarism any more than how West Side Story plagiarizes Romeo and Juliet.
From what I've seen so far, there is absolutely no basis for a GPL copyright violation claim.
> 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
Are you convinced that that parser code which I highlighted, and which you said is a "verbatim code copying" is not a copyright violation? If so, did the investigators lie by omission?
(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... . 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
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);
}
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);
}
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
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.