Bob Hyatt says that....

[kranium]

show us specific lines of code that are equal to those from fruit.

http://pagesperso-orange.fr/ct_chess/Fr ... rt_go.html

This is some kind of joke?!

The 'code' contains 200 lines, many of which are blank, ignoring those, there are:

33 lines same
81 lines different

that's a 28% correspondence. Very funny joke.

You have no source of Rybka, so the variable names are guesswork, btw.

Given that the code chucks are doing the same thing, I find 81 different lines to 33 same completely reasonable for programs written by two different people.

yes, i haven't counted, but ok 33 are exact ...
isn't that concerning? how can that happen.

not that it means a lot, but of course, as a programmer Chris you're aware that there are many more than are very close (or as Uri put it: equivalent)

Searching = true;
is the same as
Searching = 1;
and
Delay = false;
is the same as
Dealy = 0;

etc.

It just seems like a awful lot to me,.. and we're only talking about 1 (relatively small) function.

as far as the missing symbol info, yes reproducing or reconstructing it is not an exact science. but there are many things to help, you can purchase disassembly libraries that go a great distance to aid accuracy.
And if the disassembler himself is knowledgeable and experienced, this also aids a great deal. I don't know Rick Fadden, I have simply read his many posts, and it was clear to me the was experiences, honest, unbiased, etc. he even mentioned that 'several of us' fpound the results...i.e. a group effort.

so agreed, no problem, we do need to press it....perhaps there will be more info and when the rest of the executable become disassembled.

i realize that many, if not most people, believe we have lost the argument in the court of public opinion, because we haven't provided enough code.

i can accept that...it's getting tiring foe all i'm sure.
let's stop discussing it, as Zach has requested, and simply agree to disagree.

typo :
i meant "we don't need to press it"

[Mike S.]

Obviously what went wrong was the pre-decision. To ask for source they need strong evidence already. Otherwise anybody can, in Stasi manner, wreck any competitors tournament for them.

That's what happened, and that explains my sometimes (too?) harsh wording against the ICGA. Of course, I cannot be 100% sure that List didn't contain any Crafty code, but from what was possible to read in public, I am almost sure that there was no strong evidence.

The extra funny thing about that matter is, that actually there WAS a clone participating in that tournament, as was found out later: (El) Chinito, a Crafty clone. The glorious ICGA disqualified List but not Chinito.

http://computer-chess.org/doku.php?id=c ... ngine_list

(you will notice that List or Loop is NOT in that list)

[kranium]

the whole thing will happen on the players meeting in Beijing shortly before the big tournament.

Yes, I guess that's the time and location when some people want to crucify Vas and then celebrate their satanic mass. Vas should withdraw from the world championship! Chessmaster (the best selling chess software) and since many years, Fritz (the second best selling chess software) did not require to participate. Rybka doesn't either. After the so called world champion 2008 has been crowned, Rybka will defeat it 60:40 at least, anytime anywhere.

Rolf, you remember Graz 2003. Meanwhile, F.Reul has sold his program to Nintendo, for the Wii console, the currently best selling video console. I guess from all chess programmers, he is currently the one who creates the biggest revenue. That is his silent revenge for the injustice of Graz.

yes, good point...
but they are not going to 'crucify' him...that would be completely unfair, and unwarranted. i don't even think they should him question about it, but i can't control that. everything that has been discussed here was just that - it was debate, public forum 'discussion'. the fact that it became so heated reflects the passion and love that people have for chess.

i for one, can accept the fact that the community believes that a violation has not been conclusively proven. (unless the FSF magically appears and corrects me!). but i also believe there is significant cause for concern, there is simply too much code to ignore, but even then, we're talking about rybka 1.0, 3 years ago, so maybe it's less relevant?
i don't know,

there was some conjecture about subsequent versions, and the connection kinda logically follows. but that's speculation, and i think that everybody saw it as that. in any event, it would good to know the truth.

he has a right to be there,
it's unfortunate that the outcome of the tournament is so certain. it would take a miracle...? (is it even remotely possible that rybka doesn't win?)

Norm, three questions to you, please tolerate such ones for the sake of truth:

