A Crime by a Board of Old Imposters

Sidney Cadot wrote:
Robert Hyatt wrote:

Sidney Cadot wrote:

As for the Shredder/Johnny threefold repitition: this case is not
clearly covered by the rules, so the tournament director must use his
best judgement in order to proceed. All this hinges on the fact that the
participants trust the tournament director to make a just and objective
call. If a participant does not subscribe to this, he should pack his
stuff and leave.

Sorry, but this _was_ covered by the rules. The human operator is
"passive". If, at any time during a game, it is discovered that the
operator played a move different than the move the program displayed,
or that the operator entered a move different than what the opponent
played, then the game backs up to that point _immediately_ and the
correct move is entered/played and the game proceeeds from that point.

My point it that "making a claim" is a vague wording.

It is entirely possible for a chess program GUI to list all available
moves it has at its disposal at any given time. Likewise, it could also
provide status information on the castling status, en passent status,
50-move rule status, and threefold-repetition status.

If the GUI is decoupled from the engine, it could even make a repitition
claim without being told to do so by the engine. That would not be
acceptable to me. Such a GUI should be explicitly abolished, if only to
prevent misunderdstandings.

Sure, but remember, in this case a new window popped up with the
repetition claim in it, and before the game could proceed, the operator
had to click "OK" to show he had seen it and handled it.

That's different from displaying random junk in an analysis window.


Like a human player, a chess program is free not to claim a draw based
on the threefold repetition rule, even though it could. It could still
hold some internal status information: "ok, I could take the draw at
this point, but let's see". It could also show the "draw-ability" in the
GUI.

Now if the Johnny program (prompted by the engine) popped up a dialog
saying "threefold repitition - draw", I'd be 100% with you on this.

Aha. Now you see my point. It did just that... The thing popped up
a window that wouldn't go away until OK was clicked...


However, if it just showed an internal flag, I wouldn't be.

I don't know the Johnny GUI and I wasn't there, so I don't know. All I'm
saying is that it would be wise if the rules explicitly stated what a
"claim of draw", as instigated by the engine, looks like.


The point has _always_ ben that this is computer vs computer. The
human is there to assist the two players, just like the assistant a
blind player is allowed to use. But this "assistant" may _not_
participate in the game in any way. Many programs can't accept draws
nor offer them. So unlike FIDE events, the computer chess TDs have
_always_ had absolute say on draws. If I want to offer my opponent
a draw, or if I want to resign, I have to first ask the TD. He will
look at the board and say "OK or play on". I have had _both_ happen
to me. If the program offers a draw, and the opponent program can
accept draws, then the two programs "agree" and the result is final.
If either opponent requires a human to make the decision to accept or
decline a draw, then the TD has final say. No such rule in FIDE. But
there is in CC. And here it was _clearly_ violated. The human saw
the claim of "3-fold repetition".

I'm with you all the way. If this constituted a "claim" by Johnny,
something went horribly wrong. Both the operator and (especially) the TD
should know better.

He should have claimed a draw and
called the TD over to verify it. The TD doesn't get to say "Hey the
GUI is claiming draw but the engine is not." The TD only gets to
say "the claim is valid or it is not." Here the TD and the operator
went _way_ outside the rules, clearly.

If this is the case, I'm surprised that the Fritz operators didn't
object. Could be commercial interest: it's better not to be seen as
"sore losers".

Ken Thompson and I have been harping on eliminating the operators since
the late 1970's. I wrote software to take a microcomputer with a bunch
of serial ports, and use that to connect multiple programs so that they
could communicate directly. The software I wrote managed the clock,
the programs could query the clock and send moves back and forth (somewhat
like auto232 but much more reliably). The ICCA said "sounds great, but we
have some commercial programs that have dedicated hardware and they don't
have a serial port to use, so we aren't going to use this approach." Next
I suggested installing a FICS-type server on a laptop, having a LAN at
the tournament hall, and requiring everyone to use an FICS-capable
interface (we have this requirement for the CCT event we hold every 6
months on ICC). The ICCA again said "some commercial programs don't have
a GUI that supports internet chess so we won't use this idea." In the CCT
events we _require_ this for a participant. Our last event had 3x _more_
entries than the just-completed WCCC. Why they can't move to the 21st
century is beyond me.

