Rybka Coding Posts

[chrisw]

Trolling again, Christophe.

At the start of this process, I reported back to CCC that Vas had said he was happy to answer a list of concerns if your side was to produce one.

Your side, including Zach, if I remember correct, said, in effect that I was baised, they didn't trust me to send the questions or censor them or whatever, and they would do the sending themselves.

I paraphrase that as a 'ban' on me to be any more involved in trying to get your side (a) to formally formulate its position and (b) to 'send' the position from the CCC to Vas when it was prepared.

You are certainly a talented mind reader engineer artist if you call this a "ban".

I call it 'ban' because it was actually quite rude of you, I thought. Obviously I was never going to do anything else than transmit accurately whatever concern list was prepared.

Go troll yourself. There's little point in discussion with you because (a) you should be preparing your attack evidence, not wasting your time here in content free threads and (b) you're reducing the interaction between me and you to bad-tempered, content free nonsense, which ultimately just demeans the process.

What is the point in preparing anything if you brush it away with techniques such as calling disassembling "creative reverse engineering by an artist" and such?

Reverse engineering and trying to have the reconstructed source fit the source of the original work is perfectly valid. It is what the courts do when they use "semantical abstraction".

You are trying to picture this as a completely non-scientific process when it is the contrary.

Either you believe it is not scientific, and then you are a really poor expert, or you know it is valid and you try to deceive people with your allegations.

In any case, it is what the courts do. Sorry if you do not like the process.

// Christophe

For non-technical readers the reverse engineering process goes this way, I'll start with the original program.

Vas writes source code, in C language (we assume). This source code contains huge amounts of text and named labels. The names will be of variables, functions and so on. The C code is readable, it is not too far from actual english, in the sense that a programmer can generally understand it and follow its algorithmic reasoning.

Vas then puts this source code through a compiler, the compiler produces executable code which is what you buy when you buy Rybka. The executable code doesn't contain all those variable and function names or other pieces of anymore, they are all thrown away. The executable is generally unreadable, in that it's too complex, contains no label information and is written in assembler language which is several steps too far removed from English.

Additionally, the executable is put through an optimiser which changes the order that instructions are executed in, and does some other fancy tricks, further removing the executable code from its parallel prior existence as C code.


