on the topic of the UI parsing .......BB+ wrote:ZW has already addressed some of this, but I enlarge on some points.
The exact numerology is much beyond a similarity (as I mentioned, merely having the same Rank/File/Line centralisation strategy for PST is a different bailiwick than having the same numbers from them). I can't find any engines other than Fruit and Rybka whose PST values are derived from (minor exceptions with Rybka in central pawns):One can only add the word suspicious if one have checked more programs (say 10-15) and found no such similarities. Perhaps things like these are common in many chess programs. Have Bob, Zach, you, checked 10-15 programs for its absence?I can imagine someone with the same idea producing 4 or 5 of these arrays that are the same, but not all 9.Code: Select all
static const int PawnFile[8] = {-3, -1, +0, +1, +1, +0, -1, -3,}; static const int KnightLine[8] = {-4, -2, +0, +1, +1, +0, -2, -4,}; static const int KnightRank[8] = {-2, -1, +0, +1, +2, +3, +2, +1,}; static const int BishopLine[8] = {-3, -1, +0, +1, +1, +0, -1, -3,}; static const int RookFile[8] = {-2, -1, +0, +1, +1, +0, -1, -2,}; static const int QueenLine[8] = { -3, -1, +0, +1, +1, +0, -1, -3,}; static const int KingLine[8] = {-3, -1, +0, +1, +1, +0, -1, -3,}; static const int KingFile[8] = { +3, +4, +2, +0, +0, +2, +4, +3,}; static const int KingRank[8] = { +1, +0, -2, -3, -4, -5, -6, -7,};
I think the point again is that the relative scaling is exactly the same, even to the matching of the output of the quad() function of Fruit. For instance, if I thought of 10-30-60-100 scaling, and took 4821 as my PassedOpeningMax and just rounded, I would get 482, 1446, 2893, 4821, not the 489, 1450, 2900, 4821 from the Fruit quad function (the differences appear in how the rounding in Fruit works, as 26 is not exactly 256/10) as appears in Rybka. And again there is not just one example of an array formed by Fruit code, but 5 or 6 in this genre. With both this and PST you can certainly argue that there is no "copyright violation", but my impression is that the standard in (say) WCCC events for "derivatives" is higher. Having two guys independently use 10, 30, 60, 100 scaling is reasonable, while its "hex-approximation" of 26, 77, 154, 256 is less likely. The use of rounding (rather than the floor function) with the quad() output is again something that needn't have been exactly the same if one merely took the idea in the abstract. The abstract idea of 10-30-60-100 scaling for various passed pawn elements appears in Rybka as exactly the output of the quad() function of Fruit, with there being no particular reason (and indeed, probably at best a 10% chance of a "random" implementation of this idea doing the same) for the minutiae to be identical (the most "obvious" in this sense is PassedFree array as { 0, 0, 0, 101, 300, 601, 1000, 1000 } -- from a human standpoint, clearly Rybka derived these numbers "mechanically", rather than a human writing them down as 100,300,600,1000 , and the Fruit quad() function is a mechanism that produces this somewhat peculiar output -- by this point, it should up to a defense to explain what alternative mechanism would yield the same numbers, not just similar ones).Mine has similar values. It's not suspicious at all. [on the 10, 30, 60, 100 scaling]
You have transferred the burden of proof to the impossibility of proving a negative -- surely it is any putative defense's responsibility to provide such evidence that the code actually is public domain, not vice-versa?UCI parsing: perhaps its code is public domain. Fabien took it and so did Vas. Has this option been researched by Zach, Bob and you?
The point of this was to note that there were three independent features in both Fruit/Rybka at the start of the search (position copying, 4 ply limit, setjmp), along with the time management. Of course you can argue that any one of the three is an accident. Again I feel that the preponderance of evidence has reached the point where it is the responsibility of the accused to rebut this laundry list by noting some other (independent) engine that replicates each of these three (or four, if you include time management here) elements [preferably in the same order], rather than trying chip away at each point individually [I think the derogatory phrase for this is "lawyering", usually done to impress the jury with useless addenda rather than the gravamen of the debate].Mine does the same, copy the board before the search starts. It doesn't matter if that is pointless, there are many things in mine that are not in use, they are either remains of previous ideas and forgotten to remove or I leave them there on purpose for future ideas.
I don't quite know what the connotation of "innocent" is here, but my impression is that most who have taken a similar position seem to have been quickly reduced to a variety of bafflegab and misdirection (or ad hominem) in their explanations of the evidence. There is notable evidence of "copying" in Rybka 1.0 Beta beyond mere "ideas" (the nine specific arrays re-used in the generation of engine-specific PST, for instance ), this copying appears to go beyond what is (or has been) acceptable in the field of computer chess/games [and I strongly feel that this is the proper standard to use for "originality", as opposed to a "legalistic" one, where perhaps only "code" is considered], and I personally find the attempts to dismiss this all as happenstance (or "unimportant") to be a bit outré. That being said, there is also a tendency to exaggerate the Rybka/Fruit connection in some other circles. [And by now, I think Rybka 4 has almost zero connection to the Fruit origins].I deliberately take the Vas=innocent position for the sake of the discussion.
with the caveat that I'm not a lawyer, but I was in biz, and one does make oneself aware of legal stuff. Oxford Softworks used to do a lot of work with one of the big Japanese console manufacturors. The manufacturor (I think they all tried this) wanted to control all software running on their machine, they would provide selected developers with kit and documentation and run their very strict quality control on the product. In turn, publishers had to pay them a substantial royalty and sell it through them. ie the manufacturor wanted to make sure they got the lions share of the software revenues.
To double protect themselves they created interface technology between the third party software and their hardware. The interface was coded, and you had to know the code algorithm etc. to get it to work. The manufacturor subjected the code (and everything else) to NDA and, cleverly, patented it (or some other tight legal method), I forget. So, if you broke the code, or had it leaked to you, they could sue you for not just copyright but patent breach etc. etc. Basically a clever use of patent/copyright law to prevent third parties making software for sale. Monopoly power, lack of competition blah-blah.
Now, possibly as a result of this, or similar cases, a law was passed in the EU that specifically allowed RE in order to render products mutually compatible. You could then investigate the interface software and reuse it, legally, including the fancy codes in order to make your product compatible with some other product.
My guess is that this would probably cover the UI code, although I seem to remember from the past many criticisms of the UI 'evidence' for other reasons. It was partly that that caused Zach to go away and produce a comparison that was about the engines instead.
