slobo wrote:Sven Schüle wrote:
One of my points was that I would not regard publishing the source code that results from reverse engineering a commercial closed-source program as legitimate, and that our community should not accept such doing.
Sven
Let me ask you a question:
Should "our community" accept past and copying codes from open source GPL chess engines and its posterior usage in commercial closed source chess engines?
Please, don't come to me with your argument that it is an off topic question. Have in mind that I am the father of this thread, and I certainly know very well what is on topic and what is not. In such a condition let me make it a little clearer to you: Milos's answer was not off topic.
Yes, it is your thread. As long as modifying the discussion target and posing new questions without answering old ones does not annoy me too much I'll try to follow
.
Regarding your new question: no, we should not accept that if it occurs. (I'll come back later on the relation of this new question to the original topic.)
But since it is obvious for me that you are talking about the "Rybka Beta Is Fruity" issue I have to add that there are very different opinions about the validity of what has been called a "proof". I know the old threads very well, links to these have been provided again very recently (I even think it was done by you) but I also followed the discussion closely at that time. I know especially the 58 pages thread from end of August 2008. But there was no conclusion that was agreed by both sides. Instead, one side (mostly represented by Bob) insisted on its claim that the assembler code that was shown would prove copying of Fruit source code related to UCI protocol handling. Some others opposed, as far as I remember, that there were too many differences to accept this as a proof. For parts different from UCI handling code I have never seen any code comparison of Rybka beta binary vs. Fruit 2.1 source, there was just a list of verbal items as far as I remember.
At the end of the 58 pages thread publishing of more data was promised but it actually never happened, and the discussion died right in the middle. So it is apparently wrong to repeatedly refer to these old threads in a way suggesting that there had been a proof. Bob does so frequently but I am not the only one who does not believe resp. accept it. If several people do not accept it, give their reasons, and call for more evidence which is not provided then nobody can ignore this and say later (17 months later now) that the copying from Fruit has definitely been proven.
I want to go further. As a developer, I am able to look into disassembled code on my own, too. I have done this recently with the Rybka 1.0 beta which is still available for download, and started with the UCI code, as everyone would start there since that code is easiest to find due to the strings related to UCI protocol. And on the other side I have looked into the Fruit 2.1 source. What I found was this (note that function names from a binary usually cannot be reconstructed by disassembling, therefore I use double quotes to indicate the semantics at least):
- All, or at least most, of the UCI elements that are handled in Fruit 2.1 are also handled in R1. Why? Obviously because they are required to meet the protocol spec.
- The overall structuring into UCI handling related functions is similar in both programs: there is some "main loop" function starting with init code, including setting up the board from the initial FEN string, and then infinitely calling a "loop step" function which handles one UCI command each time. Why? Because this structure is obvious for a UCI engine.
- The order in which the UCI elements are handled in R1 within the "loop step" function differs quite a lot from that in Fruit. Look at it yourself.
- The way how UCI command strings are compared technically differs in R1 from Fruit. Fruit uses two utility functions that in turn use strcmp() and strstr() while in R1 assembler code I cannot consistently identify use of the same functions. According to my interpretation (and yes, disassembling is also interpretation!!), sometimes strncmp() is used which implies a logically different approach.
- The code that implements the several UCI commands in the R1 "loop step" function does not match exactly that in Fruit 2.1. There are similarities sometimes but these can be based on copying ideas.
- The implementation of the "go" command is done in a separate function in both progs, let's call it "parse go" function. There I find the same as in the "loop step" function: different order of UCI elements, partially different implementation of handling of these elements, partially different string comparison methods.
Most of these items had already been mentioned by some people in the past, which was the reason for not accepting any proof back then. In my opinion, after looking into the details, I am pretty sure about this: The R1 UCI code does not look like copied from Fruit for me. But if the R1 code (only this had really been subject of detailled comparison) ever started from a Fruit 2.1 copy then there were so many changes until R1 beta that the copying aspect has gone. Taking also into account that there is only an 1:N mapping of binary to source by disassembling/decompiling, I still cannot follow the GPL breaking claim in this case right now.
Also I still have the impression that the comparison activities of the past had too much of the "Strelka" case in mind, it was too often tried to include elements of the published Strelka source code into the comparison, although it must have been clear to everyone that this Strelka source was already result of a disassembling/decompiling and therefore a lot of interpretation where also Fruit source code may have been used to express the results of that interpretation in terms of functions and variables.
-- Now let's come back to what I postponed initially. The relation between your new question that was like "should we accept copying open source and making closed source from the copy" and my previous statement that we should not accept publishing of source that was partially derived from decompiling a closed-source program - in case that has happened - is obvious. You imply, in my opinion, that claiming a GPL copyright infringement is already sufficient to legitimate the second act of decompiling and publishing derived source. But I don't follow that:
- As I explained, there is still substantial opposition against the "R1 Is Fruity" claim. IF the claim were proven to be right, and IF the current Fruit 2.1 copyright owner would then take action according to that, THEN the R1 source code would probably have to be published under GPL. BUT there is no accepted claim AND also the Fruit 2.1 copyright owner has signalized NOT to take any actions in this case.
- So there is not even a base for thinking that decompiling a closed-source program and publishing the source derived that way would be legitimate by any means. But even if that base WOULD exist there would still be a major difference: the "Fruity" program would be R1 but not R3 which is known to have very substantial improvements which are undoubtedly original, intellectual property.
Maybe there are more people in this forum that do follow my opinion. I'd be very interested, of course, to read yours first, and also that of Milos who seems to go conform with you in many points.
Sven
