Feb 12 version: Rybka 1.0 Beta / Fruit 2.1 document

[BB+]

Maybe some of those people will read it, too!

And maybe even a few will read it sceptically (as it ought to be, even if I weren't an "unknown")... The latest conspiracy theory had me as someone other than myself, or perhaps all the evidence is a complete fabrication [the latter was advanced in the Rybka forum, I think]. Reminds me of a cheating case (related to me by an academic dean) where one issue that was brought up was that the student could have been "framed at random, possibly by terrorists" (this was soon after 9/11) -- this was the argument of the student's faculty advisor no less.

[BB+]

It seems that there are various misunderstandings regarding the PDF.

By Banned for Life (Silver) Date 2011-03-07 09:01

By sockmonkey (**) [de] Date 2011-03-07 08:20
Wait, are you saying that you've been going on and on about this, hair-splitting this, relativizing that, without having read any of the evidence that's been presented thus far?

Mark's document is an interesting read, but it really shows only that Vas was very familiar with many of the ideas in Fruit and made good use of them. There is no discussion of other engines where these same techniques might be used, nor is there much discussion about copied or transliterated code. [...] In my opinion, this is not a strong argument for violation of either copyright or GPL.

I refer to footnote 2, bottom page 1: Just to recapitulate, this means I am largely going to avoid GPL and/or copyright issues. As the PDF was largely addressed to the ICGA, I considered "originality" in a sense closer to theirs than to copyright law. This may very well differ with the FSF/Fabien complaint/lawsuit.

The only exception to this is the UCI parser code, but this is clearly in the interface category, and interface software has different rules, at least here in the US.

I think there is conflation of licensing and copyright here. See the discussion of Muller (and others) on TalkChess. The "interface" issue is one of copyright, not licensing. To sum up the linked discussion, the Gnu GPL grants a licensed right under certain circumstances for a person to do various things that would otherwise fall under copyright law. If one breaks the license, the licensed right to do such things disappears -- the person might still possess such a right under a different heading (such as "fair use"). Going further, the Gnu GPL does not seem to be "severable" -- that is, it grants a license to a distribution as a whole, and not on a file-by-file or function-by-function basis. Violating the GPL by re-using interface code is just as much a violation as re-using any other part, whereas for copyright it is correct that issues of interfacing and/or de minimis can become relevant. Regarding the cessation of rights upon violation of the license, this seems to be the most relevant section.

5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

Furthermore, it does not seem to me that the example displayed in Appendix A regarding the iterative deepening code can easily be considered "interface" code.

For the remainder, you would basically be falling back on a totality of the evidence argument, which is not where you want to be.

Well, I'd rather be many other places than this... Given that the prior comments seemed to deal with a civil lawsuit (as opposed to the ICGA process), it seems the "balance of probabilities" is the relevant metric. Would this be so strange in a civil case? The recent addition (not in your version of the PDF) of evidence of prior examples of Rajilch re-using inplementations/code from other engines might also have some effect on said balance. [Though again, I point out that the PDF on the whole is not oriented toward such a civil case -- I bring the civil issue up here in my response because the quoted comment seems to relate more directly to such].

In defense, Vas could explain why he used each of the enumerated ideas, along with many, many others, in building the engine (see for instance, his discussion with Anthony regarding Strelka). To the extent that Vas could authoritatively put these ideas into a much broader framework (as he did with Anthony), the totality argument looks pretty flimsy.

As indicated in the last paragraph of 1.1, page 1: this document is fundamentally incapable of anticipating even legitimate explanations of the evidence here enumerated (in other words, I present prima facie evidence and leave any affirmative defenses for others to submit -- note that such defenses typically reverse the burden of proof). Also, I am unable to find any discussion with Anthony regarding Strelka that possesses much of what I would call substantive -- I will try again later why I am less busy with other things.

[BB+]

In defense, Vas could explain why he used each of the enumerated ideas, along with many, many others, in building the engine (see for instance, his discussion with Anthony regarding Strelka). To the extent that Vas could authoritatively put these ideas into a much broader framework (as he did with Anthony), the totality argument looks pretty flimsy.

Here is the only Rybka forum post I could find from Rajlich that was directed principally to Cozzie:
Rajlich claims that he spent little time on optimisiation (the response of Cozzie is quite dismissive of this claim).

As for the second sentence quoted above, I think this is a corollary to the general truism that prima facie evidence is valuable to the extent that a defendant is unable to explain it away via sworn testimony.

Figuring that the recollection of "Anthony" here might be mistaken, I searched for what Rajlich had regarding ideas and Strelka/Osipov. Here are the most relevant quotations:
http://rybkaforum.net/cgi-bin/rybkaforu ... ?pid=19118

Osipov's speculation is not correct. Rybka is and always was completely original code, with the exception of various low-level snippets which are in the public domain.
Rybka's scores are minimax score - they are propagated up the search tree. In principle, they should be from the tip of the PV, but because Rybka takes the PV from the hash table, this may not always be the case.
Re. depth, this is simply a tool to drive the iterative search. By conventional I mean 'in the normal range.

http://rybkaforum.net/cgi-bin/rybkaforu ... ?pid=39198

I've taken a look this morning at the Strelka 2.0 sources. The picture is quite clear.

Vast sections of these sources started their life as a decompiled Rybka 1.0. The traces of this are everywhere. The board representation is identical, and all sorts of absolutely unique Rybka code methods, bitboard tricks and even exact data tables are used throughout. [...]

The author did at first make attempts to hide the Rybka origins, for example by masking the table values in earlier Strelka versions. He also made significant attempts to improve the program. The attempts at improvement are not very original, but they are everywhere. They include PV collection, null verification (and in fact changes to the null implementation itself), some endgame drawishness heuristics, a handful of new evaluation term, a new approach to blending between opening and endgame eval terms, and so on. They also do include various structural changes, such as knight underpromotions, on-the-fly calculations of many tables, the setting of piece-square table values, etc. These changes are extensive and no doubt lead to differences in playing style and perhaps a useful engine for users to have, but they do not change the illegality of the code base. [...]

However, I still seem not to be finding any post from Rajlich that enumerates many ideas in Rybka.

Maybe I should repeat Rajilch's last sentence in the above, as I think it is quite relevant to the current situation: These changes are extensive and no doubt lead to differences in playing style and perhaps a useful engine for users to have, but they do not change the illegality of the code base.

[BB+]

I can also note that in section 3 in particular (among other places), I was only collating and verifying whatever information had already been uncovered by others. For instance, if one were to undertake a more complete analysis of the root search, it could conceivably turn out there is evidence (strong or otherwise) of things beyond just plagiarism. One way to attempt to determine this would be to get the relevant compiler and see how many lines of Fruit need to be changed to get an essential match in the ASM outputs. This would of course be more relevant for the question of copyright infringement than for the ICGA process.

[BB+]

I've been quite busy recently, but hopefully a new PDF version will emerge either today or tomorrow. There is already one on the ICGA wiki that contains various addenda (including the Crafty/Rybka case) that have been already mentioned on this forum. But now I've written more addenda to try to clear up some questions about evaluation features, and (yet again) the nature of evidence presented.

[BB+]

Usually you lead with your best stuff, so lets take a more careful look at the first item. There are a large number of possible features, and apparently R1B uses the same subset as Fruit. Coincidence? Not likely. But is this out of bounds?

Before we make a decision, let's look at another case with similar evaluation features, i.e. R3H and Komodo. Both have evaluation functions designed by Larry Kaufman.

I agree that, for the purposes of plagiarism, the evaluation feature overlap is the most notable. I might also point out that neither Dailey nor Kaufman have made any secret regarding Komodo, while Rajlich might have done better to say: "... and took many things, such as using essentially the same evaluation features, the PST building scheme [...]"

Finally, and to the crux of the above quotation, I am not convinced that Komodo and R3H have "similar evaluation features", particularly as much overlap as Fruit 2.1 and Rybka 1.0 Beta . I started to enumerate the Komodo 1.0 personality features versus things in Rybka 3, but this seemed a bit unwieldy (see below). Maybe I should just choose one piece type and be complete.

For instance, referring to the listed features in Komodo 1.0 personalities, and to Rybka 3:
*) pmob: R3 has this, but only on the opposite side of the opposing king - is it the same in Komodo?
*) nmob: In R3, the mobility is safe square and forward, and doubly forward moves get an additional bonus - is it the same in Komodo?
*) bmob: In R3, the mobility calculation is quite complicated -- depending on the quadrant, one considers the pawn skeleton in one direction or the other, and there is an additional forward bonus - is it the same in Komodo? Does Komodo have x-ray/pin bonuses in general? [R3 even has a king safety element here].
*) rmob: See bmob.
*) ropen/rhalf: In R3, there is another adjustment if the file is blocked by a (guarded) opposing minor - does Komodo have this?
*) qmob: R3 has safe-square mobility (as always) with an additional forward bonus.
*) blockedopen: "backward pawn that is blocked or inhibited" -- not sure there is anything quite like this in R3, though see "pbkwd" below
*) kppdist: R3 has this, though I'd have to check details about "distance" (forward rank versus backward rank, and file). I recall also there is a funky "path" array [you'd have to see it to understand] to compute distance from a king to enemy pawns (with the minimum taken IIRC) -- does Komodo have something like this?
*) ntabm/btabm/rtabm/qtabm/ktabm: these are all PST scalings, which I ignore here
*) luftp: R3 has this in essence
*) ksarea/ksdefm/ksattm: these seem too vague to explicate much
*) pthreat: R3 has not only this, but a general "good attacks" bonus (when a lesser piece attacks a greater in value)
*) outpost: R3 has no rook outposts. The details would also need comparison [R3 has a square based bishop bonus, and the same for knights with an additional bonus if near the enemy king], e.g. an "outpost" in R3 just means a piece guarded by a friendly pawn.
*) minorbehind: likely the same in R3/Komodo
*) rook7th: R3 has a different criterion (king on 7th/8th or pawns on 7th), a 6th rank bonus, an 8th rank bonus, and a doubled majors on 7th bonus - does Komodo have the same?
*) pdoubled: likely the same - although R3 has a square-based value array, the contents are constant.
*) predundant: "number squares attacked by pawns" - not sure R3 has this
*) islands: likely the same
*) isoh/isoo: likely the same
*) pbwkd: R3 splits into half-open/closed files for the bonus here
*) ppinc: R3 has something like this, but it's a bit vague
*) ptabm/nwp/bwp/rwp: these would all be in PST or the material imbalance table, which I am ignoring here
*) hmb: maybe R3H has this, but don't think R3 had this in eval, though there was a "tempo" adjustment upon doing null move and with "stand-pat" in qsearch IIRC.

