What about programs playing nearly all moves the same? Is it impossible
for programs that playing the same variant of opening with very open
and mutually terminating continuation where almost each move has
decisive meaning and ends up with a draw. If programs refuse to fail
in each move, there should be a suspicion that they are clones of
perfect engine.

Concerning List, what if to make List to play with several versions of
Crafty
from some test set of positions and see the difference with Crafty playing
against
itself from the same positions?

I think that the most secret place of the chess engine is its evaluation
function.
The rest of the code uses almost the same algorithms, so this shouldn't be
the secret.
The demands for the source code of the chess engines should be limited to
the
subset of source code that does not include evaluation (which should be
replaced with
dummy code). After investigation of this less secret code it can be compiled
and binary
compared with the real executable image. They must be different only in some
service
information and the part that corresponds to evaluation function. After that
if program
does not have violations in the presented source code and plays different
game
of the suspected parent program, it MUSTN'T be treated as a clone.
Also if evaluation binary machine code can be extracted from the suspected
parent program, it can be compared against suspected clone evaluation binary
code.

"Znarf" wrote in message
t...
What I find interesting is the following quote at
http://chessbase.com/newsdetail.asp?newsid=1330 :

"The program List is suspected to be a clone of the program Crafty. Autor
Fritz Reul failed to prove otherwise and allowed a final deadline to
pass."

So apparently an author's reputation and integrity can be maligned on
"suspicion." What is truly tragic is the "assumed guilty" posture of the
accused. LIST was *SUSPECTED* to be a clone, and was disqualified because
the author *FAILED TO PROVE* otherwise. How incredibly unjust.

Furthermore, it does not appear that the ICGA followed thier own rule:

"Each program must be the original work of the entering developers.
Programming teams whose code is derived from or including game-playing
code
written by others must name all other authors, or the source of such code,
in their application details. PROGRAMS WHICH ARE DISCOVERED TO BE CLOSE
DERIVATIVES OF OTHERS (e.g., by playing nearly all moves the same), may be
declared invalid by the Tournament Director after seeking expert advice.
For
this purpose a listing of all game-related code running on the system must
be available on demand to the Tournament Director."

LIST was ONLY SUSPECTED of being a clone; it was NOT DISCOVERED TO BE A
CLONE. The rule, as written, places the BURDEN on the ICGA to prove it is
a
close derivate of another before disqualification; it does not place the
burden on the accused to prove that it is not a derivative. Thus, the rule
is inapplicable to the present situation.

The ICGA needs a procedure to follow in resolving these disputes.
Apparently
it has none, so it made a procedure up at the expense of an author's
reputation. Furthermore, the ICGA has now possibly damaged the author's
reputation beyond repair. Allegations of copyright infringement are
serious
concerns in the software community. Finally, the ICGA should have
accommodated the accused author's schedule - is it too much to ask to give
a
person a small reprieve while he tends to examinations rather than
publicly
call into question the author's integrity in a worldwide publication on
the
Internet.

A public retraction is in order, and an apology.