[Wine] Legal Issues

James Mckenzie jjmckenzie51 at earthlink.net
Sat Dec 26 20:49:47 CST 2009


oiaohm wrote:

>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.
>
Correct.  That is why we have compliance testing and what we attempt to build functions to.  

Say there is a function (I'm working on this one, so bear with me) that formats text and then puts text into a 'box' that is sized to match a page.  This function is described in MSDN (which make it public knowledge) and then we use the tests to insure that MSDN is correct (it has been known to be wildly incorrect).  We feed in certain values to the black box and see what comes out.  We test all values and even include 'corner tests' which are where functions are supposed to change values but sometimes do not.  Clean room means that we delve into the actual code and find out what it does and then attempt to do a better job than the original.  


>Notice a critical difference Clean Room does not provide patent protection. 
>
It is also against the law in some cases.  I know that this is so in the United States and is covered under copywright and patent laws.  You cannot replicate, in detail, the functions provided by a certain piece of code.

>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.  
>
Yes.  You can duplicate how a Word document is put together.  You cannot duplicate the code of the program itself.

>Clean Room can also be highly costly using lawyers and the like.  It is simpler to Black Box than clean room.
>
Also clean room can lead to the closure of your project....


>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. 
>
This is a good example of what Wine does with complex video calls.  It is also why games and the such will never work as well as they do in Windows, if they are built for Windows.  You have to convert the DirectX call into an OpenGL call and then convert the results back.  This will slow down the screen display.  However, if you use a well made OpenGL driver, this can be minimized or even be faster than the DirectX call.  

>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. 
>
Actually, there is undocumented code all over the place in Wine.  If we documented each and every call and code piece, Wine would become very large.  However, when there is a question where code came from, we can go into git and find out who added what line (with some restrictions) and when.  

>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.
>
True.  We should document in stubs why the value returned is needed.  As we build out stubs then the comments can be removed.

>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.

The above is not necessarily true.  Some functions, like the one that I'm working on, will not be accepted if it contains errors.  However, if your code 'duplicates' the functioning of other code, then you are not black-boxing or you just happened to hit on the exact same code.  The first means that your creditability is gone, the second means someone has to 'fix' your code so that it functions in a different manner.  Something like moving the case selections in a switch statement or removing code that is not needed.

>
>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.
>
If you work on code for a couple of years, you should get it right.

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

This is very true.  It is very hard to 'get the same code' exactly if you are not reverse-engineering.  The legal reason for this is that is can end a project, suddenly.  So, the Wine project, from the start, has not allowed reverse engineered code.  Black boxed code is allowed if you can prove that the results are what are obtained by running test scenarios through a 'black box' or some Windows code.  If you cannot, then your code is disallowed.  That is why the project requires, for the most part, conformance tests and the more stringent the better.  This allow code developers and testers to compare results, not line-for-line code.

The bottom line here is as I stated before:  Wine does not and cannot contain code that is in Windows.  We include some programs that provide the same functionality as those included with, but not owned by, Windows.  For instance, the Notepad program included with Wine is a public domain program, that has been improved by the Wine project.

One item I do have to stress is that you must read the End User License Agreement (EULA) that comes with any program to insure that you are compliant with its restrictions.  The Wine project cannot be held responsible if you are not doing this and are found out of compliance.  The Windows XP license does NOT restrict use of the software contained within to only Windows operating systems, although it would be a good idea to have a valid Windows license when doing so.  Windows 7's EULA does restrict.  

Please also keep in mind that consulting a legal authority in your jurisdiction is also HIGHLY advised before using or installing a program in the Wine environment.  Laws and rules do differ from country to country.  My opinions are based upon case law here in the United States where companies and software licensees are severely restricted as to what and where they can use software products unless there is an agreement that states differently.  The E.U. and other countries have found such licenses unenforceable or invalid.

Please keep in mind that the 2000 copywright agreement was agreed to by many countries and the E.U. which severely restricts code copying as well.

James McKenzie




More information about the wine-users mailing list