How copyright affects emulators

In a private message, an emulator author asked whether the Nintendo Entertainment System hardware is copyrighted, in order to avoid potential legal problems in distributing an emulator. To avoid having to reexplain it individually to every other emulator author and famiclone builder, I have decided to answer this question publicly. Take this as the ramblings of a U.S. law student, not a lawyer, and feel free to suggest corrections or differences between the U.S. regime explained here and other countries' copyright laws.

Computer hardware is not a "work of authorship" eligible for copyright. It may be a novel invention eligible for patent, but patents last 20 years. It may be an original semiconductor layout, but exclusive rights in mask works last 10 years.

Firmware, such as initial program load (IPL) or Basic Input Output System (BIOS) software, is a computer program subject to copyright as a literary work. This has the same copyright term of life plus 70 years or publication plus 95 years, depending on circumstances, as any other literary work. But some firmware is so small that the merger doctrine applies. For example, the Supreme Court of the United States held in Lexmark International, Inc. v. Static Control Components, Inc., 387 F.3d 522 (2004), that copying the 55-byte Toner Loading Program of Lexmark's ink cartridges was not an infringement.

One common workaround for firmware copyright is to rewrite the BIOS. Many emulators of the Game Boy Advance, for example, reimplement the GBA BIOS in native code. This is often referred to as a "high-level emulated" (HLE) BIOS. Another is to dump the BIOS from authentic hardware. It is not an infringement for the owner of a lawfully made copy of a computer program to make additional copies necessary for using the program on a particular computer. 17 USC 117. There are plenty of GBA programs to dump the GBA BIOS to the SRAM, and I assume the FDS version of TapeDump can be used to dump the FDS BIOS as if it were an NROM game.

I'll explain how this applies to each of Nintendo's consoles using a 65xx-family CPU:

• Top-loading NES and Famicom consoles have no BIOS.
• The Famicom Disk System RAM cassette has a BIOS. I'm not aware of any NES emulators that support full HLE of the FDS BIOS. Thus all FDS emulators that I'm aware of require the user to dump his own BIOS.
• The front-loading NES has a BIOS, but it runs on a completely separate bus (the CIC) and thus cannot affect the emulated program. I know of one exception: The authentic Nintendo World Championships Game Pak uses the CIC to reset the mapper and thus will not boot on a top-loading NES Control Deck, but that can easily be HLE'd. Likewise, the Super Famicom and Super NES have a CIC, on which the SA-1 coprocessor in a few Super NES games rely for reset, but it too can be HLE'd.
• The Super Famicom and Super NES audio modules contain the S-SMP IPL. It cannot be HLE'd because games are known to jump into the middle of it. But given its 64-byte size and the result of Lexmark, it's unlikely to pose a substantial copyright risk.

Games, on the other hand, are copyrighted as audiovisual works, which get a full publication-plus-95 copyright term. Some of Shiru's games are an exception, as the author has dedicated them to the public domain. Distribution of any of these games is lawful as well, as their authors have granted a suitable copyright license.

One final wrinkle is a legal theory that emulator authors have secondary liability for their users' distribution of infringing copies of ROMs. Several cases involving Sony have set precedents related to contributory infringement and emulators. In fact, Sony has litigated both sides of the issue.

1. The Supreme Court held in Sony v. Universal City Studios that secondary liability for contributory infringement can accrue only when a product lacks a substantial noninfringing use. Sony's Betamax VCR was found not to infringe because time-shifting is a fair use.
2. The U.S. Court of Appeals for the Ninth Circuit held in Sony v. Connectix that Connectix's PlayStation emulator was lawful in how it HLE'd the PlayStation BIOS.
3. Sony v. Bleem was likewise decided in favor of a PlayStation emulator called Bleem! being legal.

It is my opinion that NES and Super NES emulators have a substantial non-infringing use: to test homebrew games. This might not be true of an emulator that can run only a small set of copyrighted ROMs, possibly using a whitelist, and is not distributed by or on behalf of the ROMs' copyright owner.

But the Debian and Fedora projects differ on one point. In Debian, you can sudo apt-get install fceux. The same is true of other GNU/Linux distributions based on Debian, such as Ubuntu and Linux Mint. Red Hat, on the other hand, thinks the existing library of homebrew games isn't big enough for an open-and-shut substantial noninfringing use defense. In my opinion, the explanation by Tom Calloway on Fedora's legal mailing list is part of why Action 53 and compos came to be: to prove NES emulators have a substantial noninfringing use.

Very well written tepples and easy to understand, good work!

The patents on the NES have also expired. Further, the 6502 is not owned/created by nintendo, and the 6502 is the core of all NES emulators.

The only major case I can think of involving people being sued for creating computers that were hardware/software compatible with other computers are the old mac/apple clones that Apple successfully forced out of business. However, those weren't emulators. Bleem was sued by Sony, but Sony lost on all counts, and Bleem was blatantly an emulator replacement for the PS1 with no other functionality or purpose.

