Fabien's open letter to the community

[Don]

I think you are correct. I personally AM a fan of rewrites but I think there are many chess authors that don't ever rewrite, or have only done so once in years.

Rewriting for the sake of rewriting doesn't serve any purpose at all.
Software with a good architecture will survive many years and many changes.

Robert

I don't rewrite just for the sake of it.

Don

Typical reasons for rewriting:
1. Change of language (e.g. C to C++)
2. Change of underlying data structures (e.g. mailbox to bitboard)
3. Increased programming ability (every decade, my programming skills increase quite a bit, so the code I wrote 20 years ago will benefit considerably from a rewrite).
4. Lost code (yes, it does happen -- I have sent code back to chess authors who lost their original code and who had also sent their code to me on several occasions, for instance).

I don't agree with those.

(1) can be solved via translation. A good program can be translated to a new language without rewriting a thing...
(2) I did the mailbox-to-bitboard translation with Crafty. It only affects a part of the code. Search is unchanged. Move ordering is unchanged. Several other things are completely board representation independent.
(3) I don't think is that common. One does not rewrite _everything_ just because they are a better programmer now than 10 years ago. you might rewrite _parts_. But not the whole thing. That is a huge waste of time and effort.
(4) Never had that happen to the current version of code since I always keep duplicates and backups scattered around.

Bob,

I think there is a fundamental misunderstanding about what a "rewrite" is. You are approaching it as some kind of direct translation.

When I use the term "rewrite" I'm talking about making a completely different program. The new program does not play the same, it's not just a simple port of one data structure or language to another.

I would not bother to "rewrite" a program if that was the only point. I would only do it to take advantage of a different data structure that allowed me to do things differently and better.

Some of your reasons for disagreeing with Dann did not make any sense. For example just because you have not recently lost your source code, how does this refute the notion that losing source code is a reason for rewriting? I don't understand this. I also don't see how changing the data structure is not a typical reason for rewriting. I think it's VERY typical. In fact I have rewritten programs for this very reason. Note that I said rewritten, not "translated."

Don

[Chan Rasjid]

The proof is the author of Fruit himself. "Fabien's open letter to the community". And Vas statement that he claimed that Strelka 2.0 is a clone of Rybka 1.0. This linked Fruit code with Rybka code.

Read it again, then. As many times as it needed to register. He says "legally 'there is no issue". Which means no GPL violation, i.e. no copying of code.

Now I understand of course you take Fabien for an idiot, so that you can ignoe what he writes completely, and just want to use the fact that he says anything at all as a good opprtunity to shoot off your mouth aganst those that you dislike.

But I take Fabien kind of seriously. "No copying of code, but a translation of the algorithm".

So 'poof' goes your 'proof'...

I think you are misinterpreting "translation". Certainly if I translate a book from German to English and sell it as my own, I'll run afoul of copyright laws pretty quickly if the English copy sells well.

This is where most are wrong and HGM right.

The idea of 'derived work' has never been tested yet in any court (internet). Most legal/technical experts interpret 'derived work' in GPL to only include 'copy and paste'. The notions about derived work accepted in general copyright laws do not apply in GPL.

Rasjid

I simply do not agree, nor do I think a court would should this be tested. One can't translate from C to C++ and call that "new and original" and nobody in their right mind would think that is acceptable. Otherwise there can be absolutely no challenge to the legitimacy of ippolit and friends, because they are a translation from binary executable in x86 assembly language to C. So it can't be wrong, correct? That argument has more holes than Swiss Cheese.

from GPLv3 :-

To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.

I think you are correct. The issue that causes dispute is about re-writes that need not involve any cut-and-paste. A re-write of Fruit from mailbox to bitboard could have copyright issue. I did try to search for some expert articles to clarify the issue, but there was none that directly addresses what is at dispute here.

Adaptation or translation of a work in general has copyright issue. In non-software works, the question of cut-and-paste cannot arise as it cannot be done; but in computer software, cut-and-paste or starting from the source codes of a program and then making modifications is the usual means to produce a derivative work and this clearly has copyright issue.

A re-write of Fruit (assuming no cut-and-paste) from mailbox to bitboard would likely be judged on whether it can be considered a 'translation' of Fruit. The translated product could only be deemed 'a translation of Fruit' only if it retains something that could be identified as being distinctly from Fruit - not just things routinely found in chess programs. So if a translation of a chess engine is found by the court to be a derivative work having copyright issue, then it would mean that chess engines do have 'personalities' recognized by the courts and this essence would have copyrights attaching to it like the plot in a novel.

I suspect that a chess engine does have a 'personality'. This would imply that it is legitimate to question if an engine is original or not original. We could call a non-original engine a clone, derivative or whatever - it is an adaptation derived from another engine.

Rasjid.

[Adam Hair]

