OpenChess

Mr. Hyatt, you mentioned the "one author, one entry" rule in a discussion elsewhere, which I excerpt below. In pondering the imponderable, I cannot imagine how any of the ippolit derivatives could ever comply with the rule as you state below. The reason is that ippolit has a) anonymous/unknown authors, b) is apparently 'ownerless', and/or c) is public domain.

However, could not someone take up the source, modify it in some substantial way, and then GPL their contributions and publish it under their name, and then under such circumstances would this hypothetical programmer's ippo-derived engine comply with the 'one author, one entry' rule? This would assume that only one person would get to do this.

In other words, is there any scenario whereby an ippo-derivative could find an adoptive parent so-to-speak and get on the path to CCT legitimacy? Or is it and its progeny forever doomed by a scarlet A?

To make my point clear I propose a change like the following:

1. Each participant (engine) must be an original work or a license compliant derivative of an original work. No entry can contain code from another program unless code is public domain, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.

Don't like that wording. The intent of the rule is "one author, one entry" plain and simple. I do not want to allow entries that copied a "public domain" source as that violates the very idea we are trying to adhere to, "one author, one entry".

That is a difficult question. At the moment there is a claim that it is a reverse-engineered Rybka 3. No real evidence to support this. A few table similarities only. There is more evidence that it is not a RE Rybka although there may be some common parts for all we know. The problem for CCT, ACCA and ICGA events is that the author has to enter the program or else appoint someone to do this. Without any known author for the IP* family, there's no way to get past this hurdle. No, just "taking over the source, modifying it" doesn't get past the original author's responsibility, otherwise someone could reverse-engineer anything anonymously, make the source available, have an accomplice then "take over" the code and enter it at will.

I believe that for the moment, everyone has decided to not accept any ip* family member until the author issue has been resolved, which may be never. We've never had a case like this one where there is a strong program and anonymous author(s) so there is not much in the way of precedent to deal with this specific circumstance. In general, the author is the one to be protected from any "damage" by the claims of "you have a clone or whatever," but with no visible author this seems to not be an issue. Then the other authors should be protected by not allowing a questionable program to participate when no author is available to discuss the program's origins in detail. This is a catch-22 that boggles the mind.

No entry can contain code from another program unless code is public domain, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.

Does this also include Nalimov (or Gaviota) tablebases? Old-timers might remember that Bruce Moreland was against more than one entrant in any event using them (he suggested that Nalimov himself could designate who could use them), but he seemed to be a rather solitary voice, and I think the (ICGA) powers-that-be made some decision along the lines that EGTBs/access were so uniform in nature (hmm, tell that to SMK with his ShredderBases) that the "code re-use" rule should not apply to them. [I would agree that allowing everyone to use the same TBs in root positions is an OK idea, but in search it becomes more dicey --- for that matter, since GUIs often uses TBs nowadays, can two entrants both use the same GUI? ].

BB+ wrote:

No entry can contain code from another program unless code is public domain, or be a "clone" of another program. This includes any "personality" settings of an originating program. This includes opening books.

Does this also include Nalimov (or Gaviota) tablebases? Old-timers might remember that Bruce Moreland was against more than one entrant in any event using them (he suggested that Nalimov himself could designate who could use them), but he seemed to be a rather solitary voice, and I think the (ICGA) powers-that-be made some decision along the lines that EGTBs/access were so uniform in nature (hmm, tell that to SMK with his ShredderBases) that the "code re-use" rule should not apply to them. [I would agree that allowing everyone to use the same TBs in root positions is an OK idea, but in search it becomes more dicey --- for that matter, since GUIs often uses TBs nowadays, can two entrants both use the same GUI? ].

GUIs that make chess move decisions (openings, endings) would seem to be disqualified unless they were written by the engine author. Otherwise you have a program not written by the author playing chess for part of the game at least. This would suggest that UCI is a fundamentally wrong design at least for computer competitions.

Let's take both cases.

1. EGTB code. This is a F(x) -> Y for all values of X and Y. That is, one input always produces the same output. We've always maintained that using this kind of code is perfectly OK. What is the point of demanding that everyone design and code an EGTB generator and probe code, when their answers will be exactly the same as everyone else's?

2. GUIS are a totally different issue. They are (particularly for UCI GUIs) taking on a significant part of the game-playing functionality. They handle the opening book and move selection (which is not a 1 to 1 mapping as EGTBs are). They can handle book learning. They handle time allocation. They handle egtb positions at the root. The GUI can actually play far more moves in a game than the engine plays. And many of us consider _this_ a serious problem. Just another reason I don't deal with UCI at all. I want the GUI to serve as the user interface between the engine and the user, I don't want the GUI involved in any chess-playing decisions at all.

EGTB code. This is a F(x) -> Y for all values of X and Y. That is, one input always produces the same output. We've always maintained that using this kind of code is perfectly OK. What is the point of demanding that everyone design and code an EGTB generator and probe code, when their answers will be exactly the same as everyone else's?

