Tainted code in User32?

[Shachar Shemesh]

Steven Edwards wrote:

>Hello this line:
>
>"However, disassembling NT implementation (WIN32K.SYS) reveals
>that........."
>in
>http://source.winehq.org/source/windows/win.c#L845
>
>was introduced in to winehq by the following patch:
>http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61&r2=1.62
>
>Does this not violate a clean rooming the implementation?
>
I'll remind you that the term "clean room" applies specifically to 
reverse engineering. "Clean room" means that you reverse engineer the 
specs out of an existing product, and then use those specs to write a 
new implementation, without copyright interfering (i.e. - without code 
being copied as derived work).

I'll also remind you that the case that coined the term "clean room", 
the Olivetty BIOS clone, was 100% disassembly, and was deemed legal.

> The ReactOS
>code is a derived work of the Wine code in the case and if soon then we
>have to remove it.
>  
>
If these are the standards you set (i.e. - higher than your own courts), 
you may have to remove the whole of the wine code altogether. Then 
again, there is no other way for you to reimplement Win32 code. The only 
standard Win32 adhers to is set to be "whatever Windows does". Whenever 
MSDN and Windows disagree, Windows is, per definition, the correct 
party. How can you find that out?

Now, in this case it's a single parameter interpretation that was 
disassembled out of the code. I don't think that's cause for concern. If 
large scale disassembly takes place, we try to have the disassembler 
write the specs in human interpreted language, and then have someone 
else do the actual implementation. This is, AFAIK, what happened with 
cards.dll, for example. This follows the clean room doctrine to the letter.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/