3 ms·
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 hav
by devit 6y ago
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 6y ago> 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.
- skuthus 6y agoIf you don't look at the source code, how do you know they are re-engineering the source code?
- coldpie 6y agoIt 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 6y agoGot it. Thanks for the clarification
- devit 6y agoI 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 6y agoThe 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 6y agoWhat evidence do you have for this?
- CKN23-ARIN 6y agoThe great thing about parallel reconstruction is that it doesn't leave evidence.
- lostgame 6y agoIf 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.