[devit]

That policy obviously just results in Wine contributors not disclosing seeing Microsoft source code, which is a good thing for Wine, but does not imply that having Microsoft source code (or Nintendo's in this case) is useless.

Also looking at source code and documentation does not mean that the code you write is derived work (although it makes it very slightly more risky that it is).

[coldpie]

> That policy obviously just results in Wine contributors not disclosing seeing Microsoft source code

Absolutely not, we take it very seriously. If there's a hint of looking at Microsoft source code or REing Microsoft binaries, then contributions are banned. It's not a wink-wink kind of situation.

[devit]

I mean that almost surely there are people that do so and carefully make sure to not mention that and make sure that their contributions are not derived work and don't have such "hints".

The main technique to do so is "parallel construction": e.g. you reverse engineer a binary or look at source code, find out a special case not implemented in Wine, then construct a test case that tests the special case and behaves differently in Windows and Wine and claim that you found the test case experimentally, from a personal project that didn't work in Wine or from open source code you find that triggers it (rather than from RE or source code reading); you then implement a patch in the way you find most optimal without influence from how the code you reversed or read did it.

This is in fact good for Wine since it results in both having high quality contributions and having no additional liability.

So Wine's policy effect is not to stop such activity, but to make the Wine project not liable for it; thus, any leaks of Microsoft's source code are in fact good for the project since they enable this activity and the Nintendo situation here is similar.

[zozbot234]

The legally safest route would be to not implement the patch, but merely to describe the difference in behavior that triggers the bug in general terms (yet sufficient to replicate a "correct" behavior). This may also enable you to RE Microsoft binaries that you want to support in Wine, e.g. web browsers, office-productivity applications or development tools, as opposed to OS components.

[1123581321]

What evidence do you have for this?

[CKN23-ARIN]

The great thing about parallel reconstruction is that it doesn't leave evidence.

[lostgame]

If there was evidence it wouldn’t be effective.

That’s like asking a spy for evidence of their current mission.

Does the spy’s denial of knowledge or a lack of evidence of that spy’s mission mean that individual was not a spy? Quite the opposite. It means they were an effective spy.

[1123581321]

This isn’t enlightening. It sounds like there is no evidence and the user to which I originally replied just wanted to besmirch the reputation of the Wine project without a good reason why they are lying about rejecting legally troublesome contributions. It is possible to go about an open source alternative honestly.

[skuthus]

If you don't look at the source code, how do you know they are re-engineering the source code?

[coldpie]

It doesn't come up much, but there's lots of clues. Most often people won't understand the rule, so they will just come out and say that they reverse-engineered some binary. Other clues would be implementing it in some unintuitive way, or with some internal details that an application is not likely to depend on ("why did you do it this way?"), or without adding to our black-box test suite ("how do you know it should behave this way?").

[skuthus]

Got it. Thanks for the clarification