OverClocked #10, "Spare Time" © 2000 David Lloyd

I still feel that most emulators ... are perfectly legal.  It kinda falls into that "legal to own, illegal to use" category that seem to cover game copying devices and cable descramblers.

Jeff Gerstmann, review editor, VideoGames.com

     28 January 1999 marked a significant event in the world of videogame emulation.  It was on that day that a team of two hackers, known only by the aliases of Epsilion and RealityMan, released UltraHLE - the world's first working emulator for the Nintendo 64 videogame console.  Many had tried over the previous year to devise an emulator for that system and failed.  Nintendo was well aware of the rising interest in emulating its popular videogame systems, what with working NES and SNES emulators already available, and they had strongly supported the IDSA sweep against illegal Internet ROM sites during the spring and summer of 1998. They kept abreast of the growing possibility of N64 emulation and were the ones behind the shutdown of Project Unreality, the most promising N64 emulation project of 1998.  They threatened legal action if that project produced a working N64 emulator, so the authors of Project Unreality abandoned their efforts at that time.  Both Epsilion and RealityMan were already quietly conducting a parallel effort to develop a working N64 emulator, but they decided to try a different approach than that of the Project Unreality team.  Instead of starting with the console's base functions and working upwards, they started with its high level functions and worked down (hence the name UltraHLE - Ultra High Level Emulator).  They also decided, in light of Nintendo's public attitude with regards to emulation, that they would not tell anyone about their project until they felt it was ready, and then make it available to as many people as they could in the shortest amount of time.
     The sudden and unexpected release of a working N64 emulator caught the emulation and videogame communities completely by surprise.  What was even more insulting was that UltraHLE promised full compatibility with The Legend of Zelda: The Ocarina of Time (aka Zelda 64), the first N64 entry in the long-running and popular RPG series by Nintendo and its biggest seller of the 1998 Christmas shopping season.  The release of a working N64 emulator promising full compatibility with their newest hit title was just too much to take, so it should not have surprised the emuscene when Nintendo reacted like it did.  The blindsided videogame giant quickly rushed to shut down the UltraHLE website and threatened prosecution against the authors and anyone carrying or supporting UltraHLE, but it was too late.  Epsilion and RealityMan's release tactics had ensured that UltraHLE would be spread far and wide given the nature of the Internet, and a helpless Nintendo could do little but watch as UltraHLE popped up on one site after another in quick and rapid succession.  N64 cart dumps had already been available on the backwater sites for over a year, and now patrons of the "warez scene" had something with which to play their bootleg videogames.  Zelda 64 was the most sought-after "ROM" of the lot, and it took little effort for dedicated Internet users to eventually track it down. UltraHLE was by no means perfect, and only worked with about one-third of the "ROMs" in existence at the time, but it worked with Zelda 64 and Super Mario 64 (the console's flagship title), and that was enough for most folks.
     Nintendo's next reaction was what those familiar with its history might expect.  It continued to threaten legal action against anyone who supported UltraHLE, and threatened to file suit against its authors claiming that the emulator was an infringing work that promoted software piracy.  The threats were considered to be pure bluff by the emulation community and many sites called them on it - those that weren't carrying any bootleg N64 "ROMz," that is.  As for the lawsuit threat against the UltraHLE authors, it is still looming as of this date, and the resultant legal pressures coupled with the instant popularity of UltraHLE among the software pirates forced the temporary "retirement" of RealityMan for a period of several months.  In the meantime, Nintendo continued to flail away at the illegal N64 "ROM" sites whenever it found them, but it was of little use.  At least two more sites would spring up for every one Nintendo managed to shut down, often hosted by unscrupulous ISPs and frequently in countries where Nintendo's famous legal resources were of little avail.  Nintendo continues to maintain to this day that UltraHLE violated the patents and copyrights that it held on the N64 internals and microcode, including the system's anti-piracy security system.  While the construction of UltraHLE remains a closely guarded secret even to this day, both Epsilion and RealityMan contend that it was an 100% reverse engineered software-based emulator; furthermore, the anti-piracy feature was not an issue because they did not emulate it (which would have been illegal).  In the meantime, though, Nintendo's legendary intimidation tactics continue to be employed against anybody who carries UltraHLE and the requisite "ROMs," but the sad truth is that UltraHLE continues to be freely available and can be downloaded by anybody with the will to find it.
     This incident caused some serious soul searching among the emulation community, as well as many a comment from the videogame industry.  Most were of the opinion that UltraHLE should not be supported because it was designed to emulate a product that was very much alive and kicking.  The release of UltraHLE implied that the end-days of the N64 were near, and nobody really believed that.  On the other hand, there were those who argued that they should not discriminate against a supposedly legal emulator regardless of the status of the original system, and these were the folks who continued to carry UltraHLE on their web sites while the rest refused.  The videogame community was equally split, with many expressing admiration for the programmers and their accomplishment while others called for their prompt prosecution.  The debate seems to have died down after RealityMan announced his retirement from the emulation scene, and not long after UltraHLE reappeared on just about every single major emulation site.  Those who had fought its support before now felt justified in carrying it after Nintendo's failed attempts to stop it; furthermore, they noted that there were several public domain "ROMs" available for it just as there were for other videogame emulators.  The availability of a legally downloadable software base for the emulator, however limited and incompatible that might be, seemed enough justification enough to many minds for supporting this remarkable program.  As an afterthought, it is ironic to note that Nintendo announced plans to release a new videogame console (the N2000, later renamed as the Dolphin) not long after the release of UltraHLE, so perhaps those who feared the N64's impending obsolescence may have been right after all.

     In previous discussions, we have seen that emulation is a valid use for a computer system; furthermore, that an unlicensed emulator is possible once the intellectual property concerns are properly addressed.  The time has now come for the next important step:  the release of an unlicensed emulator.

