No, The Nintendo Leak Won’t Help Emulator Developers, And Here’s Why

If you haven’t heard from other websites yet, earlier this year a leak of various Nintendo intellectual properties surfaced on the Internet. This included prototype software dating back to the Game Boy, as well as Verilog files for systems up to the Nintendo 64, GameCube and Wii. This leak seems to have originated from a breach in the BroadOn servers, a small hardware company Nintendo had contracted to make, among other things, the China-only iQue Player.

So, that’s the gist of it out of the way, but what does it all mean? What is the iQue Player? Surely now that a company’s goodies are out in the open, enthusiasts can make use of it and improve their projects, right? Well, no. A lot of things prevent that, and there’s more than enough precedent for it that, to the emulation scene, this was just another Tuesday.

What’s in the Leak

Getting the files to take a look at them yourself comes with a certain risk, just like having a copy of any copyrighted piece of information on your computer. Much of the legal aspects of it might be overlooked on the Internet, but that means we can’t just tell you where to get it, and we obviously can’t endorse the action. However, other people have already rooted through them and categorized everything so we can tell you what the leak contains at a glance.

In China, the Nintendo 64 was available as a plug-and-play controller system called iQue

Most notably, there’s a wealth of source code relating to the Nintendo WII in this leak. That includes the boot0, 1, and 2 bootloaders, plus the full source code and SDK for IOS, the operating system that runs on the Wii’s ARM9 processor. These are all low-level parts of the software side of the Wii, making the underlying system on which the Wii System Menu runs.

There’s also Verilog sources for all the parts of the iQue Player system, a hardware revision of the Nintendo 64 for the Chinese market, and consequently enough information to build a version of it from scratch. Since the company was involved in making the iQue and other projects for Nintendo, there are also extensive planning documents from the 2004-2006 era for such consoles.

Some of it could be interesting, for example, for individuals to use in order to repair their own systems, much like having the schematics to an old home computer to trace down and find where a fault is. But other than that, there isn’t much use for them, at least within legality.

Toxic for Emulator Devs, and Not All That New

If you’re one of the many people thinking this leak could finally make the ever-plagued Nintendo 64 emulation be perfect, we have bad news for you; using the official confidential documents to help build your own reimplementation of these consoles would constitute breach of copyright law. Since Nintendo is already known for not being keen on others emulating their games, and this will net you at best a cease-and-desist order, and at worst a hefty lawsuit.

A proof-of-concept prototype game called Mekton running on SGI hardware from the Project Reality era.

In fact, many of the documents included in this leak which has caused an uproar this month, have already been floating around the ‘net for two decades now. Dubbed “The Oman Archive”, an SGI leak from 1999 exposed the source files for Project Reality, the basis for the Nintendo 64 console. Developers have had to steer clear of those documents ever since, for the same legal issues with them.

Ever since the modern console emulation scene began with Nesticle in 1997, the legality of such software has been put into question numerous times. Arguments can be had that the software is the copyrighted part, and not the arrangement of chips running it, but barely any of those internet opinions are sound legal advice, and neither is my opinion. But the main common agreement between most developers is that an emulator is legal, as long as it is completely reverse-engineered without referencing the copyrighted source material. Which is known as…

The Clean Room Design

You may be familiar with this term if you’ve read about early IBM PC clones and the lawsuits surrounding them. Back in the early 1980s, IBM’s line of PCs were remarkable not only for being leaders in the business market, but also for being built entirely with off-the-shelf parts. This meant that IBM produced none of the hardware in the computer, they simply put it together and wrote a BIOS for it, and therein lay their copyright.

Soon enough, clones from companies such as Sanyo and DEC started appearing — but since they wrote their own BIOS none of them were fully IBM compatible, they merely ran their own flavor of MS-DOS. Eagle Computers was one such company, but instead of writing their own BIOS they were accused of cloning IBM, infringing on IBM’s copyright. It wasn’t until 1983, with Compaq and Phoenix reverse-engineering their own BIOS from scratch, that full compatibility could be achieved legally. Eagle and IBM settled out of court, with Eagle agreeing to write their own BIOS, however they never recovered from the lost sales.

The case had since then been made that in order for a clone product to remain legally protected against copyright infringement suits, it had to be completely built up from scratch without any sort of contact with the source of the material itself, merely a reimplementation of its observed behavior. More relevantly to the subject at hand, this was brought up twice against Sony’s Playstation, once with Connectix’s Video Game Station emulator and Bleem Company’s bleem! emulator. In both cases the jury ruled in favor of the defendants against Sony, cementing precedent for the legality of emulators, but in both cases the legal costs forced the companies into bankruptcy.

But the Data is Still Out There