- there was a clone affair connected with your person, why are you, a good chess programmer so actively participating actually as if you could be a trustable attorney fighting for the truth - I just dont get it and I have nothing against you personally but please try to give your view on that peoblem.

- Norm, I dont know your education, but anyway you are very smart IMO, so my next question, of course not to programming but what a "debate" is also besides a mere factual exchange. McLuhan said the message is the message. Do you understand what this means?? I ask because I have the strong opinion that the debaters here dont resalise what such a public inquiry can cause even if each one for himself claims honestly that he does only factually discuss a problem. Do you get what I mean?

- If you agree with me that such a debate can lead to consequences that are indipendent of the single participants?

- Why do you personally and in connect with you collaboraters avoid to research Fritz, Junior and such programs but only Rybka? Can that be justified somehow?

I hope that all will tolerate my questions as psychologically justified from a critical standpoint. Of course it's not technically on CC but it's still relevant for your presentation as notable programmer(s).

Rolf,
i can't believe i saying this, but i'm glad to see you back.
i'm especially happy and certainly appreciate and respect the fact that you appear to be excerising a level of discretion and restraint, which previously was often lacking (:D)

yes i'm familiar with the saying, marshal mcluen (i am a child of the 60's)...it's "the medium is the message" isn't it?
or is it the "message is the medium", i can't remember and i'm going to google it. a cynical perspective on the role of media and communications on peoples perceptions?

the initial info about rybka had been presented in May, we didn't conspire and select rybka.
here please read this, i tried to explain how it started:
http://64.68.157.89/forum/viewtopic.php?t=23275

then i'll finish my answer

[Alexander Schmidt]

This is some kind of joke?!

Do I need to explain every single message?

He asked for "some specific lines."

[Alexander Schmidt]

Chris, I guess I know what you are doing right now. You talked to Vas, asking about all this stuff here. He is a really nice guy and you believed him that he didn't do anything wrong.

I believed him too when I asked right after the Rybka 1.0 release.

I hope you will not get disapointed to much one day. I mean that honestly.

[bob]

...the argument that points how many programs or even all use the same algorythms is irrelevant as much they can be writen in so many different ways. So, he add, the reasonning that programs share lot of stuff, as Fabian said, would be not valid.
Ok. Then, if it is so and surely must be because, after all, Bob Hyatt and none other said that, if really the line of code and how was writen is the core of the issue, then let the attackers of Rybka originality show us specific lines of code that are equal to those from fruit.
Of course I wonder how they will do such a thing as much I presume the Rybka lines of code are not easily accesible.

Wondering regards
fern

What is being done is to take the executable, and run in thru a disassembler which produces the assembly language code the compiler produced when the source was compiled. An experienced programmer can then take that assembly language code and reconstruct the C source code it came from.

inc i => i++; in C for example.

It takes time because the optimizer in the compiler re-orders instructions to make them run as efficiently as possible, so the human reverse-engineer has to undo all of that...

Perhaps you should also point out that when the executable code is compiled from the source in the first place, enormous amounts of information are thrown away, so to re-generate the source from an executable requires creativity and massive amounts of creative guesswork from the reverse engineer. Better to call him reverse creative artist actually.

Your final alleged C source, rehashed from the executable is, shall we say, open to question.

Who tells you the label names, for example? Oh whoops, Reverse creative artist calls them himself, whatever he wants to call them, and so on.

Perhaps for you. Not for me. I can't reconstruct variable names. But I can figure out what code is doing and then deduce reasonable names, given enough interest to do so.

This used to be quite common in O/S development where source was not available (or available for a huge cost) so we looked at core dumps, and reconstructed code from that.

Of course, I suspect you are hung up on the syntactical issue again, where I am talking semantics.

So code might be interpreted as either

i++;
x = x[j] + n;

or

x[i++] = x[j] + n;

Personally, I don't have any problem at all seeing that those are semantically the same, and this code:

mov eax, j
mov ebx, i
inc ebx
move ecx, [x + 4*ebx]
add ecx, n
mov [x + 4*eax], ecx
mov i, ebx

might have been produced by either of those. I also do not have any problem in answering the question "is this block of assembly language semantically identical to that block of C code?" The chances of two semantically identical blocks of code is _extremely low_. Functionally equivalent I would buy. But not semantically equivalent. And in some cases, even worse, we see syntactically equivalent which is even grosser.