IMPERFECT EMULATION

     In this and future discussions, I will refrain from discussing pure firmware emulators, as well as the more common varieties of hardware-software combinations.  Firmware emulators are almost always produced by original vendors or other companies under license to the original vendor.  Remember, the ability of the Sega Genesis/MegaDrive to emulate a Sega Master System via VDP mode 4 was due to Sega itself and installed as a desire to support its customer base for the older platform.  Sony is taking the same position with regards to the announced release of its newer PlayStation 2 console; they have included a PlayStation emulation mode that permits playing of many (but not all) older titles on the newer system.  This is a practice that is universally accepted within the industry; furthermore, firmware emulators are quite profitable to the original vendor due to the proprietary nature of such.  It would be almost impossible to build a firmware emulator without the consent of the original vendor, aside from the ubiqutous cart adapters, and the laws are quite clear with regards to the illegality of unlicensed clone products.  Just ask all of the folks who tried to manufacture the many unlicensed clones of the NES console during its lifetime and see where it landed them.
     A combination emulator is a different animal altogether, and their very nature tends to blur the legal lines somewhat.  For example, Commodore's cross-licensing agreements with various PC clone manufacturers gave them solid legal ground upon which to base their PC Bridgeboard product for their Amiga computer systems.  The same could be said of A-Max, as its only vendor-produced requirement was the use of the original Macintosh BIOS in its special hardware adapter - the Mac BIOS was the only truly proprietary part of the system - and this practice was eventually deemed acceptable.  Jump forward in time to the present, where combo emulators have taken a new twist.  The modern variety frequently require the use of a BIOS dump, which is nothing more than a software image of the computer code contained within the BIOS of the original system.  Remember the A-Max bootleg?  It's the same thing, but almost a decade later.  I will reserve the discussion of the legality of this practice for another time, but will note in passing that such emulators have become widespread.  For example, Cloanto of Italy sells a package called Amiga Forever designed expressly for users of the WinUAE Amiga emulator.  Along with the emulator and other extras, it provides a legal copy of the AmigaDOS software, along with a legally licensed copy of the Amiga Kickstart ROM (the system BIOS, in other words).  True hardware-software combos are becoming more rare with each passing day due to the incredible advances in computer processing capability, and the time will no doubt come when their existence will be limited to providing emulation for highly specialized niche systems that have a minimal impact at best upon the computer industry.