I tend to agree with you on this, though I would prefer that the "shared code" of competitors was public domain (and then the rules are sufficiently clear), and one didn't have to track down someone for permission to use it. Also, the "functional equivalence" is a bit debatable, as I can name at least five different functions F that have nuances in usage [DTM, DTC, DTZ50, loss-draw-DTM (as with FEG), win-draw-loss]. Again I see the problem as being more that: one guy writes code, and then shares with some, but not all.

BB+ wrote:I tend to agree with you on this, though I would prefer that the "shared code" of competitors was public domain (and then the rules are sufficiently clear), and one didn't have to track down someone for permission to use it. Also, the "functional equivalence" is a bit debatable, as I can name at least five different functions F that have nuances in usage [DTM, DTC, DTZ50, loss-draw-DTM (as with FEG), win-draw-loss]. Again I see the problem as being more that: one guy writes code, and then shares with some, but not all.

Hello BB,

Gaviota tablebases!

Later.

BB+ wrote:

EGTB code. This is a F(x) -> Y for all values of X and Y. That is, one input always produces the same output. We've always maintained that using this kind of code is perfectly OK. What is the point of demanding that everyone design and code an EGTB generator and probe code, when their answers will be exactly the same as everyone else's?

I tend to agree with you on this, though I would prefer that the "shared code" of competitors was public domain (and then the rules are sufficiently clear), and one didn't have to track down someone for permission to use it. Also, the "functional equivalence" is a bit debatable, as I can name at least five different functions F that have nuances in usage [DTM, DTC, DTZ50, loss-draw-DTM (as with FEG), win-draw-loss]. Again I see the problem as being more that: one guy writes code, and then shares with some, but not all.

I think Miguel has done a public domain egtb implementation, which makes it possible for everyone to have access. Eugene's code was problematic due to the compression code, which is unfortunate. I'll try to look at Miguel's code myself and see if i can coax it into working inside Crafty as a reference point.

As far as the different implementations (DTM, DTC, DTZ, etc) the final result is still "fixed". Choosing which you want is an implementation detail that each engine programmer can make. Nothing prevents using more than one, in fact. I'm far more concerned about sharing code that actually plays parts (or all) of a game. We've brought this issue up several times, but quite a few don't care (primarily because they are using a GUI that does this and don't want to lose access to it for tournaments).

hyatt wrote:

BB+ wrote:

EGTB code. This is a F(x) -> Y for all values of X and Y. That is, one input always produces the same output. We've always maintained that using this kind of code is perfectly OK. What is the point of demanding that everyone design and code an EGTB generator and probe code, when their answers will be exactly the same as everyone else's?

I tend to agree with you on this, though I would prefer that the "shared code" of competitors was public domain (and then the rules are sufficiently clear), and one didn't have to track down someone for permission to use it. Also, the "functional equivalence" is a bit debatable, as I can name at least five different functions F that have nuances in usage [DTM, DTC, DTZ50, loss-draw-DTM (as with FEG), win-draw-loss]. Again I see the problem as being more that: one guy writes code, and then shares with some, but not all.

I think Miguel has done a public domain egtb implementation, which makes it possible for everyone to have access. Eugene's code was problematic due to the compression code, which is unfortunate. I'll try to look at Miguel's code myself and see if i can coax it into working inside Crafty as a reference point.

As far as the different implementations (DTM, DTC, DTZ, etc) the final result is still "fixed". Choosing which you want is an implementation detail that each engine programmer can make. Nothing prevents using more than one, in fact. I'm far more concerned about sharing code that actually plays parts (or all) of a game. We've brought this issue up several times, but quite a few don't care (primarily because they are using a GUI that does this and don't want to lose access to it for tournaments).

Does anybody know if the "robbobase" code is a rip or original?

I think Miguel has done a public domain egtb implementation, which makes it possible for everyone to have access

I don't know what the current licensing situation is, but it seems that you second statement is more precise than the first.

Copyright (C) 2000-2009, Miguel A. Ballicora
This software is provided 'as-is', without any express or implied warranty of any kind. In no event or circumstance will the author be held liable for any damages arising from the use of this software. Anyone is permitted to use this software, but its distribution is not allowed without the consent of the author. The origin of this software must not be misrepresented and you must not claim that you wrote the original software. Modification of the software is not permitted. (mails to the gmail account: mballicora@gmail.com)

That's not exactly "public domain", though the Anyone is permitted to use this software is probably sufficient for chess-engine tournaments. However, the Modification of the software is not permitted might make this more debatable.

Does anybody know if the "robbobase" code is a rip or original?

The format (win-draw-DTC) of the TotalBases is already different from anything else I know, though I guess one could modify other code to adapt to this. The indexing and "symmetries" (what happens when both kings are on the same long diagonal) also seem unique to it. The TripleBases use some sort of run-length encoding, which conceivably could be borrowed from something else. The compression code is rather lousy at computing a suffix tree (if it is copied, it is maybe from a CS homework assignment -- for instance, bzip2 has a much better method), though the decompression code seems to have reasonable performance.