Emulators have been around for over 20 years. If they were going to be banned, it would have happened by now. I think it would be very hard to argue that an emulator (which often contain enormous inaccuracies and shortcuts) is an accurate reflection of underlying hardware because it isn't. Take the PPU for example: the PPU on a real NES is a complicated piece of hardware, but an emulated PPU functions absolutely nothing like a real PPU.

I'm really not fond of the pissy attitude on that page.

The best example:


Sounds pretty "professional"

Yup, and thanks to the community, they used the NTSC palette (take Rockman 2 "purples" instead of "reds", Airman stage) and the iNES header... and probably most of the emulation stuff available for free.

Yet Red Hat's legal department takes said "pissy attitude" as a threat.

And yet there is evidence for Nintendo downloading ROM's for use in their VC releases:

http://www.polygon.com/2016/3/18/112659 ... ve-gamings

Frank Cifaldi quoted:

"I would posit," Cifaldi said, "that Nintendo downloaded Super Mario Bros. from the internet and sold it to you."

That's what I meant. ^_^;;

And they'd be right when you consider what happened with Bleem. It doesn't matter that what you're doing is legal if they can just force you into bankruptcy anyway.

Nintendo might not be using ROMs downloaded from the internet (they may have copied them by themself) but they are using the same file format (which they did not invent though). Emulators are not necessarily developed only to play illegally copied Nintendo software. The fact that it can play illegally copied Nintendo software is a necessary consequence, because the emulation would be incorrect if it did not work (however being able to play Nintendo software doesn't necessarily prove that it is correct). If it does not emulate the PPU correctly then the emulation is incorrect, even if all existing games will run correctly.

To my knowledge, the major emulators like FCEUX, Bizhawk (or in the past ZSNES and Nesticle) have never faced a legal challenge from Nintendo/etc. You can interpret that how you will, but I think it shows the likelihood of companies like Nintendo losing that legal battle (despite having profoundly more money). Nintendo has always been hard nosed about these things officially, but they've never put their money where their mouth is. Plus, counter to Nintendo's argument, there is the homebrew market that it can be argued that emulators exist to serve. And again, Nintendo doesn't even own the 6502. Nintendo hasn't even gone after NES/SNES hardware clones.

The idea of emulation is not in and of itself illegal. VMWare has an entire industry based on it.

To help argument you should also to avoid the emulator having a built-in list of hashcodes to correct incorrect headers. I consider having such a built-in database to be bad design anyways regardless of legality; now that NES 2.0 exists, a user could even correct the header themself if needed (using remote databases containing the hashcodes if needed). (A correct emulator has to be capable of running these programs, although they should not run correctly if the header is wrong (running them according to the wrong header instead in such case); if the user insists on using illegal ROM images then it is the user's own job to fix anything that may be wrong with them.)

I would also suggest to implement stuff correctly as long as it is possible that software can depend on it, even if no game currently uses it (for example, to implement all stable unofficial opcodes, and if your emulator implements the VRC6 mapper, to implement the advanced CHR mapping features it supports); this is for correctness and is good to do regardless of legality.

Emulators should not include hacks for specific games; you should instead work to make the implementation have the correctness in order to avoid such problems (if the problem is that the .NES file is wrong, it is the user's job to correct it). If such hacks are instead used as enhancements and the game can work even without, then it should be optional and should be implemented in external modules. If some part of the implementation is incorrect, include it in the list of bugs with the program, and hopefully can later be corrected.

These things would be better software design in general regardless of legality, but may also result in more "substantial non-infringing use" compared to "infringing use" for purpose of legal considerations.

(I also have other comments about emulator design, although they are irrelevant to the current discussion and will not be included in this message.)

Or an emulator can ship with support for an external module that corrects the header. This approach is used by higan, which delegates ROM file cleanup to the "icarus" process. A takedown, if it comes to that, can thus be far more surgical: remove the plaintiff's entries from the database.


Which makes test ROMs describing these behaviors that much more important to the longevity of our hobby. Thank you blargg.


For something that occurs once at startup, the overhead of an external module is negligible. But for something that occurs every single dot, such as a change from the standard 8-sprite fetch pattern to the 15-sprite pattern that I suggested and bunnyboy implemented as an option in AVS, switching back and forth between modules can severely decrease performance. This goes double on mobile devices, which often need a deliberately approximate emulator in order to run in real time. See PocketNES and, to a lesser extent, FCEUX with old PPU.

Yes, this is very reasonable, as long as the emulator can run even without that module. (A more sophisticated program could also allow customization of the exact command to run, although for simplicity you could also do without, as long as at least the ability to disable it is there.)

Yes, although those things are not specific to individual games, and can be implemented in the way which is independent of the individual game in use (an external database could be used to automatically enable them if the user wishes), and I am OK with that as long as it can be configured and disabled by the user (the ability to disable it is needed for correctness).