EMULATION AND REVERSE ENGINEERING

     It goes without saying that a pure software-based emulator should be comprised entirely of reverse engineered code before you release it to the world.  This neatly avoids any legal claim that the original vendor can mount against you in this regard, such as what happened between Intel and AMD over the Am386 (Intel vs. AMD, 1991).  The courts have ruled time and again that reverse engineering does not void copyright protection, as it does not replicate the original's "defining algorithms."  A program written entirely in 100% reverse engineered code is therefore legal, so it stands to reason that any emulator that is 100% reverse engineered should also be legal.  The best way to do this is what is known as the "clean room" technique, in which reverse engineered code is developed on the basis of observing the actual operation of the original system and then coming up with an independently developed means of duplicating its various processes.  The legality of the "clean room" technique was validated in the famous legal dispute over the cloning of the IBM PC BIOS (IBM vs. Compaq, 1982).  The "clean room" technique is also the chief reason why Sony was unable to prevent the bleem! PlayStation emulator from going to market (Sony v. Bleem LLC, 1999), as the company had ample documentation to prove that "clean room" techniques were used in every aspect of bleem!'s design.  This has established beyond the shadow of a doubt that the legality of the "clean room" technique also applies to emulator development.  Another example you might consider is Steve Snake's KGen emulator for the Sega Genesis/MegaDrive, which was also a "clean room" product.  It proved to be such a good program that Sega eventually licensed the source code from the author for use in its commercially released Sega Smash Pack.  Talk about coming full circle!
     As a final nod to the issue of of reverse engineering, let me share something with you from a leading major industrial organization with whom I have dealt in an indirect way for many years.  One of the chief trade organizations in the electromechanical industry is the Institute of Electrical and Electronics Engineers (IEEE).  You normally hear about them whenever there is a dispute about specifications for electrical or mechanical components; they are the industry's means of regulating itself.  Here are some significant excerpts from their official policy statement regarding the concept and practice of reverse engineering which you might find interesting:

     ...We also believe that the high intellectual content of a computer product and competition are enhanced when computer products developed by one vendor are capable of operating with computer products developed by another vendor.  This compatibility promotes the development of interoperable products by independent and competing vendors and, therefore, promotes enhanced value to the vendee at a competitive price....
     We further believe that lawful reverse engineering of computer programs is fundamental to the development of programs and software-related technology....  We further believe that lawful reading, analysis, or disassembly of machine language is a reverse engineering technique by which an engineer can reconstruct the ideas of a computer program.
     Accordingly, an engineer having the right to use a copy of a computer program should be entitled, without the authorization of the author, to observe, study, and test the functioning of the program, in order to determine the ideas that underlie the program, if it is accomplished while performing any of the acts of reading, displaying, running, transmitting, receiving, or storing the program or other lawful acts involving the program that the engineer is entitled to do.
     We support the fair use rulings in the recent Appellate Court decisions in the Ninth and Federal Circuit, in Sega Enterprises vs. Accolade, 977F.2d 1510 (9th Cir. 1992) and Nintendo vs. Atari, 975F.2d 832 (Fed Cir. 1992) pertaining to disassembly of computer code.

THE PITFALLS OF EMULATION RELEASE

     Finally, the day arrives when you plan to unveil your emulator.  Whether you are a commercial company with considerable time and resources invested in your product, or you're just an extremely gifted hacker like the one described earlier, the time has come to make your creation known to world.  What happens next?  Well, that depends on two things:  who originally vended the system you are emulating, and how old that technology might be.
     There has been a growing acceptance of emulation within the computer and videogame industry; however, it is not yet universal.  Nintendo's attitude is well known and is embodied in their official emulation FAQ:

The UltraHLE [sic] is illegal.  The N64 emulator infringes Nintendo's intellectual property rights, including copyrights, and circumvents Nintendo's anti-piracy security system.

