> The PC emulation community could also theoretically use the data to improve their software so that it imitates the original systems perfectly. However, since the leaked documentation has been illegally obtained this would put them in murky territory.
I'd love to hear opinions about this whole thing from folks who work on emulators.
I don't work on emulators, but I do work on Wine. We explicitly forbid any contributions from anyone who has seen any Microsoft source code. The risk of introducing work derived from code owned by Microsoft is too high. I don't know how strict emulator authors are about this--they're non-commercial and so have less at stake than we do--but if I were an emulator author, I would cut ties with anyone known to have looked at this material. The whole reason emulators are legal and ROMs aren't is because emulators are original work not owned by the console developer. Once you start introducing derived work, that all flies out the window, and Nintendo can crack down on the emulators themselves.
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).
> 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.
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.
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.
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.
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.
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?").
The whole reason emulators are legal and ROMs aren't is because emulators are original work not owned by the console developer.
Except that people need ROMs to test emulators with.
Just like the old saying that it's impossible to actually start "from scratch", at some point everything is a derivative work of everything else; it just has to be far enough away to not attract legal attention.
It's not really comparable. It is legal to rip ROMs for your own use. Distributing ROMs discreetly is illegal, but also basically impossible to prove. If reverse-engineered, the hardware ABI that the cartridge uses to converse with the system is not copyrightable[1] so you can distribute an emulator that you developed. Meanwhile it's pretty trivial to prove that some code is derived from some other code or some internal docs. The legal risks are wildly different.
Incorrect. People say this all the time but no, it is not in fact legal. It's never been tested in court and Nintendo takes the explicit view that both it is illegal to rip your own roms and that said devices are illegal.
Now you and I can disagree with Nintendo, but Nintendo could sue someone for ripping their own roms. They won't however, because it would be an incredibly difficult case to prove. Don't mistake that for it being legal or illegal however.
Without a test case, we cannot state with certainty whether it is legal or illegal - particularly as some jurisdictions have carve-outs from copyright for format shifting.
Nintendo could sue for someone ripping their own ROMs; what is unclear, and also would determine legality, is whether Nintendo would win.
Do you have a source for that? I don't see how it can't be legal, no copyright is violated. Ripping DVDs is illegal, because the DMCA makes cracking encryption even for personal use illegal, but that doesn't apply to unencrypted ROMs.
I wonder. What’s the difference between ripping the ROM of an IC versus just hooking the address and data pins of the IC into your computer and using some code to interface with the emulator?
Meanwhile it's pretty trivial to prove that some code is derived from some other code or some internal docs.
There are only so many sensible ways to do things. Straight copying would certainly be stupid but I think it won't be provable unless you decide to include specific aspects which would not be possible to discover through reverse-engineering, and it is likely such things wouldn't affect emulation anyway, so obviously as an emulator developer would be of no real use.
I don't work on emulators myself but I know a few people who do. Their position thus far as been to stay as far away from the leak as possible. What they're hoping for is that someone will use it to improve the documentation on the various *brew wiki. Then that documentation could be used to improve the emulators.
Directly using the code to improve the emulator is a huge liability. It makes it very easy to make a copyright violation case. For an example, look at ReactOS, that had to cease development to eliminate copyrighted code back in 2006[0].
Don't have a link at hand right now but: the Dolphin (GameCube/Wii emulator) developers posted a statement on Twitter saying if they would use these instructions instead of doing the reverse engineering on their own, Nintendo would shut them down.
I made very small contributions to Yuzu (switch emulator), and there's an extremely strict anti-piracy stance to the entire dev process.
The entire dev discord is entirely anti-piracy as well. Anything linking the source code to pirated code would "taint" the whole project legally.
So while you can theoretically read those leaks on your own and use that acquired knowledge to contribute to the project, there has to be a hard stance against tainted contributions to protect the project legally.
I'd love to hear opinions about this whole thing from folks who work on emulators.