What's the latest on the Rybka-Fruit situation

[Tom Barrister]

Did I miss something here? Were threads moved somewhere else? Was the situation resolved?

[bob]

Did I miss something here? Were threads moved somewhere else? Was the situation resolved?

No. We've put together a really large collection of code examples, discussion, and such. We had asked Vas to respond, which he did not. We are in the process of giving this to the ICGA, which will contact Vas again. This should wind down pretty quickly, and then made public for everyone to read.

[Tom Barrister]

Thanks.

[Onno Garms]

Will this large collection focus on code theft or will it again discuss the algorithms?

I'm asking because the majority of pages in Mark's paper (which was cited in the open letter) was about using the same algorithms, which is legally pointless IMHO. There are some things in Mark's paper that do indicate code theft, but not many pages would remain if you removed the algorithmic discussion.

Who's working on the large collection apart from you?

[bob]

Will this large collection focus on code theft or will it again discuss the algorithms?

It has never been about "algorithms." It has always been about "copied source code."

I'm asking because the majority of pages in Mark's paper (which was cited in the open letter) was about using the same algorithms, which is legally pointless IMHO.

You need to re-read things then, as you seriously overlooked things. First, there are several _identical_ blocks of code in Rybka 1.6.1 and Crafty 19.0. The C code in Crafty is presented (along with a couple of built-in bugs) and the assembly language from Rybka 1.6.1 is given with a reverse-compile back to see. There are _perfect_ matches. In one case, for a block of code that is 100 lines of C (EvaluateWinner()). Other examples include NextMove(), NextEvasion() and such. Those are _not_ "algorithms."

Ditto for blocks of code in Fruit. The code becomes "not identical" when one first copies Fruit's eval line by line, and then modifies it to use bitboards. But that does not make it original code, it has only been translated.

There are some things in Mark's paper that do indicate code theft, but not many pages would remain if you removed the algorithmic discussion.

Who's working on the large collection apart from you?

Mark Watkins, Zach, even Ken Thompson has joined the Wiki panel and has looked at the evidence...

[Onno Garms]

You need to re-read things then, as you seriously overlooked things. First, there are several _identical_ blocks of code in Rybka 1.6.1 and Crafty 19.0. The C code in Crafty is presented (along with a couple of built-in bugs) and the assembly language from Rybka 1.6.1 is given with a reverse-compile back to see. There are _perfect_ matches. In one case, for a block of code that is 100 lines of C (EvaluateWinner()). Other examples include NextMove(), NextEvasion() and such. Those are _not_ "algorithms."

Are you sure that we are talking about the same paper?
I was talking of
http://www.open-chess.org/download/file.php?id=304

This is basically the only ressource I know. Crafty is not mentioned in it at all. Maybe the thing I have overlooked is the link to some other ressource?
I also had a quick look at
https://webspace.utexas.edu/zzw57/rtc/eval/eval.html
but that does not seem to be fundamentally different from the PDF above.

[UncombedCoconut]

Are you sure that we are talking about the same paper?

Some evidence, particularly what panelists found in early versions like 1.6.x (older than 1 beta), is scattered among forum threads here and in open-chess. IMO the fun of reading all of it isn't worth the time it would take to track it down. This thread is the first place I saw a confirmation of where the panel got its pre-1β Rybka binary, so I suppose it's a good place to start if you want to follow developments. For the time being, though, why not follow insipid Hollywood gossip or something? That's at least more likely to involve sex than any computer-chess-related discussion.

[michiguel]

You need to re-read things then, as you seriously overlooked things. First, there are several _identical_ blocks of code in Rybka 1.6.1 and Crafty 19.0. The C code in Crafty is presented (along with a couple of built-in bugs) and the assembly language from Rybka 1.6.1 is given with a reverse-compile back to see. There are _perfect_ matches. In one case, for a block of code that is 100 lines of C (EvaluateWinner()). Other examples include NextMove(), NextEvasion() and such. Those are _not_ "algorithms."

Are you sure that we are talking about the same paper?
I was talking of
http://www.open-chess.org/download/file.php?id=304

This is basically the only ressource I know. Crafty is not mentioned in it at all. Maybe the thing I have overlooked is the link to some other ressource?
I also had a quick look at
https://webspace.utexas.edu/zzw57/rtc/eval/eval.html
but that does not seem to be fundamentally different from the PDF above.

You are missing the leaks from the panel.

Miguel

[Sven]

You need to re-read things then, as you seriously overlooked things. First, there are several _identical_ blocks of code in Rybka 1.6.1 and Crafty 19.0. The C code in Crafty is presented (along with a couple of built-in bugs) and the assembly language from Rybka 1.6.1 is given with a reverse-compile back to see. There are _perfect_ matches. In one case, for a block of code that is 100 lines of C (EvaluateWinner()). Other examples include NextMove(), NextEvasion() and such. Those are _not_ "algorithms."

Are you sure that we are talking about the same paper?
I was talking of
http://www.open-chess.org/download/file.php?id=304

This is basically the only ressource I know. Crafty is not mentioned in it at all. Maybe the thing I have overlooked is the link to some other ressource?
I also had a quick look at
https://webspace.utexas.edu/zzw57/rtc/eval/eval.html
but that does not seem to be fundamentally different from the PDF above.

You are missing the leaks from the panel.

Miguel

@Onno: there is a newer version of the Mark Watkins paper here. It now mentions also Crafty. The evidence shown there looks quite heavy, nevertheless it should neither be relevant for the current ICGA investigation nor for Fabien and the Fruit-Rybka case since it is all about the early pre-beta "Rybka 1.6x". That case is definitely very relevant for Bob, though, no doubt here.

Sven

[Milos]

The evidence shown there looks quite heavy, nevertheless it should neither be relevant for the current ICGA investigation nor for Fabien and the Fruit-Rybka case since it is all about the early pre-beta "Rybka 1.6x". That case is definitely very relevant for Bob, though, no doubt here.

In this case I agree with you. Moreover, if Rybka 1.6x is a private engine (it has not been distributed in any way) the case is also not legally relevant for Bob, as a matter of fact it's not (legally) relevant at all. In addition to this, since Bob does not provide explicitly any license with his source code he cannot claim any violation of (legal) rights.