We realize there is a passionate audience of diehard Atari fans who want to keep the Jaguar system alive, and we don't want to prevent them from doing that.  We will not interfere with the efforts of software developers to create software for the Jaguar system.

Copyrights and trademarks of games are corporate assets.  If these vintage titles are available far and wide, it undermines the value of this intellectual property and adversely affects the right owner.  In addition, the assumption that the games involved are vintage or nostalgia games is incorrect.  In fact, there are now more and more programs available that emulate current game systems such as Game Boy and the Nintendo 64.

• Patent violation:  Emulation permits the bypassing of any anti-piracy protection measures, as well as unlawfully replicating other proprietary vendor processes internal to the hardware and original software of the system.  This represents a direct threat to the intellectual property rights of the original vendor.
• Copyright infringement:  Emulation promotes software piracy because users are no longer required to buy the original system, and as such represents a clear and present threat to the original vendor's profit margin.  It is also a given that users may no longer be required to obtain the system's software in its original commercial format.  Since vendors traditionally reap the most profit from software sales, this further impacts potential revenue.
• Trademark concerns.  It is a fact that emulators are never as good as the actual hardware.  This could contribute to a detrimental mindset against the original vendor, as an emulator does not accurately replicate the experience of using the original system.  As such, emulation poses a direct threat to both the corporate image and quality control of the original vendor and its affiliated licensees.

• Nintendo views any N64 emulator that either somehow invokes or includes emulation/bypass code for its proprietary anti-piracy security system (APSS) to be both patent and copyright infringement.  It violates the patents on the hardware by either emulating or invoking the internal APSS code, and it violates the copyrights on the code because any tampering with a computer security system (as Nintendo regards its APSS) is in direct violation of the DMCA.  The N64 emulator developers have contended these many months that the APSS is not an issue, since it is not required for actual program execution; however, Nintendo often adds additional copy protection and internal hardware checks to its program cartridges that are not dependent on the APSS.  Nintendo views these as an additional "security system;" therefore any emulator that can run so-called "cracked" N64 dumps is still guilty of violating the DMCA.
• Sony views any PlayStation (PSX) emulator out-of-hand as an infringing product.  It is their contention that any successful PSX emulation would unlawfully duplicate the proprietary code within the Papillon chip, which is its name for the PSX BIOS.  They were able to provide reasonable proof of this against Connectix, makers of the Virtual Game Station for the Mac, and were thus able to halt further marketing until the matter came to trial (Sony v. Connectix, 2000).  They were unable to provide such proof against Bleem LLC, makers of bleem! for IBM PC compatibles, because the company had more than enough evidence to prove "clean room" reverse engineering of the PSX BIOS (IBM v. Compaq, 1982).  The U.S. 9th Circuit Court of Appeals eventually ruled that Sony's original copyright and trademark claims were without grounds (Sony v. Connectix, 2000), so Sony has resorted to the attack it should have taken in the first place - multiple counts of patent infringement of proprietary Sony hardware.  They are also reportedly considering filing a second copyright lawsuit contending PSX security scheme violation under the terms of the DMCA as this article goes to press.
• It should also be noted that Sony initially declined an offer from Bleem LLC to market their emulator, judging it too slow and incompatible to truly replicate the PSX "product experience."  To go back in time for a moment, the problem that Apple originally had with A-Max was that it too accurately replicated the Mac "product experience" on an Amiga.  This should have come as no surprise, since the only real difference between the hardware requirements for the two systems was the Mac BIOS itself!  The Amiga had comparable hardware to the Mac (and more), so emulating the Mac was relatively easy.  The same holds true when comparing an actual Sony PSX to a 3D-accellerated, Pentium-powered IBM PC computer, although it has been a long-proven principle of emulation that a pure software approach is usually slower than working with hardware (as is the case with bleem!).

