[Wine] Re: Legal Issues

oiaohm wineforum-user at winehq.org
Sat Dec 26 18:47:32 CST 2009


army_ant7 technically Wine does not ship with Direct X.   Wine contains wined3d and other wine parts that does basically the same thing as Direct X built by blackboxing.

Wined3d reports that it Direct3d to applications even that it mapping even operation that has been blackboxed out of Direct X to opengl.  Same with wine equal to direct x audio parts mapping to other sound systems.

Wined3d runs on windows as well as every platform.  Wined3d is used by companies like vmware for making Direct X applications inside there virtual machine work.

Basically you just claimed wine contains something it does not army_ant7 internals of wined3d no where close to those of Direct3D.

http://en.wikipedia.org/wiki/Black_box_testing     Black box testing is technically not reversing.

http://en.wikipedia.org/wiki/Clean_room_design  This is reversing clean room.

Wikipedia is a pain in ass to find stuff on reversing.

Notice a critical difference Clean Room does not provide patent protection. 

Black box testing on the other hand.  If internal implementations happen to match its independent development.   Allowed for under patent law.   Basically once you look inside the black box you are no longer fully independent.  

Clean Room can also be highly costly using lawyers and the like.  It is simpler to Black Box than clean room.

When it comes to reverse engineering Wikipedia is weak it can lead you to a lot of wrong places.

Basically there are no known legal issues in wine army_ant7.

Yes most of wine has been built from scratch with test cases guiding the way.

Black boxing is simple to prove.  Bugs unique to wine have proven it many times over.  Followed by testcases to testing function.  Followed by that the internal code is not even close to MS design.   MS direct X never redirects to opengl it goes down threw a completely different hardware path. 

Then there is what called magic code that has a bad habit appearing in clean room and black box works.  The magic code style is unique to each type.  Not documented with why it is really doing something is magic code. 

Wine does have some magic code but is normal magic code for blackboxing.  Ie stubs that return a value got from black boxing with no clue why the function is returning that value inputs to function just junked.  Note the black box stubs have a logical reason a test case acquired the result to return.   But why the returned value no one is sure.

Clean room/disassemble magic code is different.   Inside functions there is magic code performing operations with no logical reason or data supporting it.    This code would normally appear and function correctly without any development process.  Ie not natural.  Code normally never just works perfectly normally need to be edited and corrected.  It has finger prints.   Lack of mistakes requiring reversions and corrections is a clear warning sign to Clean room or disassemble being used.

Yes history of wine a few developers have been caught being stupid enough to try to sneak disassemble or clean room stuff in.   The lead maintainer does look for the signs.   If a developer does get caught there code will be removed from wine.   Most cases they get caught before they have had any of there code merged into the project.  Lack of errors is a major giveaway.  Its not human to get it perfectly right first time a lot.

army_ant7 basically if you had a greater understanding of detection of reversing you would have known it has a signature.







More information about the wine-users mailing list