Here are some more things in R3, about which the Komodo situation seems unclear.
*) Queen attacks opposing piece not guarded by a pawn (including an opposing king(!), it seems)
*) Queen on 7th
*) Bishop attacks opposing pawn not guarded by pawn
*) Bishop attacks opposing knight not guarded by pawn (attacking rooks/queens is in "good attacks")
*) Trapped bishops (I'm guessing Komodo has this?) and same with trapped rooks.
*) Rook attacks opposing pawn not guarded by pawn
*) Penalty for knight three squares orthogonally from enemy bishop
*) Penalty for knight two squares diagonally from enemy king
*) Bonus for knight on a colour that no enemy bishop can attack
*) Knight attacks opposing pawn not guarded by pawn
*) Knight attacks opposing bishop, extra bonus if not guarded by pawn
*) Bad bishops (I'm sure that Komodo has it - but is the method the same, or at least similar?)
*) Various pawneval considerations (pawn on long diagonal of king, central blocked pawns with respect to shelter, etc.)

It may very well be that Komodo contains a lot of these, but they are not in the personality file.

[benstoker]

Komodo? Now Komodo is getting sucked into the vortex of BB+ Chess Engine Metaphysics. If you know not the objects in your universe, then your universe is "hoisted by its own petard".

Contingency planning: what happens if ICGA does NOTHING?

