Crafty accused of copying Fruit PST

[michiguel]

...Since then, Miguel scored a very minor hit with his work on PST and a few technically competent others have taken pot shots at it without doing any damage.

I do not know if you think this is a complete hit on a minor thing, or a minor hit on a big thing, but the issue about PSTs is something of a tremendous importance because of the harmful precedence it sets.

Miguel

[bob]

While your reply is certainly well thought out, it is simply wrong with respect to copyright law. Copyright law is intended to protect effort, as opposed to text. That is, random text can't be copyrighted, but if something takes effort to produce it, that product can be copyright. And indeed, that has been the metric used in many computer software copyright cases.

The clearest example is that you can not copyright a single PGN game, but you can copyright a collection that took effort to produce. The example often quoted in CC literature is the book with "Fischer's 100 greatest games." That took effort to compile and publish (not forgetting the annotation effort). And it is copyrighted. You want to pin this down to the "OK you can't copyright 1, you can copyright 100, so can you copyright 10, or 30, or 50. I believe that is a decision the court would have to make. If there is no effort required to compile 10 games, I doubt they would uphold a copyright claim. If you took Tal's 10 greatest games and spent a chapter on each annotating each move, yes the court would uphold the copyright claim.

It about the effort, and it is not so easy to say how many evaluation terms one can copy before it is over the "line". For pure source code, the ICGA has simply said "none" without calling the person the code came from part of your team, which excludes him from any other team. Is that the best solution? It is draconian, but it is enforceable as well, which is an advantage. A clear line is always better than a vague one.

However, let's back up a program. What about Rybka 1.6.1 and Crafty? Did you look at that part of the report. It is _really_ revealing about how early "100% original rybka" was anything but original. And it gives insight into the integrity of one that would claim it was 100% original yet absolute proof in the report shows it was simply copied from Crafty 19.x... OK, we have a prior act that was _really_ bad.

Now, on to Fruit/Rybka. What about all of the evidence as a whole, All the PSTs having the same initialization code derivation. The eval similarities. The ugly 0.0 bug in the time management. The iterated search driver that is the same?

One has to draw a line, and there is no way it can be drawn somewhere beyond the point where Rybka/Vas went. He didn't just cross any reasonable line, he crossed the line and kept driving for months.

I don't see any viable explanation that says "this is OK." If it was, one could take any two programs and find enough similarities to make you blink. That doesn't seem to be the case, at least when applied to my code. I've compared fruit's search, Crafty's search, Fruit's basic move selection mechanism against Crafty's, ditto for eval. They don't even look like 10th cousins, much less brother/sister. I don't buy this "all are very similar". It's a thought, but it is not founded on any exhibited data (except for the fruit/rybka case). It appears to me that everyone is trying to use tunnel vision and say "look fruit and rybka are so close because chess algorithms are fairly simple, the range of useful numbers is very small, and speed concerns limit the ways code can be written. To a point where the two programs look so similar, not because they are close derivatives, but because they HAVE to be by the very nature of chess programs. If that is true, one should be able to find a third or fourth program that is not advertised as derived from Fruit, but which still shows those same similarities. To date, no one has offered such evidence to support that theory, and until I see it, I don't buy it. I've looked at a couple of dozen programs over the years, from the 1970 fortran program COKO, to greenblatt's mack hack pdp 10 assembly code, to Slate's chess 4.x CDC assembly code, to Cray Blitz (of course) to Chaos, to LaChex (Los Alamos program) to today's current group of open-source programs. And I don't see just one overall design, with similar code. I see lots of different ways to implement each and every thing required to create a chess program.

Simple things. Compare SEE. Move ordering ideas. Evaluation concepts, scores, and exact methodology. This idea of "just a very few ways" to do these things doesn't jive with reality. Maybe in a few small cases, sure. But not across a wide slice of a chess engine...

That's where I have the problem with these ideas.

Bob,
I was talking about "reuse of evaluation concepts", not about general copyright questions. Also not about chess games and PGN files. We are in the domain of software. I can understand your intention to compare "copying of 100 chess games" somehow to software in order to discuss that "draw a borderline" point. But no, it simply does not apply to the point I am making. There is nothing comparable to the "evaluation concepts" that could be free of copyright in the domain of "large collections of chess games". From the (assumed) fact that copying a collection of 100 games violates copyright (if a judge decides so) you can't derive that partially reusing 30 evaluation concepts violates it, too. Apples and oranges.

