OpenChess

I think the question of a document on Rybka 1.0 Beta and Fruit 2.1 was raised some months ago. I have attached what I currently have written. One of its functions is to outline and enumerate various parts of the evidence.

Just to recapitulate, this means that I am not going to consider GPL or copyright infring-
ment issues, and I also disregard any statement from a representative of either Fruit/Rybka
concerning their opinion of the matter (after all, from the standpoint of a tournament director,
two \competitors" could be colluding so as to gain multiple entries to an event | this was
actually an issue 20+ years ago, but hopefully those days are past us!).

I applaud the effort of taking an objective approach. It is up to Fabien (author of Fruit) and/or FSF to read this very well put together technical document as well as the mentioned reference work of Zach, and then conclude from there -- they have the ultimate say on this controversial, and at times very divisive matter.

Thank you very much for this. I hope that Fabien has a moment to read it. In fact, I hope that a lot of people, particularly skeptics, have a chance to do so. As usual, very comprehensive and clear.

Jeremy

You say, "The most interesting part is likely that moves[-1] reappears in the Rybka code, while I’m still not sure of its exact purpose in the Fruit code." It looks like that just null-terminates the string passed to board_from_fen (at the space before "moves" in a substring like "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 moves e2e4"). Granted, the board_from_fen() in Fruit 2.1 would work fine with extra garbage after the FEN, but it couldn't hurt to remove it.

UncombedCoconut wrote:You say, "The most interesting part is likely that moves[-1] reappears in the Rybka code, while I’m still not sure of its exact purpose in the Fruit code." It looks like that just null-terminates the string passed to board_from_fen (at the space before "moves" in a substring like "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 moves e2e4"). Granted, the board_from_fen() in Fruit 2.1 would work fine with extra garbage after the FEN, but it couldn't hurt to remove it.

This is correct. It's not a bad way to handle it, in fact, but it definitely looks odd to C-programmer eyes. Most would probably write "string[moves-string] = '\0';", which isn't any better to read, but doesn't get into negative array indices.

Jeremy

The below is from the PDF ....

Some of these could be considered to be \ideas" rather \code" for various
purposes; while the standard I adopt here makes some nuance between the two,
it is not so strict so as to demand any re-appearance of any specic code or
numerology.
It must be said that what is \fair game" to re-use from an open source
programme is not entirely clear. For instance, pursuant to the second major
point of above, one of the more notable \ideas" of Fruit was its evaluation
based mainly on mobility. In an appendix, I compare the components of this
evaluation routine to those used in Rybka 1.0 Beta. While a large match is
found, it is certainly possible to argue 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 taken, then
the re-use of the same evaluation components should not be seen as too derelict.

It seems to me that there is a safe way some similarities could occur, namely by study of source, writing a spec and then coding, quite a few of the "matches" you show could well have been produced by such a method, "5. Identical procedures in root search", for example. You call it something different: "using Fruit as a manual" whereas I call it "writing a spec without the need for a closed room, thanks to the free source publication". We can also see that if this was the approach a very concerted effort to write own code via data structure change to bitmaps was also used.

Has Vas actually done any more than write a strong program, used as many and whatever public domain sources there were, written it in another data structure, hence forcing use of his own code, used also his own ideas as well as a great bunch of ideas in the public domain already? I see little more than same order of calls (your root analysis) which can come via a spec rather than a copy, likewise the eval codes, and some data similarities, including the infamous 0.0

Looks like way not enough to promise success in a legal action in such a grey area already.

[...] grey area [...]

I think the principal effect of your post is to append the concept of "spec" to the ideas/code debate. Is it clear at what point does the "spec" just become "code"?

I think I've always felt that Fabien/FSF would be on tenuous ground for legal action (then again, the threat is often stronger than its execution), but then, I've never been particularly concerned with that facet. Elsewhere I noted that plagiarism is mostly an ethical concern, not a legal one.

Both Rybka and Fruit compute king safety by computing whether a piece (ignoring pawns and kings) attacks a square adjacent to the opponent's king.

This is incorrect. In fact, both do consider pawns, but Rybka counts 1 pawn maximum as attacking a square around the enemy king (via a bitboard check), while Fruit can have multiple pawns doing so. The "weighting" of such a pawn-attack is 0 for each engine.

Granted, the board_from_fen() in Fruit 2.1 would work fine with extra garbage after the FEN, but it couldn't hurt to remove it.

This is correct. It's not a bad way to handle it, in fact, but it definitely looks odd to C-programmer eyes. Most would probably write "string[moves-string] = '\0';", which isn't any better to read, but doesn't get into negative array indices.

There are two things here [three, if I were to correct "moves-string" to "moves-string-1", I think].
First, that something is done to handle it, when in fact (given the rest of the "position" handling in each) nothing need be done [recall that programmers are typically lazy]. Second, the thing that is done is a bit nonstandard. Given both these elements, it starts to like more than a coincidence, though I admit that without other evidence it wouldn't be of much value. [Recall also that Rybka had been a UCI engine from the start in 2003 -- would UCI parsing really need to be re-written?].

BB+ wrote:three, if I were to correct "moves-string" to "moves-string-1", I think

good catch.