[bob]

...the argument that points how many programs or even all use the same algorythms is irrelevant as much they can be writen in so many different ways. So, he add, the reasonning that programs share lot of stuff, as Fabian said, would be not valid.
Ok. Then, if it is so and surely must be because, after all, Bob Hyatt and none other said that, if really the line of code and how was writen is the core of the issue, then let the attackers of Rybka originality show us specific lines of code that are equal to those from fruit.
Of course I wonder how they will do such a thing as much I presume the Rybka lines of code are not easily accesible.

Wondering regards
fern

What is being done is to take the executable, and run in thru a disassembler which produces the assembly language code the compiler produced when the source was compiled. An experienced programmer can then take that assembly language code and reconstruct the C source code it came from.

inc i => i++; in C for example.

It takes time because the optimizer in the compiler re-orders instructions to make them run as efficiently as possible, so the human reverse-engineer has to undo all of that...

Perhaps you should also point out that when the executable code is compiled from the source in the first place, enormous amounts of information are thrown away, so to re-generate the source from an executable requires creativity and massive amounts of creative guesswork from the reverse engineer. Better to call him reverse creative artist actually.

Your final alleged C source, rehashed from the executable is, shall we say, open to question.

Who tells you the label names, for example? Oh whoops, Reverse creative artist calls them himself, whatever he wants to call them, and so on.

So what's your point? That reverse-engineering cannot be used to prove any breach of copyright because too much depends on the "artist"?



// Christophe

My point is to inform non-programmers that this reverse engineering which is presented as some fine scientific process is in fact a highly creative procedure in which the reverse creative artist is guessing, writing in names and labels which he invents personally, and no way recreates the original code becaause the original code has already had great chunks of its own information totally thrown away and which cannot be reconstituted.

In short, its a bit of a sloppy mess and its output needs to be treated with handful of salt.

Here's a point to ponder and then answer. If you give me a block of assembly language taken from somewhere, what is the probability that someone else can give me something that was written by someone else, and when I convert the namespace of one of the blocks to match the namespace of the other block, they become identical? Is that pure luck that we somehow wrote the same identical instructions, but just used different names? One _can_ make logical deductions when doing this. The field of "computer forensics" has gotten pretty good at this sort of thing.

[chrisw]

...the argument that points how many programs or even all use the same algorythms is irrelevant as much they can be writen in so many different ways. So, he add, the reasonning that programs share lot of stuff, as Fabian said, would be not valid.
Ok. Then, if it is so and surely must be because, after all, Bob Hyatt and none other said that, if really the line of code and how was writen is the core of the issue, then let the attackers of Rybka originality show us specific lines of code that are equal to those from fruit.
Of course I wonder how they will do such a thing as much I presume the Rybka lines of code are not easily accesible.

Wondering regards
fern

What is being done is to take the executable, and run in thru a disassembler which produces the assembly language code the compiler produced when the source was compiled. An experienced programmer can then take that assembly language code and reconstruct the C source code it came from.

inc i => i++; in C for example.

It takes time because the optimizer in the compiler re-orders instructions to make them run as efficiently as possible, so the human reverse-engineer has to undo all of that...

Perhaps you should also point out that when the executable code is compiled from the source in the first place, enormous amounts of information are thrown away, so to re-generate the source from an executable requires creativity and massive amounts of creative guesswork from the reverse engineer. Better to call him reverse creative artist actually.

Your final alleged C source, rehashed from the executable is, shall we say, open to question.

Who tells you the label names, for example? Oh whoops, Reverse creative artist calls them himself, whatever he wants to call them, and so on.

Perhaps for you. Not for me. I can't reconstruct variable names. But I can figure out what code is doing and then deduce reasonable names, given enough interest to do so.

Yeah, yeah, yeah, Bob.

Only there won't be deduced "reasonable names", there will be deduced deliberately, names that cirrespond to names in the target program, to make it seem there are more correspondences than there really might be.

That's the creativity.

Do you deny the use of identical names as target program wherever possible will be used? No, of course you don't. Because already that is what has happened in the disassemblys we've been presented with.