Now along comes the reverse engineer. His task is to take this optimised executable code and reconstitute the original C code. He has no labels or function names (they've been thrown away). He has to hunt around in the relatively unreadable assembler code trying to work out what does this and what does that. He guesses at what variables do. He creatively assigns names to variables and functions. Gradually and time comsumingly, he manages to put together bits and pieces of C language with labels names and function names that are his guesses, inventions, intuitions. Sometimes he'll get it right and sometimes wrong. Art not science.

Christophe appears angry because he claims I am trying to trash the entire reverse engineering process. Just to assuage Christophe's anger I can state, no, I'm not trying to do that. I'm trying to provide some balance to the idea that the reverse engineered C code is 100% scientific and 100% accurate, because it is not. I'm also pointing out that the label and function names contained within it are *not* in the original Vas source, but are created by the reverse engineer in deliberate parallel with the target program that is accused of being copied.

I'm also trying to point out, as was Ed with his tunnel vision post, that the reverse engineer, if not totally impartial, runs the risk of finding things that are not there.

Ultimately, the purpose of this critique is to prevent the antis, or their program knowledgable ones, from being able to say: "we disassembled it and found it was the same" and for all the readers just to accept that.

A critique of the disassembly process as ducking stool, so to speak.

Their disassembly has to be open to criticism and open to repeat disassembly process and alternative possibility by less involved people.

No more and no less.

[rebel777]

Perfect Chris.

Ed

For non-technical readers the reverse engineering process goes this way, I'll start with the original program.

Vas writes source code, in C language (we assume). This source code contains huge amounts of text and named labels. The names will be of variables, functions and so on. The C code is readable, it is not too far from actual english, in the sense that a programmer can generally understand it and follow its algorithmic reasoning.

Vas then puts this source code through a compiler, the compiler produces executable code which is what you buy when you buy Rybka. The executable code doesn't contain all those variable and function names or other pieces of anymore, they are all thrown away. The executable is generally unreadable, in that it's too complex, contains no label information and is written in assembler language which is several steps too far removed from English.

Additionally, the executable is put through an optimiser which changes the order that instructions are executed in, and does some other fancy tricks, further removing the executable code from its parallel prior existence as C code.


Now along comes the reverse engineer. His task is to take this optimised executable code and reconstitute the original C code. He has no labels or function names (they've been thrown away). He has to hunt around in the relatively unreadable assembler code trying to work out what does this and what does that. He guesses at what variables do. He creatively assigns names to variables and functions. Gradually and time comsumingly, he manages to put together bits and pieces of C language with labels names and function names that are his guesses, inventions, intuitions. Sometimes he'll get it right and sometimes wrong. Art not science.

Christophe appears angry because he claims I am trying to trash the entire reverse engineering process. Just to assuage Christophe's anger I can state, no, I'm not trying to do that. I'm trying to provide some balance to the idea that the reverse engineered C code is 100% scientific and 100% accurate, because it is not. I'm also pointing out that the label and function names contained within it are *not* in the original Vas source, but are created by the reverse engineer in deliberate parallel with the target program that is accused of being copied.

I'm also trying to point out, as was Ed with his tunnel vision post, that the reverse engineer, if not totally impartial, runs the risk of finding things that are not there.

Ultimately, the purpose of this critique is to prevent the antis, or their program knowledgable ones, from being able to say: "we disassembled it and found it was the same" and for all the readers just to accept that.

A critique of the disassembly process as ducking stool, so to speak.

Their disassembly has to be open to criticism and open to repeat disassembly process and alternative possibility by less involved people.

No more and no less.

[tiger]

Trolling again, Christophe.

At the start of this process, I reported back to CCC that Vas had said he was happy to answer a list of concerns if your side was to produce one.

Your side, including Zach, if I remember correct, said, in effect that I was baised, they didn't trust me to send the questions or censor them or whatever, and they would do the sending themselves.

I paraphrase that as a 'ban' on me to be any more involved in trying to get your side (a) to formally formulate its position and (b) to 'send' the position from the CCC to Vas when it was prepared.

You are certainly a talented mind reader engineer artist if you call this a "ban".

I call it 'ban' because it was actually quite rude of you, I thought. Obviously I was never going to do anything else than transmit accurately whatever concern list was prepared.

Go troll yourself. There's little point in discussion with you because (a) you should be preparing your attack evidence, not wasting your time here in content free threads and (b) you're reducing the interaction between me and you to bad-tempered, content free nonsense, which ultimately just demeans the process.

What is the point in preparing anything if you brush it away with techniques such as calling disassembling "creative reverse engineering by an artist" and such?

Reverse engineering and trying to have the reconstructed source fit the source of the original work is perfectly valid. It is what the courts do when they use "semantical abstraction".

You are trying to picture this as a completely non-scientific process when it is the contrary.

Either you believe it is not scientific, and then you are a really poor expert, or you know it is valid and you try to deceive people with your allegations.

In any case, it is what the courts do. Sorry if you do not like the process.

// Christophe

For non-technical readers the reverse engineering process goes this way, I'll start with the original program.

Vas writes source code, in C language (we assume). This source code contains huge amounts of text and named labels. The names will be of variables, functions and so on. The C code is readable, it is not too far from actual english, in the sense that a programmer can generally understand it and follow its algorithmic reasoning.

Vas then puts this source code through a compiler, the compiler produces executable code which is what you buy when you buy Rybka. The executable code doesn't contain all those variable and function names or other pieces of anymore, they are all thrown away. The executable is generally unreadable, in that it's too complex, contains no label information and is written in assembler language which is several steps too far removed from English.

Additionally, the executable is put through an optimiser which changes the order that instructions are executed in, and does some other fancy tricks, further removing the executable code from its parallel prior existence as C code.


Now along comes the reverse engineer. His task is to take this optimised executable code and reconstitute the original C code. He has no labels or function names (they've been thrown away). He has to hunt around in the relatively unreadable assembler code trying to work out what does this and what does that. He guesses at what variables do. He creatively assigns names to variables and functions. Gradually and time comsumingly, he manages to put together bits and pieces of C language with labels names and function names that are his guesses, inventions, intuitions. Sometimes he'll get it right and sometimes wrong. Art not science.

Christophe appears angry because he claims I am trying to trash the entire reverse engineering process. Just to assuage Christophe's anger I can state, no, I'm not trying to do that. I'm trying to provide some balance to the idea that the reverse engineered C code is 100% scientific and 100% accurate, because it is not. I'm also pointing out that the label and function names contained within it are *not* in the original Vas source, but are created by the reverse engineer in deliberate parallel with the target program that is accused of being copied.

I'm also trying to point out, as was Ed with his tunnel vision post, that the reverse engineer, if not totally impartial, runs the risk of finding things that are not there.

Ultimately, the purpose of this critique is to prevent the antis, or their program knowledgable ones, from being able to say: "we disassembled it and found it was the same" and for all the readers just to accept that.

A critique of the disassembly process as ducking stool, so to speak.

Their disassembly has to be open to criticism and open to repeat disassembly process and alternative possibility by less involved people.

No more and no less.

OK, fair description I think.

I will add that the courts do not have to compare source codes. What they compare is a level of abstraction higher. They compare the "semantics" of the program. They compare what the programs are doing, not exactly how it is written.

The semantic can be expressed in plain english for example:
- set variable i to 0
- set variable j to 1
- add to variable i the value of variable j
- ...

The semantic can also be expressed in "pseudocode" (algorithmic language):
i <- 0
j <- 1
i <- i + j
...

Semantically, the above piece is equivalent to this one:
j <- 1
i <- 0
i <- j + i
you notice that two lines have been exchanged and a formula as been slightly changed as well. But these changes have not changed the semantics of the program. It would still produce the same result. Semantically, it is the same.

For the purpose of comparing a binary code to a C source code, it is correct to reconstruct a C code from the binary in order to make it look as close as possible to the other one. The condition is that the semantics of the reconstructed program must not differ from the semantics of the binary code.

In other words, it is correct to reconstruct the C source code in order to make it look as close as possible to the other C source code, at the condition that the recontructed one "does the same things" (in term of results) as the binary.

Let's take an analogy in detecting plagiarism in cinema. If you want to prove that one movie has copied the story of another movie, you are not going to care about the actors. Just about the characters. And you will not be fooled by the names of the characters, because changing them does not change the story. Not taking into account the actors and the characters' names is going up in the levels of abstraction. It's going to the semantical level. The semantical level is the story.

And if in the copied movie the order of some scenes has been changed, you know if it changes the story or not. Sometimes it does not and you can say that the story is "semantically" identical (it's just the same story).

If you are comparing two different movies with different stories, even ignoring the actors and the character names and even the order of some scenes, there is no way you will be able to say it's the same story.

It's the same when comparing programs. If, even when allowed to go to the semantical level and apply operations that do not change the semantic of the program, you cannot make the two appear identical, then you have different programs.

If you can make them appear nearly identical with some exceptions, then you can suspect something. Even in this case the semantical analysis will help because it will spot the real differences between the programs, which would be more difficult to detect otherwise.

One area of concern is that the reconstruction and the possibility to apply different operations like changing the positions of some lines or changing the variables names could make two different programs appear as if they were the same.

It does not happen, and this is why the courts use this process of "abstraction". It has been designed by experts in the field of IT and it works. The majority of disagreement between experts when working in such cases happen in other areas, such as what is an idea and what is not, and what is protectable.



// Christophe

[Steve B]

Unfortunately I'm not sure it is a good idea to rely of Mr Whittington's view to get an accurate picture of what is happening.

I would say that evidence has been provided, but it has been brushed away in such an absurd way that the source code of a program would never be recognized as such even if you are given the corresponding executable. So if you cannot tell that this executable comes from this source, don't even dream about finding about the similarity between this other source and this executable.

For example the process of finding the variables names in the binary code (which has no variable names because they have been replaced by numeric addresses) and trying to make them fit with the original source code we are comparing to is described by Mr Whittington as the work of a "creative artist", which is a way to discredit competely the process. He says that disassembling is making things up.

So we stand at a point where no evidence would ever convince Mr Whittington and we say that someone is trying to obstruct the debate.

// Christophe

Thanks Christophe
but if i am reading your post correctly
it is not Vas that is brushing aside the evidence already presented(the initial first question) but rather CW and others
in your view..of the current situation...is the following accurate?...

a)one question has been asked of Vas
b)Vas has chosen to not reply but will wait until a final list of questions is presented
c)we are waiting for this list now for several days

is that a fair synopsis ..in your opinion so far?

Steve

[Terry McCracken]

Trolling again, Christophe.

At the start of this process, I reported back to CCC that Vas had said he was happy to answer a list of concerns if your side was to produce one.

Your side, including Zach, if I remember correct, said, in effect that I was baised, they didn't trust me to send the questions or censor them or whatever, and they would do the sending themselves.

I paraphrase that as a 'ban' on me to be any more involved in trying to get your side (a) to formally formulate its position and (b) to 'send' the position from the CCC to Vas when it was prepared.

I call it 'ban' because it was actually quite rude of you, I thought. Obviously I was never going to do anything else than transmit accurately whatever concern list was prepared.

Go troll yourself. There's little point in discussion with you because (a) you should be preparing your attack evidence, not wasting your time here in content free threads and (b) you're reducing the interaction between me and you to bad-tempered, content free nonsense, which ultimately just demeans the process.

Correct. There's no point in further discussion until the anti-camp have come up with a formal statement.

by "formal statement"..you mean a formal list of questions?
in short..Vas is not going to reply to one question
so are the chief questioners preparing this statement or refusing to ..until Vas answers the first question?

just trying to zero in on where things are now..thats all
Steve

Well, Zach become very frustrated a few days ago with all the "where's your evidence questions" and retracted the ban of me from sending their questions to Vas. When I said ok, what do I send, he pointed at the first post in one of the threads and said send that. So I did.

Zach has never banned you from doing anything.

I notice more and more subtle mistakes in your posts and wonder if they are intentional or if they come from lack of sleep (or anything else).

Now if it is possible to ban you a little bit, just a little bit and as friendly as possible, can I take this opportunity to ban you from obstructing any reasonable examination of the evidence that has already been provided?



// Christophe

I think they (antis) then realised that that post was quite unsuitable as a statement list or a list of concerns or anything else. So they then stated (and before in fact) they were preparing further and better material. Hardly surprisingly, when Vas got to hear that a more formal and better presented version of their case was on the way, he decided to wait for that instead. It's clearly in his interest to get their entire case and refute it rather than deal with piecemeal attacks one after the other. The anti-side, of course, should have prepared this case in its entirity beforehand, but they didn't, preferring instead to rely on slurs and assumptions without evidential base.

The ball is very much in their court, and responsibility for this very sloppy and damaging process rests entirely with them and their failure to have prepared material beforehand. Now they do it in desperation to try to defend their accusations and themselves. Hardly a process designed for impartiality or truth seeking.

Go troll yourself.

Obscene personal attack. I think it's time you left this debate altogether.

You have lost. And you know it!

[tiger]

Unfortunately I'm not sure it is a good idea to rely of Mr Whittington's view to get an accurate picture of what is happening.

I would say that evidence has been provided, but it has been brushed away in such an absurd way that the source code of a program would never be recognized as such even if you are given the corresponding executable. So if you cannot tell that this executable comes from this source, don't even dream about finding about the similarity between this other source and this executable.

For example the process of finding the variables names in the binary code (which has no variable names because they have been replaced by numeric addresses) and trying to make them fit with the original source code we are comparing to is described by Mr Whittington as the work of a "creative artist", which is a way to discredit competely the process. He says that disassembling is making things up.

So we stand at a point where no evidence would ever convince Mr Whittington and we say that someone is trying to obstruct the debate.

// Christophe

Thanks Christophe
but if i am reading your post correctly
it is not Vas that is brushing aside the evidence already presented(the initial first question) but rather CW and others
in your view..of the current situation...is the following accurate?...

a)one question has been asked of Vas
b)Vas has chosen to not reply but will wait until a final list of questions is presented
c)we are waiting for this list now for several days