If we declare reusing many eval concepts as illegal then virtually all chess engines are illegal. And if we declare 44% eval feature overlap as legal but 74% (following the quite subjective numbers of Mark Watkins since we have nothing better) as illegal then this is not comprehensible for anyone. You did not address these two central points of my previous posts, for obvious reasons.

This is not so much about copying ideas, although copyright certainly applies to that. But it is treated different for computer software precisely because computer programs are an unusual blend of coding effort, design effort, etc.

Note that Mark's comparison was not intended as a "giant piece of evidence". It was meant to extend the investigation from Rybka 1.0 beta to Rybka 2.3.2 without resorting to a big expense of time. Would have been nice to have source for all the rybka versions. This would be completely resolved (for most at least, some will never accept any verdict other than innocent it seems) if we could compare source to source. That's pretty easy compared to using RE to compare a binary to a different source. His comparison was simply to show that much of the fruity evaluation is still present in 2.3.2a, with significantly less effort (although it was still a major effort to put what he did together.)

And I was also talking about the Fruit/Rybka case. Rybka 1.6.1 is irrelevant for the ICGA, for the FSF, and for computer chess today, even if there is no doubt that it contained some Crafty code. So please stay on topic. I can understand that you are "not amused" regarding that 1.6.1 case from the past, and I am not saying that Vas were innocent w.r.t. early pre-1.0beta Rybka. But please do not mix it with the relevant part about Fruit/Rybka.

That is just a convenient way out of a distasteful discussion. He clearly copied Crafty 19.x to create 1.6.1... that adds impetus to the conclusion that he also copied Fruit to create 1.0 beta. Behavior tends to repeat. And courts allow such evidence precisely to show a "pattern of behavior that suggests that the current charge fits the pattern..."

Also nobody has ever stated that Crafty and Fruit had big similarities, so even that part of your post is fully off-topic. Same for the related section about "different overall design of various chess programs", that is simply unrelated to what I wrote, nothing but noise.

Prepared for more obfuscations,
Sven

[K I Hyams]

...Since then, Miguel scored a very minor hit with his work on PST and a few technically competent others have taken pot shots at it without doing any damage.

but the issue about PSTs is something of a tremendous importance because of the harmful precedence it sets.

Miguel

No it isn't.

The concept of a precedent, is something that a jury might find relevant - scientists and programmers need facts. Your work does not imply that there is a precedent in this case. In a criminal trial any competent defence lawyer and forensic team will inevitably find small areas of overstatement of certainty in a large body of prosecuting evidence. Any sensible member of a jury will intuitively be aware of that fact and instead of saying that a precedent has been found that rocks the whole case, he will simply downgrade the significance of the particular piece of evidence in question.

Not only are you a top quality programmer, you are also an experienced scientist. You are forensic and programming skills combined. Quite a “team”. Therefore, it would be surprising if you couldn’t find a small area of uncertainty or overstatement in a large bulk of evidence. However, it is noteworthy how little progress the rest of the specialists on the Rajlich team appear to have made.

Perhaps a jury would look at a trade off - your opinion that the evidence is unconvincing against Don Dailey’s opinion that it is convincing. If a jury then looked at the weight of expert opinion left after the pair of you had been removed from the equation they would see on one side a stellar line up who, having taken part in a painstaking investigation, have concluded that plagiarism took place and on the other side, a coterie consisting basically of Ed, Whittington and Rolf.

Although the outcome of your work would not be seen by a jury as precedent, if it was demonstrated to them that that Rajlich copied Crafty into Rybka, they most certainly would see that as setting a precedent.

The other thing that a jury would take into account is circumstantial evidence. The right of silence still exists but juries in a number of western countries are told that they are entitled to take inferences from the fact that a defendant refuses to defend himself. That jury would also take a dim view of the fact that Rajlich refuses to provide the source code of Rybka 1. They would be informed that if he did and it was found to be clean, it would destroy much of the case of his accusers and that he couldn’t produce a credible excuse for failing to do so.

[michiguel]

...Since then, Miguel scored a very minor hit with his work on PST and a few technically competent others have taken pot shots at it without doing any damage.

but the issue about PSTs is something of a tremendous importance because of the harmful precedence it sets.

Miguel

No it isn't.

I thought you were talking about my humble contribution, restricted to PSTs, but based on the text below, you are talking about the whole case.

The PST establishes a criteria by which an engine could be considered <insert you name here, dirty, clone, derivative, whatever>. I considered this criteria dangerous, because engines could fall under it as guilty when they are not. You may disagree with me, but I hope you see that I based it on concrete arguments.