On this, I couldn't agree more.

This could have been avoided with a LAN and no operators. It wasn't. It
could have been avoided by the TD making a rational decision. It wasn't.

The final result is a joke, the title is tainted, and the after-smell will
haunt the ICGA for years. Shredder may very well be the best program there.
I don't question that at all. But more than once I had the best program at
a CC event and lost due to a bug or whatever. I simply looked my opponent
in the eye and said "good game" and moved on.

This was a blunder of ridiculous proportions. It could have been avoided.
It will only serve to make the CCT (held on ICC) the main computer chess
event of the year from here on.

How anyone could reach a decision allowing a program operator to influence
not only the outcome of a game, but the outcome of the tournament defies
any logical explanation.

I wish I had been there to see it happen. If the Johnny program's
threefold repetition message constituted a "claim" and not just a status
message, I do agree that the TD was indeed at fault here.

I've been a judge at an entirely non-related type of event (a
programming contest, if you want to know), and sometimes things happen
that are not planned. You then consult the rules and do your job, which
is to take hairy decisions in hairy situations. If you cannot do this,
or are not able to do this when push comes to shove, you shouldn't be in
that position.

yes, but here there _were_ rules. The spirit of the WCCC/WMCCC events
has _always_ been that this is a contest between two programs, and that
the humans have very limited influence on the games. Just read the rules
about incorrect moves, changing times, changing engine parameters, etc.
The human is _very_ limited in what he can/can't do, and this decision let
one go _far_ beyond what was allowed.

Ok.

As for your cheapshots at Prof. van der Herik's alleged "academic
sluggishness": I have met the man, and although I have no particular
like or dislike of him, I feel that he is the perfect man for the job
and would always try to pass objective judgement, within the framework
of the written rules if possible, but based on what is just in other
circumstances. I don't think you have a clue on his standing in the
computer chess community. I have his PhD thesis sitting in my bookshelf,
which is about using advanced search algorithms for chess endgames, he
wrote this when your parents probably didn't even conceive of conceiving
you. Who are you to judge this man?

I think he is simply "in over his head." I participated in CC events
from 1976 to 1994 when the last ACM event was held. For most of those
IM Mike Valvo was the T.D. and we _never_ had such irrational decisions.
This is _not_ the first gaffe Jaap has made. I happen to like him myself,
I've known him for years. But as a TD, he is simply in over his head.

That could be. My main reason for reacting to Mr. Tueschen's message was
the foul tone this thread had evolved to. I am sure, as I think you
are, that Prof. van der Herik had no malintent. Of course it is fair
game to discuss his decisions as TD, but I'd prefer to keep this civil.

One simple example. I think it was in 1995 that a program played a move
and displayed it on the GUI chessboard. In looking at the analysis window
the engine said "move X is best". But somehow the GUI displayed the wrong
move (it was a pawn promotion and the engine wanted to promote to queen
and the GUI said knight, or vice-versa). Jaap said "we use the GUI move,
not what the engine is showing." Reasonable? Flash forward to 2003. The
GUI says 3-fold repetition. The engine doesn't (apparently) understand
3-fold repetition. Japp says "we use the engine's analysis, not the GUI."

If it was the GUI claiming 3-fold repetition, this would count as
"status info" in my view. If the engine cannot claim 3-fold repetition,
I would say that a draw cannot be claimed. A "claim" to me is almost
like a move: it's an active action that the "thinker" (human or
computer) must make. To me, an engine that doesn't know how to claim a
draw is only partially a chess-playing engine; I don't see a whole lot
of difference to it and an engine that can't make Knight's moves.

I think the 1995 incident was completely mishandled by Mr. van der
Herik, assuming your recollection is good.

Does that seem rational or logical? Not to this long-time CC
competitor. If you look at Mike Valvo's decisions, they were consistent
from the first tournament he directed to the last one. That is vital.

Yes.

Best regards,

Sidney Cadot


--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170

Charley Moore m wrote:
Robert Hyatt wrote:


2. Kick list out in the middle of the event, with all the bad publicity
and harm to the programmer's reputation that would incur, not to mention
the unfairness to the tournament standings. List was pretty strong. Some
had already played it. After it was taken out, everyone beyond that
poing got a free point. Those before that point lost or drew with it
and got less, simply because they were unlucky in the pairings.

