Your selection of options (a), (b), (c), and (d) excludes the possibility of a mixture of (b), (c), and (d)?

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?