Usually you lead with your best stuff, so lets take a more careful look at the first item. There are a large number of possible features, and apparently R1B uses the same subset as Fruit. Coincidence? Not likely. But is this out of bounds?

Before we make a decision, let's look at another case with similar evaluation features, i.e. R3H and Komodo. Both have evaluation functions designed by Larry Kaufman.

I agree that, for the purposes of plagiarism, the evaluation feature overlap is the most notable. I might also point out that neither Dailey nor Kaufman have made any secret regarding Komodo, while Rajlich might have done better to say: "... and took many things, such as using essentially the same evaluation features, the PST building scheme [...]"

Finally, and to the crux of the above quotation, I am not convinced that Komodo and R3H have "similar evaluation features", particularly as much overlap as Fruit 2.1 and Rybka 1.0 Beta . I started to enumerate the Komodo 1.0 personality features versus things in Rybka 3, but this seemed a bit unwieldy (see below). Maybe I should just choose one piece type and be complete.

For instance, referring to the listed features in Komodo 1.0 personalities, and to Rybka 3:
*) pmob: R3 has this, but only on the opposite side of the opposing king - is it the same in Komodo?
*) nmob: In R3, the mobility is safe square and forward, and doubly forward moves get an additional bonus - is it the same in Komodo?
*) bmob: In R3, the mobility calculation is quite complicated -- depending on the quadrant, one considers the pawn skeleton in one direction or the other, and there is an additional forward bonus - is it the same in Komodo? Does Komodo have x-ray/pin bonuses in general? [R3 even has a king safety element here].
*) rmob: See bmob.
*) ropen/rhalf: In R3, there is another adjustment if the file is blocked by a (guarded) opposing minor - does Komodo have this?
*) qmob: R3 has safe-square mobility (as always) with an additional forward bonus.
*) blockedopen: "backward pawn that is blocked or inhibited" -- not sure there is anything quite like this in R3, though see "pbkwd" below
*) kppdist: R3 has this, though I'd have to check details about "distance" (forward rank versus backward rank, and file). I recall also there is a funky "path" array [you'd have to see it to understand] to compute distance from a king to enemy pawns (with the minimum taken IIRC) -- does Komodo have something like this?
*) ntabm/btabm/rtabm/qtabm/ktabm: these are all PST scalings, which I ignore here
*) luftp: R3 has this in essence
*) ksarea/ksdefm/ksattm: these seem too vague to explicate much
*) pthreat: R3 has not only this, but a general "good attacks" bonus (when a lesser piece attacks a greater in value)
*) outpost: R3 has no rook outposts. The details would also need comparison [R3 has a square based bishop bonus, and the same for knights with an additional bonus if near the enemy king], e.g. an "outpost" in R3 just means a piece guarded by a friendly pawn.
*) minorbehind: likely the same in R3/Komodo
*) rook7th: R3 has a different criterion (king on 7th/8th or pawns on 7th), a 6th rank bonus, an 8th rank bonus, and a doubled majors on 7th bonus - does Komodo have the same?
*) pdoubled: likely the same - although R3 has a square-based value array, the contents are constant.
*) predundant: "number squares attacked by pawns" - not sure R3 has this
*) islands: likely the same
*) isoh/isoo: likely the same
*) pbwkd: R3 splits into half-open/closed files for the bonus here
*) ppinc: R3 has something like this, but it's a bit vague
*) ptabm/nwp/bwp/rwp: these would all be in PST or the material imbalance table, which I am ignoring here
*) hmb: maybe R3H has this, but don't think R3 had this in eval, though there was a "tempo" adjustment upon doing null move and with "stand-pat" in qsearch IIRC.