So who is it for? Legally speaking, this should have never left the hands of Nintendo and BroadOn, so it’s hard to say if this has any use to anybody. Of course, that’s not going to stop everybody and we’re still likely to see effects of it in the future. Since the early 1990s, manufacturers of various countries have been producing clones of the Famicom (known in the west as the NES), affectionately dubbed “famiclones”. These are still produced today in various forms, and now that Nintendo’s patents on the hardware have expired, they’re more prominent than ever in the bootleg and retro markets.

It’s possible then that, through some exploitation of legal loopholes, the files describing console hardware in this leak might end up being used by cloners and we might see knock-off Nintendo 64s in the wild in a few years, but it’s impossible to predict that. At best someone not involved with the development of emulators of the systems included in the leak could use these to assess how close the reverse-engineering efforts have come to the real deal, but in the mean time, the developers themselves need to stay far away from it in order to continue to claim legality to their efforts.

34 thoughts on “No, The Nintendo Leak Won’t Help Emulator Developers, And Here’s Why

  1. The original Compaq reverse engineering didn’t happen completely in isolation: the source to IBM’s BIOS was published in the manual, after all. So just buying the thing got you access to the source (different days…). What Compaq did was use someone who legally had access to the source create a new work describing how it worked. They weren’t isolated from the source at all. Then another team created the new BIOS from that work, and *they* were isolated. Using the source to create the spec is no big deal: that’s why the source was there in the first place.

    Of course in this case Nintendo never released the code for compatibility reasons at all, but for specific business purposes. So yeah, touching this is totally toxic.

    1. Tanden made drives for the original IBM PC, from their version of the BIOS source code they were able to develop and equivalent code that did not use any of the IBM code. So, before Compaq, Tanden PCs were the most compatible.

    2. Of course, what COULD be done is an enterprising individual could use this source code to build a complete specification of the operation of an N64, and then anonymously publish that specification with no mention of said source or even directly referencing Nintendo or the N64. That person could be held liable for having obtained the source code… but only if you could prove their identify and that they actually used the source code during their reverse engineering.

  2. Nice write up, Erin! One minor correction- the caption on the Mekton image is not quite correct. I worked at SGI at the time and later on the prototype dev kits that became the N64. Mekton was a multiplayer game developed for Irix by Alias/Wavefront, based on an IP by R. Talsorian (of Cyberpunk 2020 fame). It was unrelated to the N64, and the demo ran directly on SGI hardware, not on the N64 dev kit. Mekton predates the N64 project by quite a bit.

    The prototype N64 dev kits were an interface card you put in an SGI Indy, and the controllers plugged into it. You plugged a TV into it as well. SGI designed this card, but that’s different than the SGI boxes which hosted it, and Mekton was unrelated. It never turned into much- it was just a tech demo that SGI folks used to demo the hardware.

    1. Thanks for the clarification, that’s super interesting! I’ve made some amends to the article, but it would be interesting to hear from you if you have any more information from those days, since they seem hard to come by!

    1. They also feature projects that allow you to dump ROMs of your own cartridges. There’s no project posted here that requires you to use illegally obtained games to recreate.

  3. Skirting around publicly available, closed source proprietary content when trying to make something that is supposed to emulate said content, that can indeed be interesting.

    Its also a good tale of not using content just because its out there. If it isn’t content that one should have had access to, then it likely isn’t legally benefiting one’s project.

    Its a part of one’s due diligence as a developer to check if the content and source are actually providing something that they in turn have the right to share. Now here one can apply some common sense in most cases and get by without any real issues. But it is worth while keeping an eye out for.

    Though same thing applies for any type of license to be fair.
    If one works on code for closed sourced software, one can’t really use copyleft licensed content. (and vice versa in a lot of cases as well. And some open source licenses aren’t compatible either, so that is a bit of a legal trap…)

  4. Since this articles seems to be produced in “the west” and is aimed at a western audience, why the “known in the west as the NES”? Seems a bit pretentious considering the audience.

    1. If it was being pretentious it’d assume you already knew what a “Famicom” is and not mention “NES” at all. But there’s always someone who is encountering this for the first time.

  5. Clean room development can happen also with using leaked documents or source code, if the actual developers of the “clone” didn’t get into *direct* contact with said copyrighted material.

    If for example someone else reviews this information, and creates a documentation of the inner workings, that do not expose the copyrighted files itself, this is perfectly fine.

    If the ideas are not patented, copyright only protects the files, not the architecture or principle. That’s how a lot of compatible software gets created.

    1. Right. I’m struggling to see how this can’t benefit the clone developers. The information will be compiled from the leaked sources, and as long as nothing is directly copied, the ideas will indeed be useful in solving problems and working through incompatibilities. I think it’s very strange to say that just because you can’t legally do it, it won’t be somehow useful. After all, it would be upon Nintendo to prove that the emulators directly copied it. Doesn’t stop them from trying and using the courts as a kludgeon to put smaller companies out of business, but that will happen regardless of what the smaller company does now.

      1. Amusingly the author demonstrated this exact principle in his article. He noted that “However, other people have already rooted through them and categorized everything so we can tell you what the leak contains at a glance.”

        Should I expect a call from Nintendo legal for reading his summary? /s

  6. Earlier in my life, I loved having illegal copies of MicroSoft software. I loved the thought of “stickin’ it to The Man”.
    Later, I deleted all of that, because I hated MS so much, I didn’t want to give them any legal satisfaction if they decided to crack down on the little guys.

  7. “If one works on code for closed sourced software, one can’t really use copyleft licensed content”

    Since so many misconceptions about free software licenses abound, let me pick a nit here: of course you can use copyleft licensed content with closed source software.

    With the GPL, you only owe the source code to those people you give the resulting binaries to. So if it’s for your own use: no problem (from the GPL at least). If it is for a small group — same (but the GPL gives each member of this group to re-distribute the program, under GPL’s restrictions, so they’d have to pass on the sources with it).

    Of course, you’d have to have the pertinent licenses for the closed source software, too (perhaps because it’s yours).

      1. Pointless comment. Even programmers need to practice their skills with odd projects, sometimes they make emulators. Just because you’re not doing it doesn’t mean it’s the case for everybody, “Captain.”

  8. How about an article on Apple crushing Unitron in Brazil, and thus leaving that market to the PC Clones until Brazil dropped its ban on imports of complete computers in 1992?

    Had sanity prevailed at Apple, they would have used the age old tactic of working around such market protections. Licensed local production. Apple could have recognized that Unitron had a very smart crew and sold them a license to manufacture Macintosh computers for sale in Brazil. Apple could also have used Unitron as a design and engineering company to develop improvements and new products for all markets.

    Vehicle manufacturers have done exactly that for a long time to make money in markets they can’t export vehicles to.

  9. Hmm… Kinda reminds me of the arguments I’ve read for Minecraft modders to NOT use the Mojang-provided deobfuscation maps, because of the risk of copyright trolls later on hunting them down for “using Microsoft copyrighted code”, or the risk of Microsoft itself later changing their mind and going after modders. The argument, which lines up well with this article, is that as long as modders continue their usual reverse-engineering shenanigans and don’t touch or reference the official deobf maps whatsoever, they’ll remain clear to continue doing their own thing without risk of a lawsuit.

  10. Wait, it won’t lead to a perfect emulator because of copyright law? Ugh, shut up nerds. Somebody will just drop it open source and anonymous. When has copyright ever stopped the emulation community?

    1. “When has copyright ever stopped the emulation community?”
      Fair use saves them. Until infringement is proven”. That is the veredict of Sony vs Bleem, thus cementing the legal bases for emulators. Like the article said.

      But If they stick a few lines of copyrighted code and reverse engineering proves the code is copyrighted, then it doesn’t fall under clean room design (fair use). Thus they can sue you for that.

      Also It’s not ninty emulators are accurate, because these definitely emulate basic stuff for quick prototyping their platforms. So i’m pretty sure Nintendo emus are less accurate than open source ones. For a good reason: they focus on their hardware.

      1. It’s 2020. You can write code based on leaks and spread it far and wide, anonymously. The litigious nature of Nintendo is well known, so anyone working on fan games, ports, or emulators should not be using their real names at this point. If you are sufficiently paranoid, use a VPN or Tor when uploading it somewhere, and publicize it using throwaway accounts.

        99% of the emulator users are downloading “illegal” ROMs. No reason the emulators can’t thrive that way too, hosted on some of the same ROM sites.

  11. A smart Nintendo move would be to provide a N64 mini from the iQUE research. It’s definitely the way to go, that way people will buy it anyway instead of resorting to clones.

  12. Maybe I’m speaking out of school in saying this, but as SGI has gone through multiple changes of ownership I figure few would care.

    Inside SGI, the N64 was known as “Project Reality”. Within SGI’s network, most systems had open guest accounts, so you could rlogin to most systems on the network without a password (1996, folks!) SGI’s network was heavily firewalled (sgigate), but inside it was quite open. Only those who knew which server to go to could see the PR source code and docs. It wasn’t a huge secret, because I found out by just emailing one of the managers and asking, but it wasn’t openly discussed. He just told me to look freely, but don’t distribute. Never did, nor would.

    We did have a central system where most of the source code for Irix and so forth was, but the code wasn’t there. Initially, anyway. SGI really expected to win the deal for the next-gen system (what we now call Gamecube), and when ArtX won it the management were not happy. The fact that ArtX was most of the ex-Project Reality team was also an irritation.

    I can’t say for sure it was the next day, but within a few days of that announcement the Project Reality code was on the source code server. It seemed like a bit of a screw you to Nintendo, and a bit of a temper tantrum. But there it was.

    I worked for SGI from 1994-1999.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.