I don't know how the pairing and scoring went in the tournament but would
it not have been fairer to declare all games void and award everyone the
same score against List?

That is a choice. But the it would screw up the early round pairings,
since losers would now have an extra point and would have been paired
differently. However, with 16 programs and 11 rounds, I really don't
think this would have been very bad. Perhaps no worse than letting it
play on. But kicking it out in the middle made a difference since it
was not weak.

Regards Charley

--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170

Sidney Cadot wrote:
Robert Hyatt wrote:

[snip] I didn't try to nit-pick and get into
this "the GUI said this, the engine said this, the GUI is not really the
engine" nonsense. This game has two players. Each player is comprised
of hardware and software. It is a _single_ entity. Not multiple pieces
where one can be eliminated from the discussion.

So, if I understand correctly: it is your opinion that the human player
is just an I/O device, but the GUI isn't (it's "part of the same single
entity").

Correct. Just as much as the monitor is a part of the computer player.
Remove the monitor, no game.

I think that is a strange position to take. I feel that the GUI is also
just an external I/O device, like the human operator; For most bare
engines, the GUI is driven by a protocol and runs as a separate process.
To me, it's pretty clear who's in charge.

Actually not. Look at the UCI GUI protocol. THe GUI tells the engine
what to search, what to ponder, when to move, etc...



You pointed out some examples from your own experience where the engine
and the GUI disagreed. What should be the course of action in cases like
that?

Somehow the engine has a concept of "playing a move". With a GUI, that
concept is moving the piece on the graphical chess board. That has to
be the move it plays. In the case of my old experience, the "my move
is B-qb4" was the way to display a move. That was the right thing to
look at.


Should we follow the engine or the GUI? Or should we ask the TD (or toss
a coin)?

The engine hides behind the GUI. You really have little choice.



Best regards,

Sidney


--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170

Robert Hyatt wrote:

If the GUI is decoupled from the engine, it could even make a repitition
claim without being told to do so by the engine. That would not be
acceptable to me. Such a GUI should be explicitly abolished, if only to
prevent misunderdstandings.


Sure, but remember, in this case a new window popped up with the
repetition claim in it, and before the game could proceed, the operator
had to click "OK" to show he had seen it and handled it.

I would be interested to know what the setup was used during the game,
for the Johnny program. Did it use an integrated engine/GUI, did it use
an xboard compatible interface, UCI...

That's different from displaying random junk in an analysis window.

For me, it depends on what process initiated the popup. If it's the
engine, ok. If it's a separate GUI, maintaining game state and
concluding on its own that a threefold repetition has taken place, I
don't think that should constitute a claim.

Like a human player, a chess program is free not to claim a draw based
on the threefold repetition rule, even though it could. It could still
hold some internal status information: "ok, I could take the draw at
this point, but let's see". It could also show the "draw-ability" in the
GUI.

Now if the Johnny program (prompted by the engine) popped up a dialog
saying "threefold repitition - draw", I'd be 100% with you on this.

Aha. Now you see my point. It did just that... The thing popped up
a window that wouldn't go away until OK was clicked...

For me, the words "prompted by the engine" have a very specific and
crucial meaning.

Best regards, Sidney

"darrz" wrote in message
...
The ICGA has no crystal ball to detect cheats, that's why they have
the examination of source code provision in the first place.

What "procedure", other than an examination by an expert, would you
prefer the ICGA to use?


Fair question.

A proposed procedure would be to provide the source code under a
non-disclosure agreement to the ICGA.

