syzygy wrote:Mine weren't even arguments, let alone straw man arguments. I was only trying to make sense of your arguments.User923005 wrote:I hold no such position in either case. These are what is know as "straw man" arguments.
You seem to find your string operations example very important:So what exactly does this prove then?User923005 wrote:As a suggested exercise, examine the C and Assembly language versions of the string operations I put here in a previous post in this thread.
You will see that the compiler has removed all the syntactic sugar from the code and left only the bare algorithm behind as assembly languge. Examine the C code carefully. I happen to know that these versions were produced independently by various authors at the same time. You can see by looking at the C code, that the code is not identical. While it is similar, this is certainly due to the task at hand (there are only so many ways that you can accomplish that simple string task). However, upon running the compiler against the C code, the syntactic sugar is squeezed out, leaving the bare assembly language algorithm behind. I think you will see upon examination of the assembly language that the assembly language produced is for all intents and purposes identical.
It is important to understand that the algorithm is not protected by a copyright -- only the implementation. This is, of course, exactly as it should be.
I think what you are trying to say is that for this example of yours, there is no "copyrightable" distinction between the object code obtained from compiling the first version and the object code obtained from compiling the second version. I think you are even implying that essentially any source code implementing these string operations will compile to essentially the same object code. Your conclusion seems to be that based on the object code, you can't say anything regarding the originality of the source code. This is because all originality was weeded out by the compiler. The object code corresponds to the algorithm and is unprotectable by copyright.
So far this is all fine and dandy. I do not disagree. I don't think anyone disagrees.
However, what is the point of your examples? I must assume that you are not mentioning them for nothing. Indeed, you seem to be putting great weight on them.
I can make sense of why your are giving these examples if I assume that you consider these examples to be representative of all algorithm / source code / object code relationships, or at least for those related to chess programming. If these examples are indeed representative, that would mean that object code in general is free from the copyright on the source code from which the object code was compiled. However, in general, that is complete nonsense.
The other possibility is that you were NOT trying to imply that the string operation examples were representative. In that case, I can only conclude that you were bringing them forward as a straw man argument.
On Dalke
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: On Dalke
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: On Dalke
The string examples show very plainly that different source {IOW, source that is coded by different people but using the same algorithm} which is obviously not a source level copy can produce identical assembly language because the algorithm is the same. In the case of Rybka, even that cannot possibly be a perfect match because the underlying representation is different. The "semantic equivalence" that has been demonstrated is nothing more than showing similar algorithms for small snippets of code, which is exactly the same thing that we would see if we examined, for instance, two LMR implementations or two alpha-beta implementations which came from studying the same original versions.syzygy wrote:Mine weren't even arguments, let alone straw man arguments. I was only trying to make sense of your arguments.User923005 wrote:I hold no such position in either case. These are what is know as "straw man" arguments.
You seem to find your string operations example very important:So what exactly does this prove then?User923005 wrote:As a suggested exercise, examine the C and Assembly language versions of the string operations I put here in a previous post in this thread.
You will see that the compiler has removed all the syntactic sugar from the code and left only the bare algorithm behind as assembly languge. Examine the C code carefully. I happen to know that these versions were produced independently by various authors at the same time. You can see by looking at the C code, that the code is not identical. While it is similar, this is certainly due to the task at hand (there are only so many ways that you can accomplish that simple string task). However, upon running the compiler against the C code, the syntactic sugar is squeezed out, leaving the bare assembly language algorithm behind. I think you will see upon examination of the assembly language that the assembly language produced is for all intents and purposes identical.
It is important to understand that the algorithm is not protected by a copyright -- only the implementation. This is, of course, exactly as it should be.
I think what you are trying to say is that for this example of yours, there is no "copyrightable" distinction between the object code obtained from compiling the first version and the object code obtained from compiling the second version. I think you are even implying that essentially any source code implementing these string operations will compile to essentially the same object code. Your conclusion seems to be that based on the object code, you can't say anything regarding the originality of the source code. This is because all originality was weeded out by the compiler. The object code corresponds to the algorithm and is unprotectable by copyright.
So far this is all fine and dandy. I do not disagree. I don't think anyone disagrees.
However, what is the point of your examples? I must assume that you are not mentioning them for nothing. Indeed, you seem to be putting great weight on them.
I can make sense of why your are giving these examples if I assume that you consider these examples to be representative of all algorithm / source code / object code relationships, or at least for those related to chess programming. If these examples are indeed representative, that would mean that object code in general is free from the copyright on the source code from which the object code was compiled. However, in general, that is complete nonsense.
The other possibility is that you were NOT trying to imply that the string operation examples were representative. In that case, I can only conclude that you were bringing them forward as a straw man argument.
Since everyone who writes a high end program uses LMR, can we therefore conclude that all of them have also violated the second rule?
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: On Dalke
I keep repeating this because it is exactly what has been demonstrated.syzygy wrote:Nobody involved in all of this has ever stated that this rule prohibited the copying of ideas. Yet you keep repeating this point. I'll refrain from trying to guess why your are doing this.User923005 wrote:If (indeed) Rybka has copied algorithms {and I agree, it has} then, by the letter of the law we might say that Rybka is guilty of violating point 2 of the ICGA agreement.
We are all in agreement that we have not shown the source to be identical.
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: On Dalke
Strike that, reverse it.hyatt wrote:Computer algorithms can not be patented. Been the case for 30+ years now.User923005 wrote:Algorithms, indeed, do fall under patent protection. If an algorithm has a patent, it cannot be used without permission.
I doubt if Fabian or Robert have patented any of their algorithms, but I am certainly ready to be corrected on that.
The decompiled C may not resemble the original source very closely. Especially things like switch statements and other control flow ideas will be mangled to whatever the compiler thought was fastest. Tail recursion may have been eliminated. We are sure to see constant folding and constant lifting, etc. So a decompiler may produce code that produces equivalent results but it will not produce the same source in the case of compiled high level languages. Things that use pcode interpreters like Java and dotnet languages will produce output that is far more similar to the original upon decompilation.As far as different ways of doing things, the C library changes all the time. Check out the change to strcpy() that broke the 64 bit adobe flash player we all use. Things change regularly.
That's a challenge one can address directly and simply. How about we use (say) Crafty and Fruit? The easiest comparison would be to compile just the search function for both, and then use hexrays to decompile it so that it would be easier for non-asm folks to read. If the asm is "close" the decompiled C should be "close" agreed? You might be in for a HUGE shock, however.As a suggested exercise, examine the C and Assembly language versions of the string operations I put here in a previous post in this thread.
You will see that the compiler has removed all the syntactic sugar from the code and left only the bare algorithm behind as assembly languge. Examine the C code carefully. I happen to know that these versions were produced independently by various authors at the same time. You can see by looking at the C code, that the code is not identical. While it is similar, this is certainly due to the task at hand (there are only so many ways that you can accomplish that simple string task). However, upon running the compiler against the C code, the syntactic sugar is squeezed out, leaving the bare assembly language algorithm behind. I think you will see upon examination of the assembly language that the assembly language produced is for all intents and purposes identical.
It is important to understand that the algorithm is not protected by a copyright -- only the implementation. This is, of course, exactly as it should be.
I think you will also find that other people's alpha beta implementations, their LRM implementations, their null move implementations, etc. closely resemble one another when viewed from the level of the generated assembly language. A close inspection will reveal, for basically almost any pair of programs that implement these things, "semantic equivalence" which means that the programs are performing the same steps. Of course, that is *exactly* what an algorithm is.
So, the logical step is to throw out every result from every ICGA contest that has ever been held. In addition, a press release should be sent to various publications, informing one and all that all persons who have ever entered an ICGA event are both liars and cheaters.
It is clear to me that many so-called computer scientists have no idea what an algorithm is. The *EXACT* steps of an algorithm are *NOT* protected by copyright. It is only the actual implementation that is protected. It is not like a story book where specific plot details cannot be identical.
Keep in mind that none of this is any sort of proof that Vas is innocent. It is only a demonstration that what the evidence *proves* is that Vas has done what everyone else has done. That is to say, he has used the algorithms of other programs in his program. This is, of course, a very good idea because it is stupid to reinvent the wheel every time you build a car.
I do not discount the possiblity that Vas has done something bad. He may well have. However, the evidence presented is entirely unconvincing to me.
Re: On Dalke
My impression is that some of this is fallout from the copyright barrier being perceived to be too high, and thus dutiful filings are made to get some notion of "protection" to satisfy higher-ups. [I heard that one of the credit card companies had some patent on a cryptographic scheme utilising binary arithmetic -- just to be difficult, another one patented the same scheme in base 3 (where it is not efficient)]. It's not relevant to much, but here's a 2001 paper that tried to come up with an alternative solution.Over 200,000 software patents have been issued in the U.S. and many more are in the queue
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: On Dalke
I am doing this because that is exactly what has been demonstrated. Code copying has not been demonstrated.syzygy wrote:Nobody involved in all of this has ever stated that this rule prohibited the copying of ideas. Yet you keep repeating this point. I'll refrain from trying to guess why your are doing this.User923005 wrote:If (indeed) Rybka has copied algorithms {and I agree, it has} then, by the letter of the law we might say that Rybka is guilty of violating point 2 of the ICGA agreement.
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: On Dalke
See:BB+ wrote:My impression is that some of this is fallout from the copyright barrier being perceived to be too high, and thus dutiful filings are made to get some notion of "protection" to satisfy higher-ups. [I heard that one of the credit card companies had some patent on a cryptographic scheme utilising binary arithmetic -- just to be difficult, another one patented the same scheme in base 3 (where it is not efficient)]. It's not relevant to much, but here's a 2001 paper that tried to come up with an alternative solution.Over 200,000 software patents have been issued in the U.S. and many more are in the queue
http://www.setit.rnu.tn/last_edition/se ... ue/312.pdf
www.enggjournals.com/ijcse/doc/IJCSE10-02-05-116.pdf
for sample physical ternary implementations in hardware.
Re: On Dalke
So now I secretly take a decompiler, decompile Word.exe, and recompile it. I publish the resulting executable, claiming that I wrote it myself based on the same algorithms that Microsoft used.User923005 wrote:The string examples show very plainly that different source {IOW, source that is coded by different people but using the same algorithm} which is obviously not a source level copy can produce identical assembly language because the algorithm is the same. In the case of Rybka, even that cannot possibly be a perfect match because the underlying representation is different. The "semantic equivalence" that has been demonstrated is nothing more than showing similar algorithms for small snippets of code, which is exactly the same thing that we would see if we examined, for instance, two LMR implementations or two alpha-beta implementations which came from studying the same original versions.
Will I walk away free?
Assuming I walk away free, is it because:
(1) it is impossible to prove that I did not write it myself from scratch, or is it because
(2) the object code is in fact nothing more nothing less than the algorithm, so free of copyright?
Maybe your answer is: (1) and not (2). In that case, my Word.exe executable in principle shares sufficient creative aspects with the original Word.exe, but I have the defense of independent creation. However, in such a case (i.e. common creative aspects in the expression of the algorithm) it is the alleged infringer who bears the burden of proof for showing that there was independent creation.
But of course copyright law is more or less irrelevant here. What is important is rule 2. What is also important is that Vas was given the opportunity to clarify things, but did not bother.
As you very well know, the accusation is that of the copying of code, not the copying of algorithms. What you keep repeating has no basis in the facts.I am doing this because that is exactly what has been demonstrated. Code copying has not been demonstrated.
You are contesting the factual finding that there was copying of code. So you are contesting the factual findings, not the procedure.
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: On Dalke
1. Microsoft has patents on their algorithms, including algorithms used in word.syzygy wrote:So now I secretly take a decompiler, decompile Word.exe, and recompile it. I publish the resulting executable, claiming that I wrote it myself based on the same algorithms that Microsoft used.User923005 wrote:The string examples show very plainly that different source {IOW, source that is coded by different people but using the same algorithm} which is obviously not a source level copy can produce identical assembly language because the algorithm is the same. In the case of Rybka, even that cannot possibly be a perfect match because the underlying representation is different. The "semantic equivalence" that has been demonstrated is nothing more than showing similar algorithms for small snippets of code, which is exactly the same thing that we would see if we examined, for instance, two LMR implementations or two alpha-beta implementations which came from studying the same original versions.
Will I walk away free?
Assuming I walk away free, is it because:
2. You could likely prove that the resultant binary is a duplicate in a number of different ways, including long stretches of identical assembly.
3. Microsoft would surely get a subpoena for your source code.
Nothing is impossible.(1) it is impossible to prove that I did not write it myself from scratch, or is it because
The object code is more than the algorithms and does have a copyright.(2) the object code is in fact nothing more nothing less than the algorithm, so free of copyright?
The burden of proof lies upon the accusers and not the accused.Maybe your answer is: (1) and not (2). In that case, my Word.exe executable in principle shares sufficient creative aspects with the original Word.exe, but I have the defense of independent creation. However, in such a case (i.e. common creative aspects in the expression of the algorithm) it is the alleged infringer who bears the burden of proof for showing that there was independent creation.
But of course copyright law is more or less irrelevant here. What is important is rule 2. What is also important is that Vas was given the opportunity to clarify things, but did not bother.
I am contesting both. It was not proven that code was copied and the procedure used (a collection of his competitors was used to convict him, among other things) was bad.As you very well know, the accusation is that of the copying of code, not the copying of algorithms. What you keep repeating has no basis in the facts.I am doing this because that is exactly what has been demonstrated. Code copying has not been demonstrated.
You are contesting the factual finding that there was copying of code. So you are contesting the factual findings, not the procedure.
Re: On Dalke
I have three works:
I think most agree that B infringes upon A due to literal copying (of the object code). According to my understanding of the arguments of others, C does not infringe upon A. Somehow this seems undesirable to me. I would rather it be that the C combination is just a "translation" for copyright infringement. [I also think the emulation in the above example will likely fool BinDiff (into giving what to me is a "false" negative), whereas decompiling, translating to a different language, and then recompiling would probably not].
A: The Fruit 2.1 source and object code (from a given compiler). B: A suitable emulator E1 and the above Fruit 2.1 object code. C: A suitable emulator E2 and the Fruit 2.1 object code suitably scrambled so as to avoid detection.
I think most agree that B infringes upon A due to literal copying (of the object code). According to my understanding of the arguments of others, C does not infringe upon A. Somehow this seems undesirable to me. I would rather it be that the C combination is just a "translation" for copyright infringement. [I also think the emulation in the above example will likely fool BinDiff (into giving what to me is a "false" negative), whereas decompiling, translating to a different language, and then recompiling would probably not].