Creative creation of variable and function names, deliberately to match the target.

Let's be quite honest to all the lays trying to follow this, shall we?

[bob]

show us specific lines of code that are equal to those from fruit.

http://pagesperso-orange.fr/ct_chess/Fr ... rt_go.html

This is some kind of joke?!

The 'code' contains 200 lines, many of which are blank, ignoring those, there are:

33 lines same
81 lines different

that's a 28% correspondence. Very funny joke.

You have no source of Rybka, so the variable names are guesswork, btw.

Given that the code chucks are doing the same thing, I find 81 different lines to 33 same completely reasonable for programs written by two different people.

Please look again. "33 lines the same". One of us can't count. I stopped at 50. If two lines of C are on the same line they are equivalent.

At least don't try to distort what is being presented. That code is absoilutely _not_ independently written.

[bob]

...the argument that points how many programs or even all use the same algorythms is irrelevant as much they can be writen in so many different ways. So, he add, the reasonning that programs share lot of stuff, as Fabian said, would be not valid.
Ok. Then, if it is so and surely must be because, after all, Bob Hyatt and none other said that, if really the line of code and how was writen is the core of the issue, then let the attackers of Rybka originality show us specific lines of code that are equal to those from fruit.
Of course I wonder how they will do such a thing as much I presume the Rybka lines of code are not easily accesible.

Wondering regards
fern

What is being done is to take the executable, and run in thru a disassembler which produces the assembly language code the compiler produced when the source was compiled. An experienced programmer can then take that assembly language code and reconstruct the C source code it came from.

inc i => i++; in C for example.

It takes time because the optimizer in the compiler re-orders instructions to make them run as efficiently as possible, so the human reverse-engineer has to undo all of that...

Perhaps you should also point out that when the executable code is compiled from the source in the first place, enormous amounts of information are thrown away, so to re-generate the source from an executable requires creativity and massive amounts of creative guesswork from the reverse engineer. Better to call him reverse creative artist actually.

Your final alleged C source, rehashed from the executable is, shall we say, open to question.

Who tells you the label names, for example? Oh whoops, Reverse creative artist calls them himself, whatever he wants to call them, and so on.

Perhaps for you. Not for me. I can't reconstruct variable names. But I can figure out what code is doing and then deduce reasonable names, given enough interest to do so.

Yeah, yeah, yeah, Bob.

Only there won't be deduced "reasonable names", there will be deduced deliberately, names that cirrespond to names in the target program, to make it seem there are more correspondences than there really might be.

That's the creativity.

Do you deny the use of identical names as target program wherever possible will be used? No, of course you don't. Because already that is what has happened in the disassemblys we've been presented with.

Creative creation of variable and function names, deliberately to match the target.

Let's be quite honest to all the lays trying to follow this, shall we?

I will say it again. If the instructions match exactly, and I then copy the names from one program and use them in the other on the same instructions, and everything matches and works properly, and suddenly the two programs appear to be identical, is that "creating" evidence or "discovering" evidence.

Again, I would be willing to challenge any two people to write a 500 line piece of assembly language code that implement the same algorithm. Then let's see if we can swap labels/names between the two and not break one. What are the chances? zero.

So if I match up the instructions side by side, and where I have a hex address I consistently replace that by the name from the second program, and it then looks the same in terms of instructions and varaiable and procedure names, that is not convincing? Only to someone that has never written a serious program of any kind, or to someone that doesn't want to be convinced in the first place and uses the "ostrich" approach.

If someone was "creating instructions" to add, that would be different. What you are claiming is what every entry-level student tries when he decides he doesn't have the time or skill to write his own program, so he plagiarizes someone else's program, but he knows enough to change the variable and procedure names. And according to you those can not be called equal. According to 99.999% of the academic/professional world, they would be called duplicates, and the only real issue becames who wrote what and who copied.

This trying to discount everything being said looks foolish. "GPL is unenforcable." (courts seem to disagree as do businesses that settle before going to court.) "wording in GPL is ambiguous". Apparently not to the courts. Change the names when trying to match up two programs is unacceptable, when that is the _first_ thing we look for when we notice similar program structure.

You can't discount everything. It slowly adds up.