THE A-MAX TEST FOR EMULATOR LEGITIMACY

     It has taken me a lot of time, careful research, and a good deal of deliberation in order to come up with a generalized seven-point test that both the vendors and the emuscene can use to determine the legitimacy of any emulator that comes down the pike.  I call it the A-Max test, so named after the emulator that established the possibility of unauthorized legitimacy in the first place.  It works equally well for any product being emulated, from hand-held electronics to sophisticated computer and videogame systems.  I will first present the test itself, then I will explain it, and then finish up with some examples of how it can be used to determine emulator legitimacy.

1. The original system's microcode is not duplicated.
2. The original system's firmware is preserved.
3. The original system's operating system is not violated.
4. The original system's security measures are not circumvented.
5. The original system's delivery format is not discarded.
6. The original system's trademarks are not compromised.
7. The original system's economic viability is maintained.

The original system's microcode is not duplicated.

In other words, the emulator was created completely from scratch using lawful reverse engineering techniques (IBM v. Compaq, 1982; AMD v. Intel, 1991; Sony v. Bleem LLC, 1999; Sony v. Connectix, 2000).  It only emulates a select range of system functions that are absolutely necessary to achieve desired results and nothing more (Nintendo v. Atari, 1992).  This is almost always the first infringement that an offended original system vendor will claim.

The original system's firmware is preserved.

In other words, the emulator does not employ any proprietary microcode of any kind from within any part of the system hardware unless said code is licensed from the original vendor (Apple v. Franklin, 1983; Intel v. AMD, 1991; Sony v. Connectix, 2000).  If it requires some portion of proprietary microcode in order to achieve desired results, then said system code must be either licensed or retained within its original "package."  If the "package" approach is employed, then provision must be made for the emulator to interface with that "package" in its original, unaltered form (the A-Max affair of 1989; Nintendo v. Atari, 1992).

The original system's operating system is not violated.

In other words, the emulator may not be distributed with any portion of unlicensed vendor operating system code, whether that be in software form external to the system or embedded within its hardware (Apple v. Franklin, 1983; Sony v. Connectix, 2000).  This includes the original system BIOS, any patentable custom chipset unique to the original system, and any support programs designed to facilitate the proper operation of the original system, more commonly referred to as a software-based operating system.  For example, all of the early CP/M emulators included licensed copies of the actual CP/M operating system by Digital Research.  In another example, Cloanto's Amiga Forever is a commercial Amiga emulation package designed around the public domain emulator WinUAE that includes licensed copies of both the Amiga Kickstart BIOS and the AmigaDOS operating system.  Any emulator that is distributed with unauthorized copies of operating system code regardless of its origin (hardware or software) can be considered an infringing product.

The original system's security measures are not circumvented.

In other words, the emulator does not bypass, alter, or otherwise modify any technological measures incorporated into the original system, its supporting accessories, or its designed delivery format in such a manner that affects controlled access to the original program base.  The wording is taken almost directly from the DMCA (17 USC 1201) and applies to any embedded security systems contained either within the original system itself or as part of the delivery format for its program base.  Some authorities have contended that the DMCA effectively overrides the duplication of copy protected software for backup purposes as previously deemed permissible by case law (Vault v. Quaid, 1987; referring to 17 USC 117).  It is the opinion of most authorities that the DMCA complements the Vault decision rather than compromising it; to wit, you have the right to back up copy-protected software so long as you back up the copy protection scheme with it, and that is entirely in keeping with the Vault decision.  All the DMCA would do would be to make it illegal to "crack" such a scheme, as well as then removing that copy protection scheme from the program in question, thereby facilitating easier duplication and distribution.  This item will eventually pose a real problem for future emulator authors as vendors strive to design future systems in such a way so that emulating an embedded security system may become a necessity, which would place the legality of such an emulator at risk under the terms of the DMCA.

The original system's delivery format is not discarded.