In the data you sent me before, Glaurung is closer to Fruit than R1 or Strelka to Fruit, which makes me doubt of the "stylistic" relationship between R1 or S to F. In Adam's data and Michael Hart's, when they included more engines, the relation between S and F fell apart. More engines got in between (but I am saying this without checking details). I always saw distinct branches.

Of course, this does not mean absence of cloning or confirmation of it (the material tables may be a dominant factor in changing the "style" of the engine) but I am not sure we can say Strelka's style is close to Fruit more than Glaurung's.

It is very clear, Strelka's "style" is w/o question Rybka's.

Miguel

Using my data, in your tree (not the dendrite), Fruit appears as an isolated engine, which, I am sorry to say, is unlikely, Fruit being an inspiration to many. We are using different clustering methods, for now I trust my graph better, all obvious things are confirmed, and there are some surprises too (you know ).

Disregarding this,

The fact is, my point (1) stands, _therefore_ it is up to Fabien to make claims about the relation between Strelka and Fruit (with implications on Rybka 1.0 Beta).

Kai

Kai, I think you maybe saying " all obvious things are confirmed" is a bit
premature.

I created a dendrogram from my data using Systat. I used the same
engines that you used ( except for Shredder 10 and 12 ). Complete
linkage and normalized Euclidean distance.



Looks alot like yours, maybe Fruit and Rybka 1.0 Beta/Strelka not quite
as close as your data, but no big difference I think.

Then I added 10 more engines.



Rybka 3 and Houdini/Ivanhoe are now closer than Fruit and Rybka 1.0
Beta/Strelka.

[Gian-Carlo Pascutto]

Can a top chess engine have good architecture at all? Doesn't it have to be over-optimized in a way that it nearly becomes a mess?

There isn't really any conflict between a good (high-level) architecture and a significant degree of (low-level) optimizations.
In C++ a lot of optimizations can be hidden in templates or classes, and become effectively hidden for the rest of the application.

It's a nice theory.

But it's only a theory.

I've yet to see practical evidence that it's possible to achieve that. Just look a the top open source engines.

[Gian-Carlo Pascutto]

(2) I did the mailbox-to-bitboard translation with Crafty. It only affects a part of the code. Search is unchanged. Move ordering is unchanged. Several other things are completely board representation independent.

Crafty is a giant machine with nearly 40K lines of code. At ten lines per hour and $100/hour that would translate to $400,000 worth of work. ...

"ten lines per hour" ?

You translate huge chunks of code almost as fast as you can type. Why should average speed drop to "ten lines per hour" ?

You can average faster than that, then hit a construct that doesn't directly translate.

Then it won't be so fast.

[Sven]

Just for the record, to eliminate this specific argument, when Zach, CT, I and others looked at the fruit/rybka1 question, we did _not_ involve Strelka. Strelka was the thing that exposed the issue, but we directly compared fruit to rybka, so the strelka issue could not be raised again...

What happened then?

Fabien.

We found _lots_ of similarities. Zach created a web page that went into great detail with the analysis. There are some obvious differences between Fruit and Rybka, but there are a _ton_ of similarities. Too many to be pure luck.

But these similarities are not a proof of code copying.

Sven

If you look at my previous comments, "similarity" is "identical code". The entire program was not copied. But large chunks were. That _is_ proof of code copying...

Since large chunks were copied, but not everything, I chose to not say "identical" to be accurate. But they are _very_ similar. Moreso when you factor out the bitboard changes...

So your statement reads like this: "The proof of code copying is that large chunks were copied."


Sven

[Gian-Carlo Pascutto]

So your statement reads like this: "The proof of code copying is that large chunks were copied."


Sven

No, his statement is that if too-large-to-be-coincidental parts of code match, it doesn't matter that there are parts that don't for there to be proof of copying.

[Matthias Gemuh]

"ten lines per hour" ?

You translate huge chunks of code almost as fast as you can type. Why should average speed drop to "ten lines per hour" ?

You can average faster than that, then hit a construct that doesn't directly translate.

Then it won't be so fast.

A cloner would generally shy away from an engine if it has some constructs that he deems hard to translate.

If it's one's own engine that must be translated, I agree that issues may pop up that are messy.

Matthias.

[Xann]

I think you are correct. The issue that causes dispute is about re-writes that need not involve any cut-and-paste. A re-write of Fruit from mailbox to bitboard could have copyright issue. I did try to search for some expert articles to clarify the issue, but there was none that directly addresses what is at dispute here.

Don't you think the FSF might be a little bit less clueless than we are on this matter?

Fabien.

[Gian-Carlo Pascutto]

Don't you think the FSF might be a little bit less clueless than we are on this matter?

If this is another way of saying "what about gathering all the data Zach, Bob, BB and others gathered, comparing them to Vasik's statements, forming an opinion about what likely happened and then asking the FSF if something can or should be done about it?".

Then I think this is a splendid idea.