is that a fair synopsis ..in your opinion so far?

Steve

Vas has already answered that Rybka is 100% clean (I hope I'm not distorting).

We do not know which Rybka he is talking about.

We do not know what "clean" means.

There is plenty of room in his answer to step back at any time with "I was not talking about this Rybka" and "clean means that it will not be declared as a derivative work by a court".

I do not know if it is intentional or not.

I think it would be better if some fair basis for similarity analysis to be laid out before any further evidence is provided. So far the evidence has been treated with some absurd reasoning and little objectivity.

It would be good if Vas could also state for example that "There is no code taken from Fruit 2.1 in Rybka 1.0". That would clear all ambiguity in his previous statement.



// Christophe

[chrisw]

Trolling again, Christophe.

At the start of this process, I reported back to CCC that Vas had said he was happy to answer a list of concerns if your side was to produce one.

Your side, including Zach, if I remember correct, said, in effect that I was baised, they didn't trust me to send the questions or censor them or whatever, and they would do the sending themselves.

I paraphrase that as a 'ban' on me to be any more involved in trying to get your side (a) to formally formulate its position and (b) to 'send' the position from the CCC to Vas when it was prepared.

You are certainly a talented mind reader engineer artist if you call this a "ban".

I call it 'ban' because it was actually quite rude of you, I thought. Obviously I was never going to do anything else than transmit accurately whatever concern list was prepared.

Go troll yourself. There's little point in discussion with you because (a) you should be preparing your attack evidence, not wasting your time here in content free threads and (b) you're reducing the interaction between me and you to bad-tempered, content free nonsense, which ultimately just demeans the process.

What is the point in preparing anything if you brush it away with techniques such as calling disassembling "creative reverse engineering by an artist" and such?

Reverse engineering and trying to have the reconstructed source fit the source of the original work is perfectly valid. It is what the courts do when they use "semantical abstraction".

You are trying to picture this as a completely non-scientific process when it is the contrary.

Either you believe it is not scientific, and then you are a really poor expert, or you know it is valid and you try to deceive people with your allegations.

In any case, it is what the courts do. Sorry if you do not like the process.

// Christophe

For non-technical readers the reverse engineering process goes this way, I'll start with the original program.

Vas writes source code, in C language (we assume). This source code contains huge amounts of text and named labels. The names will be of variables, functions and so on. The C code is readable, it is not too far from actual english, in the sense that a programmer can generally understand it and follow its algorithmic reasoning.

Vas then puts this source code through a compiler, the compiler produces executable code which is what you buy when you buy Rybka. The executable code doesn't contain all those variable and function names or other pieces of anymore, they are all thrown away. The executable is generally unreadable, in that it's too complex, contains no label information and is written in assembler language which is several steps too far removed from English.

Additionally, the executable is put through an optimiser which changes the order that instructions are executed in, and does some other fancy tricks, further removing the executable code from its parallel prior existence as C code.


Now along comes the reverse engineer. His task is to take this optimised executable code and reconstitute the original C code. He has no labels or function names (they've been thrown away). He has to hunt around in the relatively unreadable assembler code trying to work out what does this and what does that. He guesses at what variables do. He creatively assigns names to variables and functions. Gradually and time comsumingly, he manages to put together bits and pieces of C language with labels names and function names that are his guesses, inventions, intuitions. Sometimes he'll get it right and sometimes wrong. Art not science.

Christophe appears angry because he claims I am trying to trash the entire reverse engineering process. Just to assuage Christophe's anger I can state, no, I'm not trying to do that. I'm trying to provide some balance to the idea that the reverse engineered C code is 100% scientific and 100% accurate, because it is not. I'm also pointing out that the label and function names contained within it are *not* in the original Vas source, but are created by the reverse engineer in deliberate parallel with the target program that is accused of being copied.

I'm also trying to point out, as was Ed with his tunnel vision post, that the reverse engineer, if not totally impartial, runs the risk of finding things that are not there.

Ultimately, the purpose of this critique is to prevent the antis, or their program knowledgable ones, from being able to say: "we disassembled it and found it was the same" and for all the readers just to accept that.

A critique of the disassembly process as ducking stool, so to speak.

Their disassembly has to be open to criticism and open to repeat disassembly process and alternative possibility by less involved people.

No more and no less.

OK, fair description I think.

I will add that the courts do not have to compare source codes. What they compare is a level of abstraction higher. They compare the "semantics" of the program. They compare what the programs are doing, not exactly how it is written.

The semantic can be expressed in plain english for example:
- set variable i to 0
- set variable j to 1
- add to variable i the value of variable j
- ...

The semantic can also be expressed in "pseudocode" (algorithmic language):
i <- 0
j <- 1
i <- i + j
...

Semantically, the above piece is equivalent to this one:
j <- 1
i <- 0
i <- j + i
you notice that two lines have been exchanged and a formula as been slightly changed as well. But these changes have not changed the semantics of the program. It would still produce the same result. Semantically, it is the same.

For the purpose of comparing a binary code to a C source code, it is correct to reconstruct a C code from the binary in order to make it look as close as possible to the other one. The condition is that the semantics of the reconstructed program must not differ from the semantics of the binary code.

In other words, it is correct to reconstruct the C source code in order to make it look as close as possible to the other C source code, at the condition that the recontructed one "does the same things" (in term of results) as the binary.

Let's take an analogy in detecting plagiarism in cinema. If you want to prove that one movie has copied the story of another movie, you are not going to care about the actors. Just about the characters. And you will not be fooled by the names of the characters, because changing them does not change the story. Not taking into account the actors and the characters' names is going up in the levels of abstraction. It's going to the semantical level. The semantical level is the story.

And if in the copied movie the order of some scenes has been changed, you know if it changes the story or not. Sometimes it does not and you can say that the story is "semantically" identical (it's just the same story).

If you are comparing two different movies with different stories, even ignoring the actors and the character names and even the order of some scenes, there is no way you will be able to say it's the same story.

It's the same when comparing programs. If, even when allowed to go to the semantical level and apply operations that do not change the semantic of the program, you cannot make the two appear identical, then you have different programs.

If you can make them appear nearly identical with some exceptions, then you can suspect something. Even in this case the semantical analysis will help because it will spot the real differences between the programs, which would be more difficult to detect otherwise.

One area of concern is that the reconstruction and the possibility to apply different operations like changing the positions of some lines or changing the variables names could make two different programs appear as if they were the same.

It does not happen, and this is why the courts use this process of "abstraction". It has been designed by experts in the field of IT and it works. The majority of disagreement between experts when working in such cases happen in other areas, such as what is an idea and what is not, and what is protectable.
// Christophe

And this is why the choice of code within the UCI, the so-called Go Parser code was an astonishingly bad choice by your side.

You claim semantics is the important aspect. ok, let's go with that for these purposes.

I'm not a UCI programmer, but I think I picked up broadly what is going on in this process ....

This Go Parser (the Rick Fadden code) is the code that takes a stream of text from the User Interface and parses or interprets that text, stuffing the result into various variables.

For example, the user interface might want the engine to be in "ponder" mode or in "infinite" mode (this being the stuff Zach(?) posted about yesterday).

So, the UserInterface sends a text stream containing the character strings "infinite" and "ponder", just like that, spelt out in english text.

The UCI code has a little hunt into the text stream to see if it can find "infinite" and "ponder". If it does, it has to set a flag (a variable) to tell the engine (this because the engine doesn't deal in text it deals in variables).

So, semantically, the UCI go parser code has to do the same thing in all variants of the UCI, whoever wrote them, doesn't it?

if (strcmp(ptr, "infinite) == FALSE) infinite = TRUE; or something semantically identical.

So, how to prove anything from a piece of code that semantically has to do what it has to do?

Bad choice of code block. Better would be some AI code from the engine, but your side doesn't produce any of that.

[chrisw]

Unfortunately I'm not sure it is a good idea to rely of Mr Whittington's view to get an accurate picture of what is happening.

I would say that evidence has been provided, but it has been brushed away in such an absurd way that the source code of a program would never be recognized as such even if you are given the corresponding executable. So if you cannot tell that this executable comes from this source, don't even dream about finding about the similarity between this other source and this executable.

For example the process of finding the variables names in the binary code (which has no variable names because they have been replaced by numeric addresses) and trying to make them fit with the original source code we are comparing to is described by Mr Whittington as the work of a "creative artist", which is a way to discredit competely the process. He says that disassembling is making things up.

So we stand at a point where no evidence would ever convince Mr Whittington and we say that someone is trying to obstruct the debate.

// Christophe

Thanks Christophe
but if i am reading your post correctly
it is not Vas that is brushing aside the evidence already presented(the initial first question) but rather CW and others
in your view..of the current situation...is the following accurate?...

a)one question has been asked of Vas
b)Vas has chosen to not reply but will wait until a final list of questions is presented
c)we are waiting for this list now for several days

is that a fair synopsis ..in your opinion so far?

Steve

Vas has already answered that Rybka is 100% clean (I hope I'm not distorting).

We do not know which Rybka he is talking about.

We do not know what "clean" means.

There is plenty of room in his answer to step back at any time with "I was not talking about this Rybka" and "clean means that it will not be declared as a derivative work by a court".

I do not know if it is intentional or not.

I think it would be better if some fair basis for similarity analysis to be laid out before any further evidence is provided. So far the evidence has been treated with some absurd reasoning and little objectivity.

It would be good if Vas could also state for example that "There is no code taken from Fruit 2.1 in Rybka 1.0". That would clear all ambiguity in his previous statement.

// Christophe

I think you are distorting, especially if the origin of your quote came from what I posted some days ago.

Vas did not say "Rybkla is 100% clean", a statement that implies it might have been 5% dirty at one stage and has been through a washing machine. I hope that is not your intention.

What he said to me, and I reproduced it here was:

"Rybka is and always was completely original". A statement that implies it was written from scratch right from the start and continues to be so.

[tiger]

Zach has posted his own UCI parser, which is semantically completely different.

You say that two UCI parsers should necessarily be very close semantically, and the first example that has been posted shows that it is not the case.

You can go up in the level of abstraction and at one point two UCI parsers will be identical (at the highest abstraction level because they are both "UCI parsers"). What is suspect is when both program start to look identical as soon as you go up in the abstraction hierarchy a little bit. The sooner is the source code level (both source codes are identical). One level higher would be the algorithmic level (they are written in different languages but follow exactly the same algorithm), and so on.

Zach's and Fruit's do not look the same semantically until you reach the highest levels.

I would like to see other UCI parsers posted so we could compare a little bit and see how often it happens.



// Christophe

[tiger]

Unfortunately I'm not sure it is a good idea to rely of Mr Whittington's view to get an accurate picture of what is happening.

I would say that evidence has been provided, but it has been brushed away in such an absurd way that the source code of a program would never be recognized as such even if you are given the corresponding executable. So if you cannot tell that this executable comes from this source, don't even dream about finding about the similarity between this other source and this executable.

For example the process of finding the variables names in the binary code (which has no variable names because they have been replaced by numeric addresses) and trying to make them fit with the original source code we are comparing to is described by Mr Whittington as the work of a "creative artist", which is a way to discredit competely the process. He says that disassembling is making things up.

So we stand at a point where no evidence would ever convince Mr Whittington and we say that someone is trying to obstruct the debate.

// Christophe

Thanks Christophe
but if i am reading your post correctly
it is not Vas that is brushing aside the evidence already presented(the initial first question) but rather CW and others
in your view..of the current situation...is the following accurate?...

a)one question has been asked of Vas
b)Vas has chosen to not reply but will wait until a final list of questions is presented
c)we are waiting for this list now for several days

is that a fair synopsis ..in your opinion so far?

Steve

Vas has already answered that Rybka is 100% clean (I hope I'm not distorting).

We do not know which Rybka he is talking about.

We do not know what "clean" means.

There is plenty of room in his answer to step back at any time with "I was not talking about this Rybka" and "clean means that it will not be declared as a derivative work by a court".

I do not know if it is intentional or not.

I think it would be better if some fair basis for similarity analysis to be laid out before any further evidence is provided. So far the evidence has been treated with some absurd reasoning and little objectivity.

It would be good if Vas could also state for example that "There is no code taken from Fruit 2.1 in Rybka 1.0". That would clear all ambiguity in his previous statement.

// Christophe

I think you are distorting, especially if the origin of your quote came from what I posted some days ago.

Vas did not say "Rybkla is 100% clean", a statement that implies it might have been 5% dirty at one stage and has been through a washing machine. I hope that is not your intention.

What he said to me, and I reproduced it here was:

"Rybka is and always was completely original". A statement that implies it was written from scratch right from the start and continues to be so.

OK, sorry, I remembered your sentence and not his.

I read his statement the same way as you do. So if any parts of Fruit 2.1 can be found in Rybka 1.0, it can only be pure coincidence. That's what Vas says. Correct?



// Christophe