In other words, the emulator must make some provision for using original copies of system software contained within their original delivery format unless its development team has obtained the proper authorization to do otherwise.  Many emulators are designed from the onset to handle one or more special program formats normally employed by developers; however, any publicly released version of that emulator (commercial or public domain) must make provision for the original program delivery format.  It does not matter one whit whether or not such a delivery format is still in use, because the courts have interpreted the ultimate right of adaptation (i.e. derivation) under copyright law, which belongs to the copyright owner, to include the intended or original delivery format (Mirage Editions v. Alberquerque ART, 1988).  This is the big problem with most "classic" videogame emulators and some "classic" computer emulators in that they do not include any provision for loading original system programs from their original delivery format.  So-called "transfer programs" or specialized hardware that converts original software to a special format are not permissible unless so authorized, and this is another problem with these kinds of emulators (Sega v. MAPHIA, 1994; Sega v. Sabella, 1995; Nintendo v. Computer & Entertainment, 1996; Nintendo v. Bung, 1999).  I note in passing that a potential "personal use" argument for derivative formats has been raised under the terms of the Betamax decision (Sony v. Universal, 1984); however, it has yet to be acknowledged by the courts.

The original system's trademarks are not compromised.

In other words, the emulator does not contain any code or data to generate any kind of registered trademark in any form in and of itself without proper authorization, nor does it contain any code or data to effect any unauthorized alteration or modification of any kind of a permanent nature to any registered trademark that might be generated by a program running on that emulator.  The practical upshot of this is that your emulator cannot generate any trademark displays that were generated by the original system hardware in and of itself (Sega v. Accolade, 1992); and while it is legal to generate the display of any embedded trademark contained within a program designed for use on that system, you may not do anything that would change or possibly block the permanence of said trademark (Playboy v. Frena, 1993).  Generating an embedded trademark is considered innocent infringement (Sega v. Accolade, 1992), but doing anything beyond displaying that trademark is in direct violation of the Landham Act, as the Sega and Frena cases clearly demonstrated.  Temporary alteration of a generated trademarked image is permissable under certain circumstances; however, permanent alteration is not (Galoob v. Nintendo, 1992)

The original system's economic viability is maintained.

In other words, the emulator does not constitute a significant threat to the current or potential market impact of the original system (Sony v. Connectix, 2000).  The concept of economic viability is a rather hazy one and is usually the second thing that an offended vendor claims with regards to a possibly infringing emulator.  It involves the notion that a given product with one or more unique selling points has only so much time on a free market to exercise its capability to bring its vendor a profit.  Once that capability vanishes, then the product is no longer profitable (Harper & Row v. Nation Enterprises, 1985).  There is no clearly defined point at which a given vendor's product economic viability disappears, and it would be foolish to try and come up with a "one-size-fits-all" approach.  This part of the A-Max test must be determined on a case-by-case basis as necessity dictates and in regards to both the particular system being emulated and the amount of time it has already spent on the market.  It can be and has been successfully argued that the older and less technologically advanced a given system has become, the more likely it is to be emulated since sufficient time has passed for any willing third party to duplicate its functions (Kewanee Oil v. Bicron, 1974).  This is probably the best guide by which to judge economic viability.

⁽¹⁾Uses original system BIOS ROMs in a legal fashion (actual chips in special adapter)
⁽²⁾  Licensing involved to clear legal hurdles

• UltraHLE 1.0.0 - There are no real issues insofare as the N64's trademarks, operating system, firmware, and internal microcode are concerned.  Almost everybody who has analyzed UltraHLE (save Nintendo, of course) is in agreement on this much.  It's the other three items where the problems arise.  The subject of whether or not this N64 emulator actually violates Nintendo's APSS is an open matter of debate that will not be resolved until the source code is made available for analysis - hence the question mark in point 4.  It doesn't matter anyway, because UltraHLE goes on to fail the two remaining parts of the test.  It will not work with N64 titles in their original delivery format, which are videogame cartridges, nor is there any provision for such; thus if fails point 5 (Mirage Editions v. Alberquerque ART, 1988).  It clearly impacted sales of N64 consoles and cartridges at the time of its release by whatever reasonable yardstick you want to use, therefore it fails point 7 (Harper & Row v. Nation Enterprises, 1985).

