SuneF wrote:mhull wrote:
In programming, especially a chess program, adopting significantly large and critical blocks of very specific symbiotic logic and factored weights verbatim is only permissible in an acknowledged code fork. It certainly couldn't pass the smell test as an original work. And the distance between subsequent versions to the plagiarized starting point will hardly matter (to most people) if a programmer is shown to be so dishonest.
Ordinarily yes. What makes the Rybka situation special is that Vas couldn't have adopted "
significantly large and critical blocks of very specific symbiotic logic and factored weights
verbatim" as Rybka is bitboard and Fruit is mailbox. At least for the evaluation and move generation code it would have to be coded completely different - that is a fact.
NO it isn't "a fact". There are parts of my eval that are not "bitboard-centric". Low-level stuff is, but not all. Ditto for move generation. One can hide much with macros.
And then there is the issue of hashing, which would be the same in the eval whether you use bitboards or not (pawn hash, perhaps king safety as some use). And then we get to critical things like search, move ordering, pruning, reductions, extensions. He could have copied significant parts. And you are overlooking the issue that we now know that he copied parts of Crafty, which _is_ a bitboard program. Suddenly the changes to Fruit's eval don't appear to be so difficult since all the support code may well have been copied (we are quantifying this as I write.)
We also know that Rybka has new important material terms in the evaluation and the search seems original as well.
"seems" original? How would one conclude that. PVs, depth and node counts are intentionally misrepresented to hide search details. Every think to wonder "why"???
What they need to prove then, is either that some other parts of the engine contains large parts of copied code (for instance the hashing or protocol) or that large parts of the bitboard code is functionally equivalent to the mailbox code. The latter is a bit problematic however, as most engines are known to contain certain large parts of functionally equivalent codes, like for instance the SEE, Qsearch, Nullmove and so forth. No one would claim Fruit was a derivative of Crafty just because it had sections of nullmove code that was functionally equivalent to Crafty for instance.
More is coming.
What annoys me most about this whole issue is that we do not have objective means and rules to specify what is legal to copy and what is not. It's always a judgement call in every single case. This makes the whole process too ad hoc and un-scientific IMHO.
At the basic level, nothing can be copied. We have at least agreed previously that everyone can use egtb.cpp if they get Eugene's permission. Ditto for my rotated bitboard move generation (and now Pradu's magic move generation code). Hopefully as this progresses, we can finally formalize a statement about this specific issue. I still like my idea of it is ok to copy F(x) where we have a relationship Y = F(X) where for each unique value of X, there is one and only one unique value Y that the function can return. Move generators. SEE. SAN input/output. Not evaluation, or search, or move ordering, or hashing, or any of a number of other things. Whether everyone will agree to that or not is unknown, but it offers a pretty precise definition that any decent programmer can understand and follow.
The process should be reversed, first we need to establish what is legal and what is not, then we need to decide how to punish the rule breakers and only then does it make sense to begin considering the individual engines. Otherwise we are having a trial and jury with no accepted laws to judge by.
For fruit it is easier. _nothing_ can be copied because of the GPL. Unless the copied/modified source is also released, which it was not.
