I was writing a point by point reply to this, but halfway through it started looking waste of time. Your reply doesn't seem to be addressing the points I was making. Also you're several times asking for evidence that already has been made available in the documents you chose to not read.

I have no horse in this race, just found the original documents interesting the first time they were linked to on HN. And to be very convincing, since they showed consistent patterns of unforced similarities. (E.g. in the ordering of operations, or in the selection of which operations to support, or even in the presence of dead code) between specific versions of Rybka and Crafty/Fruit, which were not present between different versions of Rybka. They also specifically addressed the question of whether these were the only/most common/best way of doing things (answer: no).

Please read the documents. If you don't find them convincing, I'm not sure there's anything I could do to change your mind. (And I certainly wouldn't be the right person to do so). But there is definitely no point in having a discussion before that.

On your suggestion, I read through http://www.chessvibes.com/plaatjes/rybkaevidence/RYBKA_FRUIT... .

It makes the clear and cogent statement:

> While a large (indeed, almost complete) match is found, it is presumably feasible to opine that the Fruit source code can be taken as a “manual” for chess programming (perhaps in the sense of a modern version of How Computers Play Chess), and if this paradigmatic view is accepted, then the re-use of the same evaluation components might arguably be less derelict.

That theme occurs elsewhere:

> This Fruit/Rybka overlap would already likely meet a “plagiarism” standard, for instance as used in the detection of non-original work in academia and/or book publishing (note that plagiarism is generally an ethical standard and not a legal one). There is also the question of how important this item is from a chess-playing standpoint, perhaps again viewing Fruit as a “manual” in some sense.

The issue, which is also that mentioned in the chessboard article, is that the standard for plagiarism "in the context of computer chess (or more generally, computer boardgames)" is extremely sensitive. It is not the same standard practiced in research, programming, arts, or any other field I can think of. It's so high that it's not reasonable.

As Wikipedia writes, "the notion [of plagiarism] remains problematic with nebulous boundaries." In this PDF I read of multiple cases where the copying is not copyright infringement but one of reimplementing an algorithm. Relevant quotes are "Rybka 1.0 Beta uses bitboards, making direct code comparison ineffective", "Rybka uses a look-up table of patterns, while Fruit does bit-scanning", and "the relative scaling for each rank-based bonus in Rybka is essentially 10-30-60-100, though in units of 256 as in Fruit."

This PDF does stress that the surface differences are not the issue:

> I might stress that the fact that Fruit 2.1 visibly computes these while Rybka 1.0 Beta just has an array is not really relevant for the discussion here. The content is of more import.

where I presume the context includes "everything must have independent origin."

The PST structures are similar, although it uses different weights in parts. Note also the scaling differences between the two code bases - the similarities are in normalized space. Hence, this is again not evidence of copyright infringement. It would not be plagiarism in the scientific research fields I work in; since "influenced by the work of XYZ" would suffice.

This PDF points out that the quad() function in Rybka uses a different scaling, rank-dependent values, and more cases than Fruit.

This is again not a case where "parts of the code of Rybka were copied verbatim from Fruit" but where the approach from Fruit was modified. The PDF author then says:

> Not all of these terms have exactly the same meaning in Rybka 1.0 Beta, and discussing any differences would diverge from my focus on the re-use of the quad() function. Perhaps the main difference is with FreePasser, as to whether the pawn’s path is met by a friendly or enemy piece, which uses SEE in Fruit and “attacks” bitboards in Rybka, and further is split into 3 parts in Rybka.

> As with the PST comparison, it seems that there is a structural similarity between Fruit and Rybka, and the question of “originality” therein allows multiple approaches.

I think these statements are enough to establish that there was no copyright violation for this section. Your question "Does any of that excuse either violating the GPL" is therefore not relevant - there does not appear to be a copyright violation.

Could you clarify what you mean by "violating the GPL"? Does you refer to things like the file parsing code, which shows idiomatic similarities between Rybka and Fruit?

Over and over again I see that the issue is not outright copyright infringement of the chess engine nor lack of attribution, but that the definition of "plagiarism" as used in chess competition is extremely sensitive; sensitive enough that "structural similarity" even with attribution is considered excessive. It's much more stringent than any other field I can think of. As used here, it has lost its moral meaning and become more of a technical term.

Speaking as a complete outsider, it appears that the Rybka code base went through several iterations where it was based on ideas in different, existing programs. This is not uncommon, and is both legal and moral. My Minix example is quite relevant; it's meant to be used as a reference for understanding operating systems, which means people who use it as a reference will tend to create similar OSes. A question (rightly pointed out earlier) is, do open source chess programs serve as a similar manual?

The Rybka author was sloppy though. He didn't use version control until very late, and he followed too closely some of the more boring parts, like file parsing. There may be copyright infringement, and the remedy under the GPL is to request that the author either apply the GPL to the entire program, or remove the infringing parts. That this hasn't happened (I'm only guessing that it hasn't) tells me that the copyright holders aren't concerned enough to ask for help from the SFLC or other organizations which help enforce the GPL.

However, the core part shows signs of creative thought and improvement, which means it was not copied verbatim from Fruit. ("Creative" here in the legal sense related to copyright law.)

That's why Rybka still exists as a commercial program. But the chess competition arena has a different criteria for originality. While they use the term "plagiarism", they do so with a different meaning than used by nearly the rest of the world.

The entire point of the chessbase essay was to stress that this "originality criterion" is increasingly at odds with how software, including chess programs, are developed. Not only does it need to be changed, but it should have been changed years ago ("updating WCCC Rule 2 to reflect contemporary reality would be a years-overdue positive step"). At the end of that essay the author quotes:

> A fair group of participating programmers present have expressed they want the rules to be updated. One line of thinking is that attribution plus added value should be sufficient to compete, instead of 100% originality.

You say the documents against Rybka are convincing. I have read a couple of them now, and I am convinced that Rybka is in technical violation of WCCC Rule 2. I am not convinced that it's plagiarism. For that I would want to see lack of evidence of attribution, which is hard given that there is attribution. Nor am I convinced that there's wholesale copyright violation. For that I would want to see large spans of code which are not just functionally identical but which use the same values, same implementation, and same function call order. Here too the strongest evidence shows "structural similarity" but definitely not copyright infringement.

What would it take for you to be convinced otherwise? What was not persuasive in the chessbase article?

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.

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?

tl;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... . 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?

You were able to change my mind on the issue with your well-written and detailed comment (I also had no knowledge to go on besides the chessbase.com article). So please don't think it was a waste.