• PSEmu Pro - Here the situation is a little different.  This PSX emulator supports actual PSX discs, which effectively negates all of the arguments that bring down UltraHLE.  Videogame software is the true money train of any such system, therefore economic viability is not an issue.  The main problem here is its requirement of an unauthorized copy of the PSX BIOS for operational use.  Using an unauthorized BIOS dump instead of the actual BIOS compromises the original system; the item in question is a derived adaptation, not an authorized part, therefore it fails point 2 (Nintendo v. Atari, 1992; Sony v. Connectix, 2000).  The use of copyrighted BIOS code in an unauthorized manner is a violation of copyright law, therefore it fails point 3 (Apple v. Franklin, 1983).

INTROSPECTION

     Up to this point, we've talked about the basis for emulation.  We've talked about developing an emulator.  We've just finished talking about releasing an emulator.  So what conclusion can we draw about emulation in general?  Apply Occam's Razor and draw the obvious one.  As KGen author Steve Snake recently noted in an Internet message board posting, "Emulation is legal.  It's that simple and not open to debate."
     Commercial vendors can no more stop emulation than King Canute could order back the tide.  Vendors with closed minds have little chance of stemming the production and subsequent release of emulators for their systems for very long, if ever at all.  Other companies have tried to do so in the past with their systems and failed.  It is legal for original vendors to develop their own emulators.  It is legal for an independent developer to make their own emulator, provided it does not violate the original vendor's intellectual property rights.  It is legal for an independent developer to release such an emulator without the original vendor's approval, provided that it can negotiate the legal hurdles in its path.  Once those obstacles are overcome, then an independently developed unauthorized emulator has every right to be released to the general public.
     We have now come to the end of the various discussions with regards to the legality of emulation.  You should now know what is involved in developing, releasing, and possibly defending an independently developed unlicensed emulator.  Now comes one of the biggest issues of all, and it represents (as the British would say) a "sticky wicket" indeed:  "How do I support an emulator?"  That will comprise our next big area of discussion.

REVIEW QUESTIONS

1.   Why is hardware-based emulation not considered to be a problem?

2.   What particular issues do developers of emulators involving hardware-software combinations have to consider?

3.   What is the best means of development in order to produce a legal unlicensed software-based emulator?  Name two examples of such a product from the text or provide valid ones of your own.  What does the IEEE have to say about this development practice?

4.   What are two items of concern that independent developers must consider before releasing an unlicensed emulator?

5.   What are the three primary arguments that vendors use whenever they sue the developers of an unlicensed emulator?  What charges can you derive from those arguments?

6.   How can an emulator developer defend themselves against charges of intellectual property infringement by the original vendor?

7.   What is the truth behind "antipiracy security systems" in their current form?  What are some ways to deal with this issue?  Why do some emulator developers choose to ignore the problem in their products?

8.   What does the release of an emulator usually indicate with regards to the original system?  Why would this upset the original vendor?

9.   Which is easier for a emulator developer to work with - program code within the original delivery format or an alternate format?  Why?

10. How does software piracy affect the choice of delivery systems for a given vendor?  How does this impact upon the release of an emulator?

11. What was the chief mistake committed by Epsilon and RealityMan concerning the release of UltraHLE?  When is the right time for a developer to release an unlicensed emulator?  Why?

13. What causes certain vendors to become concerned whenever an emulator is released for one or more of their systems?

14. Describe the hurdles that an emulator must jump in order to be considered a legal, noninfringing product.  Why do some succeed and others do not?

15. Do you think that it is possible to release a legal third-party emulator?  Why or why not?

THOUGHTS TO PONDER

1.   If it is legal to design and then release an emulator, then is it legal to provide copies of the commercial software originally designed for use with the system being emulated?

2.   Is it legal to dump a BIOS image in order to avoid having to create an emulator that would otherwise be a combination in design?

3.   What is a "ROM?"  Is there such a thing as a "legal ROM?"

4.   Is it legal to backup computer software that was originally vended in some form of permanent storage format, such as a game cartridge or CD-ROM?

5.   Can you define the concept of fair use?  How does the concept of fair use apply to emulation?

6.   How can the Internet legally support the emulation community?