I heard that Wine uses Windows apps like Notepad, Wordpad, Regedit, etc... Is this legal? I mean, aren't these owned by Microsoft, making them proprietary??? Thanks.
On 2009-12-18 (December, Friday) 06:25:06 army_ant7 wrote:> I heard that Wine uses Windows apps like Notepad, Wordpad, Regedit, etc...Wrong. Wine does not include *Windows* Notepad, etc. Instead, all of these are replaced with LGPL-licensed open-source equivalents. Of course, there is a lot of difference internally (because whole Wine including Wordpad, Notepad, etc. was written from scratch) but to the "end-user" these programs may look similar (however even from end-user point of view there are differences between Wine and Windows versions of Wordpad, Notepad and other standard programs).> Is this legal?Yes.
So they're clean room designs? I get ya... Hahaha... Thanks! :D
Are "sourced clones" and "clean room clones" synonymous?
Sourced clones is finding a program else where under the right license performing the same tasks. Normally not like clean room clones. Think all the versions of tetris that are out there. Lot were created by people have to code a tetris like program for exams and the like. Some if the simple programs like notepad in windows was also used as something to replicate in exams. No disassembling or test casing is normally used in the production of sourced clones. clean room clones. Is suggesting reverse-engineering ie someone disassembles and documents and someone else build clone of program from documentation. Clone don't automatically mean that any reversing was done. Functionality cloning can be done from something as primitive as screen shots of the application being cloned. Lot has to be talked about on a per application base. You can be sure the methods used are legal.
These new codes are made from scratch though? Also, have you guys heard of any applications at all that prohibit you, as in "terms and agreements prohibited," from using them on Wine? Thanks.
I am not aware of any specific programs with that clause (although some specifically disallow use on anything but windows), but software EULAs are unlikely to hold up in court; they are not usually seen as equal to contracts. ------Original Message------ From: army_ant7 Sender: wine-users-bounces at winehq.org To: WineUsers ReplyTo: WineUsers Subject: [Wine] Re: Legal Issues Sent: Dec 20, 2009 8:36 PM These new codes are made from scratch though? Also, have you guys heard of any applications at all that prohibit you, as in "terms and agreements prohibited," from using them on Wine? Thanks. ]
Why would they even put that on the EULA? I mean, did Windows pay them to do that? But still, it would be wrong not to follow their terms. Hahaha... Is there a specific part of the EULA's that states this? Like a certain section?
It was somewhere on the EULA for Microsoft programs (Office for Windows, Internet Explorer, etc.); it's been a few years since I've looked but I don't believe any non-microsoft software states this. ------Original Message------ From: army_ant7 Sender: wine-users-bounces at winehq.org To: WineUsers ReplyTo: WineUsers Subject: [Wine] Re: Legal Issues Sent: Dec 20, 2009 8:53 PM Why would they even put that on the EULA? I mean, did Windows pay them to do that? But still, it would be wrong not to follow their terms. Hahaha... Is there a specific part of the EULA's that states this? Like a certain section? ]
Makes sense! Hahaha... Thanks for the enlightenment.
hacking4food at gmail.com wrote:>------Original Message------ >From: army_ant7 >Sender: wine-users-bounces at winehq.org >To: WineUsers >ReplyTo: WineUsers >Subject: [Wine] Re: Legal Issues >Sent: Dec 20, 2009 8:36 PM > >>These new codes are made from scratch though? Also, have you guys heard of any applications at all that >>prohibit you, as in "terms and agreements prohibited," from using them on Wine? Thanks. > >I am not aware of any specific programs with that clause (although some specifically disallow use on anything >but windows), but software EULAs are unlikely to hold up in court; they are not usually seen as equal to >contracts.Windows 7 does have this in the EULA as well as some other Windows programs. EULAs have been found to be enforceable under U.S. law, but there yet has to be a 'test case' where this has been run through to SCOTUS. However, prior cases have been 'settled out of court'. This means that the people in the case decided not to pursue the issue. This is different in the E.U. where the Court has found the EULA too restrictive and struck down the requirement to run software on Windows (or any other OS for that matter) being unenforceable. Other areas of the world have different opinions. However, before installing software onto your computer, read the EULA and be prepared for the worst. As an instance of this, in order to use Microsoft's fonts, you have to be in possession of a Microsoft License. I have one, with the software package and under the MSDN, so I'm ok. However, if you wipe your hard drive, which had the restoration on it, and are not in physical possession of a copy of Windows (you could even have a uninstallable copy of Windows98SE) then you are technically in violation of the EULA. Will Microsoft come after you? Probably not, but then again, they have been known to do strange things. The bottom line is that you can do whatever you want, but you have to be ready to face the consequences. Consulting legal people before you do something, like install Office 2007 for your entire company, is always a good thing considering the financial problems you can encounter. And as always, you mileage may vary based upon the terrian you live in (in other words, all of the above may not apply depending on where you live and your computer's ability to run the software in the first place.) Very respectfully, James McKenzie> > > > > >] >
Very detailed! Thanks! I really just want to follow the EULA because it's an agreement that I make when I use the software, no matter where I am. (Here in the Philippines those hold up in the law, I think.) I'm wondering if the Internet Explorer of Wine is also clean-room. Is it?
> I heard that Wine uses Windows apps like [...] >Where did you hear this? That is a sincere question as somebody needs correcting. Rather than people individually answering how each element of Wine is coded, how about this: the core wine system, including its regedit, notepad, etc applications are all written *for* wine by people with no access to comparative Microsoft code. I believe that last bit is Wine contribution policy: If you've seen copyright MS code, you're not allowed in to avoid copyright issues. I could be wrong - check the docs if you care. Apps you install on Wine (including IE) keeps its original copyrights and licenses. When you install IE, you're installing a Microsoft product it as you would on a Windows machine. License-wise, nothing changes so if the EULA says you can only run it on a genuine copy of Windows, you cannot install it under Wine and remain under the EULA. There *are* MS products with this clause in their EULA but it's your choice if you want to follow them... Or if they're even enforceable or not... Well... let's not get into that. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.winehq.org/pipermail/wine-users/attachments/20091221/9df8d6e8/attachment.htm>
I just read this on Wikipedia.com. I heard that it provides those including IE... Sorry. I just want to know more about Wine you see, and I extremely appreciate all what you guys have to say. Hahaha... Thanks.
Oh! Sorry for the misunderstanding. It's just that the first part of this http://en.wikipedia.org/wiki/Wine_%28software%29 says, that part of Wine was done by clean rooming and most, I think, by black boxing. I'm not sure about the definitions of both designs, but here goes. Clean rooming is a type of reverse engineering without knowledge of how a proprietary program was made to work, according to Wikipedia. But when I looked at the definition of reverse engineering, which I know some EULA's prohibit, it said something about checking the source code of a program to see how it was made. Black boxing is just making a program from scratch, but copying the functions of a program without checking its source code. Please clarify clean rooming. If my definitions are wrong or lacking, I would greatly appreciate corrections. I'm a little confused though. How do you prove that you haven't ever looked at the source code of the program you're black boxing? BTW, isn't Direct3D proprietary? I'm just wondering why it's incorporated into Wine. I'm a real newb, but I'm striving to learn more. Thanks for everything so far to everyone who's helped. I also hope that other people are benefiting from this. Merry Christmas! P.S. Thanks to Danila Sentiabov for clearing up the misconception in Wikipedia! :-D
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.
The rules of wine are about detectability. It very hard to tell the difference between clean room and someone who has disassembled the program and rewritten the code themselves breaking clean room. Black box difference is detectable. Simple detectable. The trial and error process of it is completely different.
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
> > > > 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.The basic rules are true. Look back at your patches in the processes of development you have put up ideas how to solve problems and so on. Even at times tried different paths. Exactly why would you be bothering trying different paths if you know what is inside. Reversed/clean room source code normally lacks the normal processes of code creation. Would it not be normal for you to put forward patches that get rejected due to over looking something along the way of getting to accepted. Basically there is a natural process to code development. Coder will miss stuff will have to go back and correct stuff. The give away is the lack of that process being required for functionality. There is more than one way of documenting you are forgetting about the commit comments. This is still documentation about the code to be correct for detecting reversing the commit data is more useful. Did this function come to life fully functional or did it need alterations to make it work right. You can see alterations to make the code work right in a progressive way some times the alterations will be helpful sometimes they will cause other bugs this is natural. Once you have a set of progressive alterations it not magic code. Progressive alterations says that it happen in the natural way code does. Yes common mistake when I say documentation people think in source code docs not history and comments on the code that are stored in a independent archive. This also tracks who submitted what this is also handy to work out if anyone is breaking the rules. I should have been more correct with clean room it magic code that is functionally correct without a development process to get there. Probability of doing that once without clean room or reversing is insanely rare. Doing it twice is almost to the point of impossible. Black box it also insanely rare to funny test a function first time and find all bugs and quirks of a function. Another thing that gives people who have reversed or clean roomed away if they try building black box test cases after the fact breach of natural process. Also helps that lot of windows functions have very odd bugs that have to be detected. Lot of code for wine at first does not contain this odd bugs. Ie reversed code would. There are signatures all threw wine code history pointing to the fact it black box code. Non black box would not have the same history.
army_ant7 wrote:> > >@James Mckenzie: You said though, >> 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. > and >> Wine does not and cannot contain code that is in Windows. >> > I found the last part, "...or some Windows code." of the former, and the latter to be contradictory. I may have just understood it > wrong though. Please clarify though if you may. :-) Your grammar was great! I clearly understood you. I have same compliments for > you like those I gave oiaohm. I'd appreciate it too if you try answering the questions I asked him. I values both of your opinions. >Here is the clarification: You can run a test against a Windows Dynamically Linked Library, say riched20.dll looking for the results for a specific test. In my case, this is EM_FORMATRANGE and the dll comes from WindowsXP. I get back values for specific input values. Since I know only what is MSDN, I input a window handle, the call name, TRUE or FALSE, an invalid input value of zero and a FORMATRANGE structure location, I then look at what is returned for each. Then I post the results and build code to replicate what is returned from the call into Wine code. I did not do the original code but I have refined it and am now looking at one final fix so that the code will return the values returned by the call in Windows. That is what black-boxing is about. Now, if I did this with reverse engineering or clean room code, I would run the .dll through a code reversal process that would give me an approximation of the original c or C++ code. Now, if the original programmer threw in 'junk code' this would be detected and I could option to remove it. However, the original code base would remain and I would be liable for a copyright violation. Using a black-box approach, even by several programmers, is not a liable incident, unless the laws or judicial rulings change. The point is that the Wine project contains no line-for-line Windows code. Yes, we replicate the Windows32 API and are working on expanding/improving the code and adding Win16/WindowsOnWindows64 code, but this project is far from complete and there are portions of the API that are undocumented as well. James McKenzie
Thanks guys for clarifying. In truth, I struggled comprehending, after all I'm only in high-school... Hahaha... But if what you guys say is true then, yup ot does sound that Wine is legally ok. But James, I'm wondering about the thing you said. Do you mean "refine" as in modifying by black boxing? So you only refined the functions then? And about using Windows DLL's, just to clarify are libraries the same as API's in the sense that they contain routine functions that are used by different programs?