Independent Computer Chess Discussion Forum
https://open-chess.org/
You might want to read one of my ramblings in the year 2000 4-5 years before Fabien and Vas entered the arena. That new trend was already in full swing to move from a big fat eval to an eval only doing the most essential things based on the increasing depths because of modern hardware and new search techniques such as nullmove, futility pruning and the focus on reductions.BB+ wrote:Many things can affect originality. If anything, I would argue that increasing knowledge in computer chess actually increases the capacity for originality. Once Letouzey had shown that a "low knowledge" EVAL could be competitive (already with Fruit 1.0 Rajlich had commented on this), there was plenty of room for exploring this idea, to what extent it could be taken, etc. Similarly, when Rajlich showed that "statisticial pruning" could be quite effective with today's (or 2005's) search depths, there were many ways to implement what was going on. Even with null move, there were (and are today) competing versions, including recursive nature, parameter tweaks (eg Heinz), when to turn it off, etc. But Rajlich largely took Fruit's (limited) EVAL knowledge, with a few replacements and additions. As Letouzey has said, it matters as much what VR didn't use as what he did. Similarly, IPPOLIT to some extent (large in some places, smaller in others) based its pruning schemes on Rybka 3's and its eval on Kaufman's R3 work. Neither of these have been transferred to the same degree in Stockfish or Komodo, but rather new "riffs" have been appeared, in concordance with Letouzey's extraction of a couple of ideas as is common, and normal.Rebel wrote:Do you really want to believe that INCREASING KNOWLEDGE doesn't affect originality?
Firstly, the LION case was not properly "a GPL breach", as they didn't convey/distribute the program, which is (essentially) a pre-condition of a GPL violation. [Furthermore, they made the source code available to the ICGA for inspection, though this was not strictly necessary for GPL compliance IMO]. Moreover, they did not admit to "copying" per se, but rather Jaap's words are: they pointed to all the newly developed routines which surrounded the ideas by Letouzey. Indeed, after the inspection, the conclusion was only: it was clear that the code was similar to Letouzey’s. I guess if these new routines had "surrounded the code" (not ideas) by Letouzey, and "the code was taken from Letouzey's" (not just similar to), then I would find your argument more substantial.Rebel wrote:The LION guys promptly admitted the Fruit origin with reference to Fabien's conjecture in this thread, copying. It's quite different with Vas who vehemently denied copying Fruit and from the beginning hinted using Fruit ideas only. Why would he care about the LION (a GPL breach) case?
The FSF complaint was made by Letouzey only after the ICGA verdict was announced. [One could also argue that Rajlich never tried to contact Letouzey, especially after his initial Open Letter appeared, though by early 2011 my recollection is that VR was already fairly inactive on his forum, and made no response to Letouzey's open letter].Rebel wrote:Problem is that Fabien instead of talking to Vas first (I am not aware Fabien tried) immediately filed a complaint to the FSF and to the ICGA.
Back in 1995, there were no words about "originality" at all, I think everyone just accepted it as an understood premise (see Berliner's 1986(?) complaint against Hsu for the re-use of the "Cray Blitz eval simulator" code). The ICCA/ICGA/ACM would just refuse to admit the entry if they had a problem with it. [There was also no explicit rule about multiple entries, for that matter]. After Gunda (1998) and List (2003), the wording became more exact. The phrase "original work of the entering developers" was already extant in 2006, and the primary 2007 change was to clarify "application details" in response to LION++.Rebel wrote:1. Was the LION case a trigger to the new 2007 rule #2?
2. What were the contents of rule #2 before 2007?
Whether or not others had toyed with the same, my point was that Rajlich had specifically inquired regarding Letouzey's work on this (here).BB+ wrote:Once Letouzey had shown that a "low knowledge" EVAL could be competitive (already with Fruit 1.0 Rajlich had commented on this) ...
There is a BIG difference between "using public available knowledge" and "copying public available code".Rebel wrote:You might want to read one of my ramblings in the year 2000 4-5 years before Fabien and Vas entered the arena. That new trend was already in full swing to move from a big fat eval to an eval only doing the most essential things based on the increasing depths because of modern hardware and new search techniques such as nullmove, futility pruning and the focus on reductions.BB+ wrote:Many things can affect originality. If anything, I would argue that increasing knowledge in computer chess actually increases the capacity for originality. Once Letouzey had shown that a "low knowledge" EVAL could be competitive (already with Fruit 1.0 Rajlich had commented on this), there was plenty of room for exploring this idea, to what extent it could be taken, etc. Similarly, when Rajlich showed that "statisticial pruning" could be quite effective with today's (or 2005's) search depths, there were many ways to implement what was going on. Even with null move, there were (and are today) competing versions, including recursive nature, parameter tweaks (eg Heinz), when to turn it off, etc. But Rajlich largely took Fruit's (limited) EVAL knowledge, with a few replacements and additions. As Letouzey has said, it matters as much what VR didn't use as what he did. Similarly, IPPOLIT to some extent (large in some places, smaller in others) based its pruning schemes on Rybka 3's and its eval on Kaufman's R3 work. Neither of these have been transferred to the same degree in Stockfish or Komodo, but rather new "riffs" have been appeared, in concordance with Letouzey's extraction of a couple of ideas as is common, and normal.Rebel wrote:Do you really want to believe that INCREASING KNOWLEDGE doesn't affect originality?
I remember Chrilly, he said, why would you do things in eval and waste speed when search can solve it for you, why do things twice?
Make sense?
I don't see Fruit as the mother of all chess engines. He also stood on the shoulders of others.
None blames him for using public available knowledge.
After inspection comparing the 2 source codes Björnsson and Schaeffer concluded LION was “a close derivative” of Fruit. From the same page :BB+ wrote:Firstly, the LION case was not properly "a GPL breach", as they didn't convey/distribute the program, which is (essentially) a pre-condition of a GPL violation. [Furthermore, they made the source code available to the ICGA for inspection, though this was not strictly necessary for GPL compliance IMO]. Moreover, they did not admit to "copying" per se, but rather Jaap's words are: they pointed to all the newly developed routines which surrounded the ideas by Letouzey. Indeed, after the inspection, the conclusion was only: it was clear that the code was similar to Letouzey’s. I guess if these new routines had "surrounded the code" (not ideas) by Letouzey, and "the code was taken from Letouzey's" (not just similar to), then I would find your argument more substantial.Rebel wrote:The LION guys promptly admitted the Fruit origin with reference to Fabien's conjecture in this thread, copying. It's quite different with Vas who vehemently denied copying Fruit and from the beginning hinted using Fruit ideas only. Why would he care about the LION (a GPL breach) case?
Absolutely!hyatt wrote:There is a BIG difference between "using public available knowledge" and "copying public available code".Rebel wrote:You might want to read one of my ramblings in the year 2000 4-5 years before Fabien and Vas entered the arena. That new trend was already in full swing to move from a big fat eval to an eval only doing the most essential things based on the increasing depths because of modern hardware and new search techniques such as nullmove, futility pruning and the focus on reductions.BB+ wrote:Many things can affect originality. If anything, I would argue that increasing knowledge in computer chess actually increases the capacity for originality. Once Letouzey had shown that a "low knowledge" EVAL could be competitive (already with Fruit 1.0 Rajlich had commented on this), there was plenty of room for exploring this idea, to what extent it could be taken, etc. Similarly, when Rajlich showed that "statisticial pruning" could be quite effective with today's (or 2005's) search depths, there were many ways to implement what was going on. Even with null move, there were (and are today) competing versions, including recursive nature, parameter tweaks (eg Heinz), when to turn it off, etc. But Rajlich largely took Fruit's (limited) EVAL knowledge, with a few replacements and additions. As Letouzey has said, it matters as much what VR didn't use as what he did. Similarly, IPPOLIT to some extent (large in some places, smaller in others) based its pruning schemes on Rybka 3's and its eval on Kaufman's R3 work. Neither of these have been transferred to the same degree in Stockfish or Komodo, but rather new "riffs" have been appeared, in concordance with Letouzey's extraction of a couple of ideas as is common, and normal.Rebel wrote:Do you really want to believe that INCREASING KNOWLEDGE doesn't affect originality?
I remember Chrilly, he said, why would you do things in eval and waste speed when search can solve it for you, why do things twice?
Make sense?
I don't see Fruit as the mother of all chess engines. He also stood on the shoulders of others.
None blames him for using public available knowledge.
I am not sure what I am overlooking, I am in much agreement.That is the one thing you keep overlooking completely. One can learn from others without copying their code. It happens all the time.
You are conflating two distinct determinations by Björnsson/Schaeffer. This is what is said: After inspection by Yngvi Björnsson and later (independently) by Jonathan Schaeffer it was clear that the code was similar to Letouzey’s. At first, neither of them "concluded" that LION++ was a "close derivative" (which occurs in the3rd sentence of Rule #2) merely that "the code was similar" (in the sense of originality, as with the first sentence of Rule #2, namely each program must be the original work of the entering developers).Rebel wrote:After inspection comparing the 2 source codes Björnsson and Schaeffer concluded LION was “a close derivative” of Fruit.
Again you ignore the words as expressed by Jaap, such as "ideas by Letouzey". If Jaap had meant code, then he would have said so. [As Riis propounded regarding "plagiarism": I note that the writers of this charge are scholars with doctoral degrees and are men whose profession obliges them to choose their public words with careful precision]. Only by pretending that "it's obviously about code copying of Fruit" (in distinct contradiction to what publicly took place in Turin, and moreover to Jaap's specific terminology in his recap editorial) could Rajlich remain unworried.Rebel wrote:Meaning, I still fail to see why Vas should be worried by the LION case, it's obviously about code copying of Fruit.
Some Rybka code, at least to the extent that is determinable from the disassembly, is also "similar to Letouzey's" in various places. See Appendix A of RYBKA_FRUIT (the iterative deepening) for instance.Rebel (quoting Jaap van den Herik) wrote:...it was clear that the [LION++] code was similar to Letouzey’s.
Yes, the infamous "vague" rules argument. Again, there is some responsibility by the entrant (particularly a new member of the community) to seek clarification of any "vague" points. As Jaap said in his LION++ editorial: For long-standing members of our community – we assume – the above the interpretation of the rules is clear. ...So far, we believed that the three-year rule was a rule for the continuity of the membership, now we know that this rule should be interpreted as a rule for familiarisation with the ICGA community.Rebel wrote:As such I don't agree with Levy's comment, "Vas could (should) have known" with respect to the green above. ... [Levy] is responsible for clear rules and the rules weren't clear.
There is a lot to say about this especially from my commercial background views.BB+ wrote:The FSF complaint was made by Letouzey only after the ICGA verdict was announced. [One could also argue that Rajlich never tried to contact Letouzey, especially after his initial Open Letter appeared, though by early 2011 my recollection is that VR was already fairly inactive on his forum, and made no response to Letouzey's open letter].Rebel wrote:Problem is that Fabien instead of talking to Vas first (I am not aware Fabien tried) immediately filed a complaint to the FSF and to the ICGA.
Code: Select all
Hi Fabien,
A question crossed my mind.
Is the IGCA (or you) planning a financial compensation from Vas when found guilty?
If so I don't want my name under the document. It would be a bridge too far for me.
I am not saying you should not, you have every right to do so.
Let me know.
EdCode: Select all
Hi Fabien,
Thanks for answer and sorry to bother you.
What about the FSF? Do you think it's technical possible the ICGA with a tribunal verdict can go to the FSF to pressure VR for compensation?
It seems to be a bit far fetched but when it comes to money I have a low opinion on David and Jaap.
Anyway the first deed of the tribunal seems to be a ban on Chris W. the programmer of CSTAL not allowing him to enter the web site. Not a good start.
Welcome back in the CC arena :)
EdThis program is based on the source code of Fruit, and was disqualified because this kind of derivative work is not allowed by the rules of the ICGA tournaments.BB+ wrote:Despite your claims, the LION++ case was not particularly about "code copying" in the sense you imply.