Here are some more things in R3, about which the Komodo situation seems unclear.
*) Queen attacks opposing piece not guarded by a pawn (including an opposing king(!), it seems)
*) Queen on 7th
*) Bishop attacks opposing pawn not guarded by pawn
*) Bishop attacks opposing knight not guarded by pawn (attacking rooks/queens is in "good attacks")
*) Trapped bishops (I'm guessing Komodo has this?) and same with trapped rooks.
*) Rook attacks opposing pawn not guarded by pawn
*) Penalty for knight three squares orthogonally from enemy bishop
*) Penalty for knight two squares diagonally from enemy king
*) Bonus for knight on a colour that no enemy bishop can attack
*) Knight attacks opposing pawn not guarded by pawn
*) Knight attacks opposing bishop, extra bonus if not guarded by pawn
*) Bad bishops (I'm sure that Komodo has it - but is the method the same, or at least similar?)
*) Various pawneval considerations (pawn on long diagonal of king, central blocked pawns with respect to shelter, etc.)

It may very well be that Komodo contains a lot of these, but they are not in the personality file.

[BB+]

Before we make a decision, let's look at another case with similar evaluation features, i.e. R3H and Komodo. Both have evaluation functions designed by Larry Kaufman.

Komodo? Now Komodo is getting sucked into the vortex of BB+ Chess Engine Metaphysics.

There had been a number of comments that I should (say) investigate all engines from tournament X, for completeness. While this seems a bit outlandish to me, in this particular case Alan Sassler mentioned a specific pair, and the work was not too difficult, so I found it reasonable to comment.

Contingency planning: what happens if ICGA does NOTHING?

Seems to me that then the ICGA does nothing... not sure I can say more than that? [And do I really need a contingency plan for this?] I agree that this is certainly a possibility, that the ICGA decides any ex post facto punishments are ill-advised, and that the Panel should just serve to deter any future problems and/or codify the notion of clone/derivative -- the above Komodo/R3 snippet in its comparative sense to R1B/Fruit might prove useful for that.

Any civil action by Letouzey and/or the FSF might still proceed, etc.

[BB+]

hopefully a new PDF version will emerge either today or tomorrow

The latest version (among other things) makes a crude stab at quantifying evaluation feature overlap. Some might dispute the methodology in general. Others might want more details on my specific numerology . And if I wrote many pages about that, the argument could then shift to saying that I was just one expert (or perhaps a clown with good document formatting skills). In any event, I would opine that the evidential burden regarding evaluation features is now on those who claim that the Rybka/Fruit overlap is nothing extraordinary.

As the PDF now exceeds the 256k file limit, I bzipped it first. EDIT: see below, now unzipped.

[Jeremy Bernstein]

As the PDF now exceeds the 256k file limit, I bzipped it first.

Thanks, I meant to increase this value some time ago. It's now 1MB.

jb