In addition, the trend shifts to discourage authors to learn concepts, directly or indirectly, and apply them on their own. In the case of PSTs, I see this as a situation of copyrighting concepts, which is wrong. I do not believe that we can copyright the numbers -3,-1,0,+1 (for this particular case, for instance) when they express intrinsically a rudimentary chess knowledge (centralize, punish edges). In general, I do not believe we should be able to copyright elements of VERY low information content either.

There are more things at stake here than just VR and I just expressed one in this post.

I do not even use static PSTs (they are initialized to zero), but if I do... I feel some may look way too close (when the criteria is apply as in this case). Mostly if you use formulas, which is what I do all the time. But I am digressing...

Miguel
PS: I am not in any "Rajlich team".

The concept of a precedent, is something that a jury might find relevant - scientists and programmers need facts. Your work does not imply that there is a precedent in this case. In a criminal trial any competent defence lawyer and forensic team will inevitably find small areas of overstatement of certainty in a large body of prosecuting evidence. Any sensible member of a jury will intuitively be aware of that fact and instead of saying that a precedent has been found that rocks the whole case, he will simply downgrade the significance of the particular piece of evidence in question.

Not only are you a top quality programmer, you are also an experienced scientist. You are forensic and programming skills combined. Quite a “team”. Therefore, it would be surprising if you couldn’t find a small area of uncertainty or overstatement in a large bulk of evidence. However, it is noteworthy how little progress the rest of the specialists on the Rajlich team appear to have made.

Perhaps a jury would look at a trade off - your opinion that the evidence is unconvincing against Don Dailey’s opinion that it is convincing. If a jury then looked at the weight of expert opinion left after the pair of you had been removed from the equation they would see on one side a stellar line up who, having taken part in a painstaking investigation, have concluded that plagiarism took place and on the other side, a coterie consisting basically of Ed, Whittington and Rolf.

Although the outcome of your work would not be seen by a jury as precedent, if it was demonstrated to them that that Rajlich copied Crafty into Rybka, they most certainly would see that as setting a precedent.

The other thing that a jury would take into account is circumstantial evidence. The right of silence still exists but juries in a number of western countries are told that they are entitled to take inferences from the fact that a defendant refuses to defend himself. That jury would also take a dim view of the fact that Rajlich refuses to provide the source code of Rybka 1. They would be informed that if he did and it was found to be clean, it would destroy much of the case of his accusers and that he couldn’t produce a credible excuse for failing to do so.

[Desperado]

I think that is the point many people do not realize, because they
do not circumvent a general discussion about similarity issues and its
consequences, but drop again into the Ryka story again and again.

I was never involved in the Rybka case and its discussions for all the years,
and if someone has read my posts the last days, he/she will
agree i never expressed my arguments related to the Rybka issue.

It is important imo that some of the experts take a deep breath and
start to abstract the circumstances which are behind the arguments of
Miguel,Sven and some others. (and myself)

So here are some already "abstracted" key points:


* semantical similar/identical code can express different formulars/ideas and must not
be part of a copy process.On the other hand, such copied code with a non relevant
modification may be seen as new idea. What is what ?

* a value or a set of values _can_ be produced by formular and manually improved.
That can lead easily to similarities. Are polished values produced by a formular
part of copyright,? Are values or set of values which can be build with easy formulars
protectable at all ? What is if identical values are used with different correlations ?

* even complete code chunks can be similar/identical because of public domain knowledge.
when does this code get his signature, what effort or effect must it match, to be
considered as original work when it is changed ?

* is there a complexity border for re-using formulars ? Is there some amount
of re-use that is ok ? Can _trivial_ formulars be part of copy protection ?

* ...


As Miguel pointed out already, it is pretty, no i say, _very dangerous_
to stemp these points with an obvious "noGo". At the moment i fear there
are to many experts passing these points with copy,copy,copy,copy !,

- not aware of the consequences that has for the chessprogramming community.
- not aware that these at first glance obvious points are highly complicated.
- not aware how urgent the need to find accordance is.
- not aware there will be two camps because they dont ask for opposite interpretation.
- not aware that they can even represent the opposite of what they think because of existing arguments.
- not aware there are a lot of laymen who simply have to believe inconsiderated conclusions and its consequences
- not aware that has _nothing_ to do with the Rybka case

regards

[K I Hyams]

PS: I am not in any "Rajlich team".

I can see why you would want to point that out. In fact, I didn’t mean to imply that you were. I used the phrase as a shorthand for:

a member of the CCC community who, while he has no specific allegiance to either side of the dispute about the legality of the Rybka engines and no specific feeling of either antipathy or sympathy for the programmer of the Rybka engine, takes an interest in the dispute and views the ICGA evidence with a degree of scepticism.

Now that I have reviewed the phrase that I used, I suspect that it didn't quite carry the full range of ideas that I intended.

[bob]

While your reply is certainly well thought out, it is simply wrong with respect to copyright law. Copyright law is intended to protect effort, as opposed to text. That is, random text can't be copyrighted, but if something takes effort to produce it, that product can be copyright. And indeed, that has been the metric used in many computer software copyright cases.

The clearest example is that you can not copyright a single PGN game, but you can copyright a collection that took effort to produce. The example often quoted in CC literature is the book with "Fischer's 100 greatest games." That took effort to compile and publish (not forgetting the annotation effort). And it is copyrighted. You want to pin this down to the "OK you can't copyright 1, you can copyright 100, so can you copyright 10, or 30, or 50. I believe that is a decision the court would have to make. If there is no effort required to compile 10 games, I doubt they would uphold a copyright claim. If you took Tal's 10 greatest games and spent a chapter on each annotating each move, yes the court would uphold the copyright claim.

It about the effort, and it is not so easy to say how many evaluation terms one can copy before it is over the "line". For pure source code, the ICGA has simply said "none" without calling the person the code came from part of your team, which excludes him from any other team. Is that the best solution? It is draconian, but it is enforceable as well, which is an advantage. A clear line is always better than a vague one.

However, let's back up a program. What about Rybka 1.6.1 and Crafty? Did you look at that part of the report. It is _really_ revealing about how early "100% original rybka" was anything but original. And it gives insight into the integrity of one that would claim it was 100% original yet absolute proof in the report shows it was simply copied from Crafty 19.x... OK, we have a prior act that was _really_ bad.

Now, on to Fruit/Rybka. What about all of the evidence as a whole, All the PSTs having the same initialization code derivation. The eval similarities. The ugly 0.0 bug in the time management. The iterated search driver that is the same?

One has to draw a line, and there is no way it can be drawn somewhere beyond the point where Rybka/Vas went. He didn't just cross any reasonable line, he crossed the line and kept driving for months.

I don't see any viable explanation that says "this is OK." If it was, one could take any two programs and find enough similarities to make you blink. That doesn't seem to be the case, at least when applied to my code. I've compared fruit's search, Crafty's search, Fruit's basic move selection mechanism against Crafty's, ditto for eval. They don't even look like 10th cousins, much less brother/sister. I don't buy this "all are very similar". It's a thought, but it is not founded on any exhibited data (except for the fruit/rybka case). It appears to me that everyone is trying to use tunnel vision and say "look fruit and rybka are so close because chess algorithms are fairly simple, the range of useful numbers is very small, and speed concerns limit the ways code can be written. To a point where the two programs look so similar, not because they are close derivatives, but because they HAVE to be by the very nature of chess programs. If that is true, one should be able to find a third or fourth program that is not advertised as derived from Fruit, but which still shows those same similarities. To date, no one has offered such evidence to support that theory, and until I see it, I don't buy it. I've looked at a couple of dozen programs over the years, from the 1970 fortran program COKO, to greenblatt's mack hack pdp 10 assembly code, to Slate's chess 4.x CDC assembly code, to Cray Blitz (of course) to Chaos, to LaChex (Los Alamos program) to today's current group of open-source programs. And I don't see just one overall design, with similar code. I see lots of different ways to implement each and every thing required to create a chess program.

Simple things. Compare SEE. Move ordering ideas. Evaluation concepts, scores, and exact methodology. This idea of "just a very few ways" to do these things doesn't jive with reality. Maybe in a few small cases, sure. But not across a wide slice of a chess engine...

That's where I have the problem with these ideas.

Hello Bob,

that is the most liberal explenation, argumentation i was able to read from
you, so far (of course i did not read every post on this topic you ever posted somewhere).

So, i want to give you my thoughts about that. If i look at my own engine,
that i consider as original work, i acertain the following facts:

My general design is certainly unique, but with the great number of open
sources there might be people seeing similarities from engine x or y, especially in the detail section.
More and more public domain code will be included in future.
There a more chess programs/programmers than ever before.
Now, because of that fact, there will be even more similarties than ever
before.Today, especially top programs converge in elected parts of the
technical choice of implementation (like the use of magics).
Chess programs are really fragmented in little chunks today.
Of course there will ever be room for implementation details.
But a lot of implemented features in the detail section are close to 100% efficient and are very hard to improve or to change somehow.
(take the mobility feature for bitboards, popcnt * constant). Yes one can
improve and change such a concept, but it will also add code complexity.
And here the maths of the programmer begins, with the question: keep
it simple and stupid or change it for a very,very good reason. There are
many features of this category.
The same for code chunks. Recently some threads appeared in the
programm/technical section here about SEE implementation.Well, my
SEE code is based on the pseudo code given from chessprogramming-wiki, which perfectly matched my datastructures. I am pretty sure
this code chunk will appear in a lot of different engines. If you read
2 engines not knowing this is public domain code, someone will cry again
copy,clone etc... When you look at it, you will realize that such code
is very compact,fast and as long you do not want to trade accuracy for
speed, there hardly wont be, maybe cannot be _big_ changes.
Let us say, i dont pick it up from chessprogramming-wiki, but from another engine and give it a try to improve it like i did. It was one line,
but changing the algorithm, what is it now ? copying ? what is if the
effort is lower than the effect ?
Another question is, why are programmers more liberal in copying parts
of the technical section like magic numbers, but go crazy with pst values.
It is at least debatable.
I also give my best to be author of a "100%" original work,but it is with the
mathematical definition of 100% not possible. I assure you that _every_ formular,concept i use, is tested against 3-10 own ideas and public known ideas,
formulars,concepts. If i want to be my engine competitive, i also
have to accept ideas,formulars found by others. I am not perfect, so
sometimes the inspiration given from other authors, or subtle progress
from chess programmers community, is superior. Accepting this is part
of making progress, and no human on this planet can reinvent all wheels.
Even if, no human can improve all wheels.
(eg: my engine uses the same/similar basic concept for kingSafty/pieceAttacks like Fruit is doing,
but of course with own implementation and different values, because i use bitboards. With respect to code complexity and performance it is hard to do better.
Receiving phD is no requirement for such a formular. Which is another problem with easy formulars,
you cannot forbid sth like that because it already exists. Should i now feel bad ?
eg: i recently decided to see what will happen if i split the search
into several parts (all,cut,pv,whatever type of node). Not because the robo
familiy is doing so, but because i want to explore the possibilities. And
i guarantee to keep it when i find a reason which is profitable to do so.
)

So please, get me right. I _dont_ say you are wrong in any way. But the
thing with _nature_ of chess programming and similarities will certainly match more with my reasoning in the _upcoming_ years.
More public domain solutions, more of them with efficiency getting closer to the maximum and finally the competition aspect to use them in a legal way.

I will add at this point that my engine is privat, because my goal is to release it at stable 3000 elo. (current level is about 2950).
I know as you know how much time it takes when writing an engine from scratch, looping
over it again and again. This is now my hobby from the day i wrote the "hello world" program. But especially the last 3 years i progressed on
and invested a lot of time. Over all these years it summed together, easily
thousands of hours. The problem is, that people finally only see what is
left, but not what you sorted out over the years which is the main work.
Once this is done, i can rewrite my engine within 2 weeks.
So,they only get the tip of the iceberg.
And now my point: if there will be similarities to engines ( i may even do not know),
i can speak at least for myself,
that i _dont want to_ accept your arguments referenced to myself.
Uncouth spoken (not mathematical), I consider my engine as 100% original.
(but think of the case, today would appear another 3000 engine...)

So i hope your opinion is not a generalization of what is right/wrong,
you may hit the wrong groups. You dont only have an opinion, as
expert you also make opinions.

regards, Michael

You really are missing the point. Just having a similar SEE is not particularly problematic. But if your SEE matches, your movgen matches, your make/unmake matches, your eval matches, your search matches...

You get the idea. Sure there is the possibility to have something that looks similar here and there. But if your SEE matches someone else, line for line, loop for loop, etc, then that begins to look very suspicious. If that same trend of identical code extends into other places, it looks worse. This is not about "similar code". It is about "identical code" which is a big difference...

If you write your own code, I don't think it will ever be considered a copy, because the probability of your writing code that looks exactly like someone else's drops as the number of lines of code increases.

[bob]

...Since then, Miguel scored a very minor hit with his work on PST and a few technically competent others have taken pot shots at it without doing any damage.

I do not know if you think this is a complete hit on a minor thing, or a minor hit on a big thing, but the issue about PSTs is something of a tremendous importance because of the harmful precedence it sets.

Miguel

To quote Mark W, by itself it doesn't mean very much. But when taken along with all the other data, it certainly adds credence to the rybka/fruit copying claim.