The ICGA could only access and review the source code upon an accusation of
"cheating." The Accuser must provide a factual basis for the accusation
(e.g., it must be more than "The accused program performed the same two
moves as program x."). This would protect entrants from unfounded
accusations.

.. The ICGA would then evaluate whether the factual basis provided by the
accuser supports a the accusation (e.g., a valid accusation could be same
tree/node/score for x positions, etc.). If the accusation seems genuine,
then the ICGA could examine the source code of the accused and compare it to
the source code of the program that the accused allegedly copied.

Upon a finding of copying/cheating, the accused is given a chance to
present his side of the story. If the ICGA is not persuaded by the accused,
then the source code is returned to the accused and the accused is kicked
out of of the tournament, and perhaps banned for some time period.

All findings are reduced to writing for the protection of all parties -
the ICGA, the accuser, and the accused. Last thing you need is litigation
based only on words and faulty memories.

Upon the completion of the tournament, all source code is returned to
entrants.

Time periods for each phase must be set in advance, and entrants must be
available during the entirety of the tournament.

"marc margolies" wrote in message
...
ssince you say you are an attorney, and i have no reason to assume
differently, why do you insist the the central question is 'copyright
law?'
this is a misguided premise.
it is misguided because the author of crafty is NOT the plaintiff and
there
are no economic damages at issue, mr attorney.
the programmer of list broke a contract. he refused to provide information
persuant to a claim of an ethics violation from one of his competitors in
a
contest where he contractually agreed to a set of rules and a method of
arbitration.


Copyright was provided only as an analogous situation in civil/criminal
procedures. True, Dr. Hyatt is not a plaintiff, and there appear to be no
economic damages. But my point is that the ICGA did not appear to have a
set procedure for dealing with accusations. It appears to have been done in
a summary, ad-hoc manner, perhaps at the expense of the accused. Whether
the accused broke a contract is also unfounded. What were the terms of the
contract? What was the course of dealing/performance with the ICGA with
other parties and the accused? Contracts may or may not be limited to the
terms they recite. Too many questions that can't be answered. So... my
point is not to disparage the ICGA, but rather ensure that any future
entrants are at least protected from a "guilty until proved innocent"
situation, and that they know the EXACT procedure for dealing with cheating
accusations. This way, all parties - ICGA, accused, and accuser - are
protected.

See my post on another thread for a proposed procedure. It's just a
starting point. Wait, a lot of threads, a copy follows. As for the
attorney remark, I just want you to know my frame of reference. I'm usually
concerned about procedures that protect the accused from unfounded
accusations.
-------------

A proposed procedure would be to provide the source code under a
non-disclosure agreement to the ICGA.

The ICGA could only access and review the source code upon an accusation of
"cheating." The Accuser must provide a factual basis for the accusation
(e.g., it must be more than "The accused program performed the same two
moves as program x."). This would protect entrants from unfounded
accusations.

.. The ICGA would then evaluate whether the factual basis provided by the
accuser supports a the accusation (e.g., a valid accusation could be same
tree/node/score for x positions, etc.). If the accusation seems genuine,
then the ICGA could examine the source code of the accused and compare it to
the source code of the program that the accused allegedly copied.

Upon a finding of copying/cheating, the accused is given a chance to
present his side of the story. If the ICGA is not persuaded by the accused,
then the source code is returned to the accused and the accused is kicked
out of of the tournament, and perhaps banned for some time period.

All findings are reduced to writing for the protection of all parties -
the ICGA, the accuser, and the accused. Last thing you need is litigation
based only on words and faulty memories.

Upon the completion of the tournament, all source code is returned to
entrants.

Time periods for each phase must be set in advance, and entrants must be
available during the entirety of the tournament.

Robert Hyatt wrote:

So, if I understand correctly: it is your opinion that the human player
is just an I/O device, but the GUI isn't (it's "part of the same single
entity").

Correct. Just as much as the monitor is a part of the computer player.
Remove the monitor, no game.

I have no issue with the human player being seen as an I/O device. But
to me, it seems natural to see the GUI in the same light.

I think that is a strange position to take. I feel that the GUI is also
just an external I/O device, like the human operator; For most bare
engines, the GUI is driven by a protocol and runs as a separate process.
To me, it's pretty clear who's in charge.

Actually not. Look at the UCI GUI protocol. THe GUI tells the engine
what to search, what to ponder, when to move, etc...

Yes, I've seen the UCI protocol and I think it is flawed in several
ways. Most importantly, it puts some responsibilities for abiding by the
laws of chess with the GUI (most specifically: claiming and offering
draws, detecting end-of-game), that should be with the engine in a
well-designed system. In general, the engine knows much more about chess
than the GUI; it is, too me (and I'm a software engineer by profession)
bizarre to see that this responsibility is left with the GUI.

The xboard spec is better in this respect:

(start quote)

"RESULT {COMMENT}
When your engine detects that the game has ended by rule, your engine
must output a line of the form "RESULT {comment}" (without the quotes),
where RESULT is a PGN result code (1-0, 0-1, or 1/2-1/2), and comment is
the reason. Here "by rule" means that the game is definitely over
because of what happened on the board. In normal chess, this includes
checkmate, stalemate, triple repetition, the 50 move rule, or
insufficient material; it does not include loss on time or the like.
Examples:
0-1 {Black mates}
1-0 {White mates}
1/2-1/2 {Draw by repetition}
1/2-1/2 {Stalemate}


xboard relays the result to the user, the ICS, the other engine in Two
Machines mode, and the PGN save file as required."

(end quote)

Clearly, the engine can end the game with a result command, claiming
draw by repetition or 50-move rule, which is unambiguous. While the
xboard standard leaves much to be desired, this is how it should be.

While technically, the xboard standard can handle this situation quite
well, the wording of this is a bit slippery: "...the game is definitely
over because of what happened on the board. In normal chess, this
includes checkmate, stalemate, triple repetition, the 50 move rule, or
insufficient material"

Of the reasons given, only checkmate, stalemate, and insufficient
material (which is a special case of the rule as given in Article 9.6 of
the Laws of Chess) make that the game is "definitely over". A legal game
can proceed beyond triple repitition and the 50 move rule.

To offer an example (which I brought up recently here):

Suppose the chess engine detects a draw based on Article 9.6 in the
following position (probably no current engine can, but in principle,
it's possible):

8/3k4/8/1pBp1p1p/1P1P1P1P/5b2/2K5/8 w - -

.... Now the GUI (with limited chess capability) will surely think the
game is still ongoing. How is an engine using the UCI protocol to notify
the GUI that the game is, in fact, over, with result 1/2-1/2 ?

You pointed out some examples from your own experience where the engine
and the GUI disagreed. What should be the course of action in cases like
that?

Somehow the engine has a concept of "playing a move". With a GUI, that
concept is moving the piece on the graphical chess board. That has to
be the move it plays. In the case of my old experience, the "my move
is B-qb4" was the way to display a move. That was the right thing to
look at.

With all due respect, I disagree.

Should we follow the engine or the GUI? Or should we ask the TD (or toss
a coin)?


The engine hides behind the GUI. You really have little choice.

It is the engine that's playing chess, not the GUI. Most engines
(including your Crafty) can play an excellent game of chess without a
GUI attached. So, often, you _do_ have a choice.

Best regards,

Sidney

Sidney Cadot wrote:
Robert Hyatt wrote:

If the GUI is decoupled from the engine, it could even make a repitition
claim without being told to do so by the engine. That would not be
acceptable to me. Such a GUI should be explicitly abolished, if only to
prevent misunderdstandings.


Sure, but remember, in this case a new window popped up with the
repetition claim in it, and before the game could proceed, the operator
had to click "OK" to show he had seen it and handled it.

I would be interested to know what the setup was used during the game,
for the Johnny program. Did it use an integrated engine/GUI, did it use
an xboard compatible interface, UCI...

I can answer those, other than what was discussed at the time of
the problem.. Johnny apparently used the chessbase (fritz) GUI as
the front end...



That's different from displaying random junk in an analysis window.

For me, it depends on what process initiated the popup. If it's the
engine, ok. If it's a separate GUI, maintaining game state and
concluding on its own that a threefold repetition has taken place, I
don't think that should constitute a claim.

What is the basis for separating the GUI from the engine? IE crafty
has two distinct parts, the input/output, and the computation part.
If I were doing a software engineering project, putting the draw
claim stuff in the front-end makes perfect sense. It is, after all
the part that communicates with the external world. Making the
engine tell the front end, and the front end tell the world seems
a bit complicated, not to mention violating a couple of design
principles for large software projects.




Like a human player, a chess program is free not to claim a draw based
on the threefold repetition rule, even though it could. It could still
hold some internal status information: "ok, I could take the draw at
this point, but let's see". It could also show the "draw-ability" in the
GUI.

Now if the Johnny program (prompted by the engine) popped up a dialog
saying "threefold repitition - draw", I'd be 100% with you on this.

Aha. Now you see my point. It did just that... The thing popped up
a window that wouldn't go away until OK was clicked...

For me, the words "prompted by the engine" have a very specific and
crucial meaning.

Not for me. The computer sits on the table and plays chess. It doesn't
matter what communicates with the operator. It only matters that it
happens... There has _never_ been a "GUI" component discussion in any
ICGA event. There never should be, IMHO. The engine/gui/computer is
one symbiotic chess player. Take any part out and the game can't be
played. Does it matter whether your left brain or right brain originates
a repetition claim? If not, why does it matter whether the GUI or the
engine did?




Best regards, Sidney


--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170

Sidney Cadot wrote:
Robert Hyatt wrote:
[snip] I didn't try to nit-pick and get into
this "the GUI said this, the engine said this, the GUI is not really the
engine" nonsense. This game has two players. Each player is comprised
of hardware and software. It is a _single_ entity. Not multiple pieces
where one can be eliminated from the discussion.

So, if I understand correctly: it is your opinion that the human player
is just an I/O device, but the GUI isn't (it's "part of the same single
entity").

I think that is a strange position to take. I feel that the GUI is also
just an external I/O device, like the human operator

What you're saying is true but impractical. I agree with you that the GUI
is a distinct piece of software that relays status from the engine, which
plays chess, to the operator, who interfaces with the world. However, if
the rules are to be based on whether the engine or the GUI claimed a draw,
for example, there must be a clear distinction between the two. The
tournament organizers must be able to tell instantly which actions were
the engine's and which the GUI's -- otherwise, it would be very hard to
disprove a claim that a particular bad move was really chosen by the
engine and not a bug in the GUI. So, while distinguishing between the GUI
and the engine sounds like a good idea, it is not possible to police and
would, therefore, make a bad rule.


Dave.

--
David Richerby Old-Fashioned Moistened Pants (TM):
www.chiark.greenend.org.uk/~davidr/ it's like a well-tailored pair of
trousers but it's moist and perfect
for your grandparents!

On Tue, 02 Dec 2003 00:27:35 GMT, "Znarf" wrote:
The ICGA could only access and review the source code upon an accusation of
"cheating." The Accuser must provide a factual basis for the accusation
(e.g., it must be more than "The accused program performed the same two
moves as program x."). This would protect entrants from unfounded
accusations.

Not really. Read your statement again. Where are the facts in the
accusation? What facts can you have as a cc tournament entrant, about
another program?

You have no source code, no performance of the suspect program on any
critical positions or test suites. Nothing!

All you have is a suspicion, based on the play you see the suspect
program make at the tournament WHICH IS ALREADY IN PROGRESS.

Are you going to stop the whole tournament and examine the suspect
program for a few hours? Based on someone's _suspicions_ ??

I don't think there is a good answer anywhere in this rat hole!

You either run the risk of someone cheating and winning a tournament
with a program like Crafty, or you disrupt the tournament and make
unfounded accusations.

I have another idea, which may not be popular, but here goes:

In an open tournament, any program competes. Bring your open source
program, modified or not. You're in like a porch climber!

Open source authors, like Dr. Hyatt, would just need to keep their
strongest version under wraps until after that year's championship.

It seem's odd that someone would make bikes, give them away freely,
and then say "but you can't race with this bike, against me".

Phooey! Every "bike" can "race" in an open tournament. Every program
can compete with different settings or "personalities" that Joe or
Jill Consumer have discovered, and care to enter into the open
tournament.

If you (as a chess programmer) make your program open source, you need
to make one version stronger than the source you released, and keep it
confidential, to compete with an edge in the next open cc tournament.

Result?

Lots of people make lots of little modifications to Crafty and other
open source chess programs. Most will be bad, but some will be good.
More competitors, more interest in cc, and any good modifications that
prove valuable may expand our knowledge of what makes a stronger chess
program.

Note that I'm not saying anyone has the right to take open source code
and sell it commercially. I'm only saying for an open tournament,
every program, of every type, should be allowed to compete.

That clears the air of any claims of cheating, and is in the true
spirit of an open tournament. IMO

It also makes computer chess more interesting, to more people.

If current open source chess program authors are offended by that, I
believe they should not make their program open source, anymore, and
really ask themselves "why did I make this program open source?".


Your thoughts?


Darrz