Is F4I in violation of the LGPL? - Part III
"Frank" posted the following comment to my last update.
"What does this code fragment do? It accesses data that is well-defined by an open specification. There is little leeway for a software developer to do things differently. So far, this may be coincidence, or a case of developers being "inspired" by looking at other source code -- like the famous "stolen" Unix code fragments in Linux. This is an invitation for more research, yes, but I don't see a smoking gun just yet."
This is a valid concern and I wanted to address this anyway, so let's do it right here. I think it's important enough to write a new update instead of just replying to Frank.
I've produced a complete annotated disassembly of the function in question. It matches the function from the LAME code 99%. I say 99% because there are differences which can be reasonably explained by common compiler optimization techniques. I've mentioned these techniques in the annotated disassembly where appropriate.
If the 99%/100% match of a 90 lines C function is a coincidence it goes beyond what I'm capable to detect using my tools.
Click here for the LAME source code.
Click here for the annotated disassembly.
Edit: I want to ask the people familiar with the LAME function in question something. Look at the following four lines from the LAME source code:
This piece of code attempts to check if buf contains 'Xing' or 'Info'. I don't know about the underlying data structures but the way it checks looks wrong to me. This piece of code passes if buf is a combination of 'Xing' and 'Info', like 'Iing' or 'Xnfo' which is probably not the desired functionality. Can anybody confirm that this is a bug or is not a bug? Because if it's a bug it's also part of the F4I code. This would solidify the assumption that the code was stolen from LAME even more.
Edit: OK guys, I'm going to proclaim victory now as I've found undeniable proof that this match is not a coincidence. I just took the the functions GetVbrTag and ExtractI4 from the LAME code and compiled them myself using the freely available Visual C++ 2003 commandline tools. The only compiler parameter I used is /Ox to turn on maximum optimizations. The resulting code is byte for byte the code from the F4I OCX file. Including all my correctly predicted compiler optimizations (function inlining, if-clause merging, operation re-ordering, ...).
Click here to see the disassembly of my own compiled version of the LAME code. It matches the disassembly posted earlier perfectly. Note that I didn't bother to re-name variables or to insert comments.
"What does this code fragment do? It accesses data that is well-defined by an open specification. There is little leeway for a software developer to do things differently. So far, this may be coincidence, or a case of developers being "inspired" by looking at other source code -- like the famous "stolen" Unix code fragments in Linux. This is an invitation for more research, yes, but I don't see a smoking gun just yet."
This is a valid concern and I wanted to address this anyway, so let's do it right here. I think it's important enough to write a new update instead of just replying to Frank.
I've produced a complete annotated disassembly of the function in question. It matches the function from the LAME code 99%. I say 99% because there are differences which can be reasonably explained by common compiler optimization techniques. I've mentioned these techniques in the annotated disassembly where appropriate.
If the 99%/100% match of a 90 lines C function is a coincidence it goes beyond what I'm capable to detect using my tools.
Click here for the LAME source code.
Click here for the annotated disassembly.
Edit: I want to ask the people familiar with the LAME function in question something. Look at the following four lines from the LAME source code:
if( buf[0] != VBRTag[0] && buf[0] != VBRTag2[0] ) return 0; / fail / if( buf[1] != VBRTag[1] && buf[1] != VBRTag2[1]) return 0; /* header not found*/ if( buf[2] != VBRTag[2] && buf[2] != VBRTag2[2]) return 0; if( buf[3] != VBRTag[3] && buf[3] != VBRTag2[3]) return 0;
This piece of code attempts to check if buf contains 'Xing' or 'Info'. I don't know about the underlying data structures but the way it checks looks wrong to me. This piece of code passes if buf is a combination of 'Xing' and 'Info', like 'Iing' or 'Xnfo' which is probably not the desired functionality. Can anybody confirm that this is a bug or is not a bug? Because if it's a bug it's also part of the F4I code. This would solidify the assumption that the code was stolen from LAME even more.
Edit: OK guys, I'm going to proclaim victory now as I've found undeniable proof that this match is not a coincidence. I just took the the functions GetVbrTag and ExtractI4 from the LAME code and compiled them myself using the freely available Visual C++ 2003 commandline tools. The only compiler parameter I used is /Ox to turn on maximum optimizations. The resulting code is byte for byte the code from the F4I OCX file. Including all my correctly predicted compiler optimizations (function inlining, if-clause merging, operation re-ordering, ...).
Click here to see the disassembly of my own compiled version of the LAME code. It matches the disassembly posted earlier perfectly. Note that I didn't bother to re-name variables or to insert comments.
Comments
Display comments as Linear | Threaded
Gabriel Bouvigne on :
sp on :
Of course it's not like there's any doubt at this point thanks to the recent findings.