Thank you all very much for the clarification, it is exceedingly helpful! I don't care to look at microsoft's code because I doubt I have the stomach for it! But now I feel much better, that I wasn't doing anything wrong by examining the program state of the misbehaving app (it was on wine anyway). I don't mind jumping through hoops of various sizes to isolate a problem, but to have to do that without debugging, yikes!, that's like having both hands tied behind your back!
--- On Wed, 5/13/09, Roderick Colenbrander thunderbird2k@gmail.com wrote:
From: Roderick Colenbrander thunderbird2k@gmail.com Subject: Re: Wine policy question: What is considered "reverse engineering"/what is acceptable? To: "Jerome Leclanche" adys.wh@gmail.com Cc: daniel.santos@pobox.com, wine-devel@winehq.org Date: Wednesday, May 13, 2009, 3:11 PM
On Wed, May 13, 2009 at 10:02 PM, Jerome Leclanche adys.wh@gmail.com wrote:
I thought reverse engineering was only relevant to MS code? As in reverse engineering of windows dlls and so on; another application would be irrelevant.
That's what I understood from it anyway.
First of all I'm not a lawyer ;)
Correct you should avoid looking at windows code. Regarding Microsoft code we only allow black box reverse engineering, so you feed the dll with some input and check the outcome without looking what happens inside (so without checking debug logs of MS dlls). Looking at Microsoft debug traces should be avoided as it is similar to disassembling a program IF it is for the purpose of figuring out what the black box is doing.
Looking at debug traces of programs is fine and as I said it is similar to looking at the output of a disassembler. Sure it can happen that you are looking at calls made by Microsoft code since some Microsoft dlls are being used but you are not aware of that and you are not trying to reverse engineer the particular Microsoft dll, so that would also be fine (though it is a gray area).
Roderick