Tag Archive for Intellectual Property

Reverse Engineering and You

January 9, 2010 Contracts, Intellectual Property, Litigation No comments

Let’s start with a story:

Mallory the Mythical developer and two of her good buddies are big fans of “Katarina’s Conquest”, a FPS loosely based on the Bolshevik Revolution of 1917.The game incorporates modern weaponry in a historical, beautiful, and immersive environment. Unfortunately when the game was released the original developers, October Industries, didn’t expect the game to achieve such a high level of success; the servers are unable to handle the number of new users and haven’t stayed up for more than 3 hours at a time since launch.

In response to this issue Mallory and her two good buddies decide to host a private server where they can play the game with a handful of friends across the globe without worrying about the server shutting down. To do this they will have to use reverse engineering to translate the game’s network protocol so their game clients can communicate with the new server. Mallory, being an experienced and business savvy developer, immediately realizes that there may be some legal problems here.

Mallory is right—reverse engineering can be a risky endeavor and shouldn’t be attempted without first consulting an attorney. Below I’ll discuss what reverse engineering is and how it’s accomplished and, more importantly, when reverse engineering will put you and your development team at risk.

What is Reverse Engineering?

Legally speaking, the reverse engineering of computer software is any method of studying a program for the purpose of obtaining useful and detailed information about the functional components and mechanisms of the program in question. The Supreme Court defined it as a “fair and honest means… [of] starting with the known product and working backward to divine the process which aided in its development or manufacture.” This can be as simple as observing game play to determine the functional elements of the game’s rule set, or as complex as decompiling a file and analyzing its components to learn how ads are displayed across the game server.

Tools used to reverse engineer a game include debuggers, disassemblers, and network protocol analyzers (packet sniffers) to name a few. The essential function of these tools is to give the programmer access to data that reveals the precise functions and mechanics of a program so those functions and mechanics can be reproduced with minimal or no use of the original source or binary code.  

Traditionally this method of learning functions and processes has been viewed as fair game and, indeed, to some extent is still protected under fair use. As a result inventors in the field of technology and software have relied on reverse engineering for decades. For example, while the Copyright Act protects the three-dimensional patterns and designs of a microchip, it expressly allows the reverse engineering of those patterns and designs (referred to by the Act as a “mask work”) to analyze the concepts or techniques embodied in the chip. Similarly many courts have found that analyzing a computer program for the sole purpose of learning and reproducing its precise functions (provided those functions are not otherwise protected under patent law) is typically fair use.

This does not, however, mean that all reverse engineering is treated equally under the law. In software and games in particular the practice of reverse engineering has been under assault for a while.

Copyright and the DMCA Anti-Circumvention Act

Machine code and source code are protected as literary work under the Copyright Act. The copying of either without permission is copyright infringement. Using any part of someone else’s code in your own project, particularly non-functional code, without permission will almost certainly make you an infringer.

Sometimes during the process of reverse engineering the programmer may want to copy a data file or the entire program; typically that type of copying isn’t permitted under the Copyright Act, although there are a few very limited exceptions for backing up files for a legal purpose (such as repairing or debugging a lawfully owned program so the program can function).

Yet Copyright Act’s protection of computer programs goes well beyond the question of whether you’ve copied anything. In fact you don’t need to copy one iota of code to run afoul of U.S. Copyright law. 17 U.S.C. 1201, the Anti-circumvention provision of the DMCA, prohibits the circumvention of any technological measures that control access to any part of the work. It also prevents the distribution of software that enables circumvention of an access control.

 Circumvention under the Act means descrambling or decrypting a work, or otherwise bypassing, removing, deactivating or impairing any technological measure without permission. A few classic examples of technological measures: remember those old Sierra games that required you to input a word from a specific paragraph on a specific page of the user manual before you could play the game? That’s an access control. Data file encryption is a more specific application of an access control. CD Key and license key encryption are another classic and oft-used example. Circumventing key encryption to access the content is typically illegal under the DMCA—but that isn’t the only scenario where a programmer could find himself in hot water under the Copyright Act.

This is particularly relevant in Mallory the Mythical developer’s case; if Mallory’s new server doesn’t provide the safe guards used to control access to the original game servers, such as a CD-key or version verification protocol, her own server is circumventing access controls to the online component of the game; by distributing the program, means (such as DIY instructions), or code to access servers that don’t use the game’s original access controls she would be running afoul of the anti-circumvention provision. According to at least one court decision this is sufficient to constitute a breach of 17 U.S.C. 1201.

Note that this does not mean that all aspects of reverse engineering are prohibited under the DMCA— for instance, analyzing un-encrypted machine code in order translate those processes and functions to source code is generally permissible. However, because the definition of “circumvention” is so broad under the act it is important to be mindful of any encrypted or otherwise protected data contained in a program or program file when you are attempting to lawfully reverse engineer a process or function.

There is one major exception to the DMCA: bypassing or decrypting encrypted data files of a legally owned copy of a program for the sole purpose of making that program interoperable with other legal software (for instance, a different operating system) is expressly permitted under the DMCA. However, this does not mean that you can distribute a way to bypass a CD-key or other cracking or decrypting software to make that software playable. This is why most interoperability projects, such as ScummVM, require end users to legally own the games they make playable. They cannot legally provide a means of playing cracked games, even if the primary purpose of the project is interoperability. Interoperability must be the only purpose.

It is important to note here that this exception can be waived if you agree to an EULA that prohibits reverse engineering.

Contractual Safeguards

A less confusing but no less treacherous risk comes from EULAs, NDAs, and other agreements or contracts a programmer might subject themselves to when they legally license the software they want to reverse engineer. For years courts in a variety of cases have upheld contract provisions that limit the end user’s right to reverse engineer a program for any purpose. Click-wrap and shrink-wrap agreements are generally considered enforceable.

For instance, if Katarina’s Conquest includes an EULA that expressly prohibits reverse engineering and Mallory the Mythical Developer has clicked the “I Accept” button when installing the program, Mallory would likely want to shelve her hopes of creating a private server by reverse engineering the client. A programmer can be liable for breach of contract and a slew of other causes of action, including misappropriation of trade secrets, by violating the EULA.

You can’t legally circumvent the EULA for a few of reasons. If it’s a shrink-wrap agreement you’ve accepted once you’ve purchased the software. If you didn’t legally purchase the software you don’t own a legal copy. In the case of click-wrap agreements, your legal use of the program is dependent on accepting that agreement. If you don’t accept you don’t have a license to use the software. Second, the EULA’s “click-wrap” process is an access control in and of itself. Bypassing that access control so you don’t have to agree to the license has a purpose beyond interoperability that doesn’t fall under the DMCA exception.

Pay close attention to the EULA of any game or program you want to reverse engineer. Even if you hope to reverse engineer the program for legal purposes you would still be prohibited if you’ve accepted the EULA’s terms in any manner—this includes purchasing a product with a shrink wrap license or clicking the “I Accept” button during the installation process.

Privacy Rights

In almost all cases of reverse engineering of a game the only network communications Mallory the Mythical Developer can or would want to monitor are her own client’s communications with the game server. This typically won’t raise many legal issues, and in almost all cases it would be impossible to virtually “sit in the middle” and monitor an encrypted communication between a game client and a game server. That’s what the encryption is designed to prevent. However, if you’re working on the kind of project where inspecting network packets that aren’t yours come into play you should be aware of a couple of laws.

The first is the Electronic Communications Privacy Act, which is part of the Wiretap Act, (18 U.S.C. 2510 et. Seq.). Under the ECPA you can’t intercept electronic communications, which includes data packets or any other transfer of information between a client and a network provider, server, or other computer or system, while that data is en route on a network unless you’re the network provider or an official (police or other government agency) authorized to access that information for investigative purposes under the Act.

The second is the Stored Communications Act (18 U.S.C. 2701 et. Seq. ). This Act is designed to prevent unauthorized access to ISPs and network service providers that allow the transfer of private electronic communications; accessing the data temporarily stored at those points without authorization, or otherwise exceeding your authorization and obtaining data you shouldn’t have access to, can expose you to criminal liability under this Act.

Both of these laws are designed to prevent you from accessing private communications, including data packets sent over a network or temporarily stored on a network. For this reason alone, reverse engineering projects that require monitoring communications you don’t have permission to observe or analyze should be avoided.

Conclusion

Reverse engineering isn’t inherently illegal. However, it does implicate a variety of legal issues. This isn’t the type of project you want to pursue if you’re risk avoidant; after all, reverse engineering is traditionally done for the purpose of recreating the useful functions of someone else’s work. That alone is typically enough to get more attention from content owners than you may want or need.

However, you can mitigate your risk by contacting an attorney and learning the steps you need to take to protect yourself and your project.

IP Enforcement for Independent Game Developers

December 4, 2009 Contracts, Intellectual Property, Litigation One comment

This issue has a lot of angles and typically two or more sides to each story. On the one hand you have the enforcer, or anyone who owns original IP. An example of the stereotypical enforcer includes Microsoft, who put a complete stop to the independent development of a Command and Conquer “HaloGen” mod that employed Halo’s intellectual property, developed by a small studio called Slipstream. MS subsequently went on to have Ensemble develop Halo Wars, which is, you guessed it, a Halo RTS. Another philosophically controversial “enforcer” example is Apple, who has worked continuously to enforce its EULA against the owners of jailbroken iPhones.

At the other side of this debate is the alleged infringer, which could be an indie like Slipstream or, more problematically, the crackers and black hats who hack DRM and pirate games in a manner that damages the entire industry. This is, in fact, one of the biggest problems arising from jailbroken iPhones; it has rapidly become a problem that creates constant strain in the application and casual game markets.

Regardless of your personal philosophy concerning the identity of the enforcer or the infringer, IP enforcement is an important aspect of protecting what you create. It’s as important in commercial works as it is in open source projects even though the ideals behind enforcement may differ. The issue here is control and access, and who has that control and access. Without this article will explain intellectual property enforcement methodology without touching on personal philosophy or the identity of the infringer or enforcer. It is my belief that it is just as important for independent developers to protect their IP as it is for the majors, and as such the tools for enforcement should be available to all.

Getting it in Writing

Contracts such as EULAs, licenses, and employment agreements are the first line of defense in IP enforcement. The more clearly your contracts set out your intellectual property rights and your remedies in the event of infringement or breach, the more likely the people you contract with are to comply. This is particularly true with regard to proprietary technology, trade secrets, and ideas you want to keep confidential.

Identifying Intellectual Property. The first step in protecting your IP is identifying what you consider protected under the shield of the contract. In the case of employment agreements and NDAs you need to be as specific as possible with regard to trade secrets and proprietary technology. With regard to EULAs you need to identify all components of what you want to protect, including content you’ve licensed from third parties. One example of how this can be done* is demonstrated in the World of Warcraft EULA, which identifies IP in two places: it sets out the game, patches, and manuals in the introduction, and expounds on those basics in the “Ownership” section further down.

Identifying Permissible Use of Intellectual Property. The next step in protecting your IP via contract is clearly stating what the licensor/end user/employee CAN do. Explain what is permissible: in the case of your game’s EULA, explain what users can do with your software; in the case of your employee agreements, explain how and when employees may access or use information; in the case of non-disclosures and confidentiality agreements, explain who information may be disclosed to or when confidentiality may be waived.

Identifying Impermissible/Infringing Use of Intellectual Property. Once you’ve explained what people CAN do with your IP, you need to explain what they can’t do. For example, in the case of games, computer programs, and hardware, one major issue of contention is reverse engineering. Under the Copyright Act reverse engineering is generally (but be careful, because this is a devilishly tricky area of the law) permissible if it is done exclusively for the purpose of interoperability. However, you may not want your game or software to work on jailbroken iPhones or other gaming devices that you plan on porting to down the road. This is something that may arguably (although this is by no means settled law) be limited by the EULA. Most major content owners seem to think so. If it’s something you deem necessary to protect your future interests, you should consider including it.

Identify Remedies and Damages. This is where you let the people you’re contracting with know what they risk if they infringe or impermissibly use your IP. You should include all available equitable remedies (remedies not grounded in monetary damages), including injunctions and restraining orders, as well as statutory and actual damages or profits resulting from infringement.

DRM and Keeping Secrets. If you’re using DRM technology, you need to let people know that you’re using it. You also need to explain that the disruption or removal of that DRM will expose them to additional Copyright Act liability if they choose to crack it. In the case of employment agreements, if you’re trying to protect trade secrets you must take steps to keep information secret. This includes DRM, password protection, encryption, and making it clear to employees that disclosing that information to anyone outside of their department is a big No No.

Cracking Skulls

There’s always a possibility that someone will breach your contractual provisions, or your game will be cracked and pirated, or you’ll find an inferior clone that passes itself off as the original. You will be angry and you will want to do everything you can to stop this from happening. First, calm down. Immediately calling a lawyer and filing a complaint or otherwise throwing a fit is expensive and probably bad for your health and peace of mind. Next, evaluate the validity of your claim. Do you have a claim? Is it really infringement? Would you know if it weren’t? For example, if the product is similar or identical to your own but released prior to or very shortly after your own, there’s a strong presumption of independent creation (which isn’t infringement under Copyright Law). You may want to talk to an attorney before going further. Take a deep breath and review the suggestions below, from most cost efficient to least. In some cases you may want to skip the first option, but as you’re an independent developer you may garner more sympathy from other small collectives, pirates, or studios who are (perhaps unwittingly) infringing on your rights.

Contact the people directly. A polite phone call or casual e-mail as a first step can go a long way in preventing future ill will or the need to lawyer up. If the infringer isn’t aware that the material is infringing or if they don’t understand the basics of IP law, they may comply with a friendly request without any further cost to you. This isn’t always the case, but as I said above, you’re an indie. There’s camaraderie among your fellow compatriots and there’s nothing wrong with taking advantage of that good will to protect your IP.

Send a Cease & Desist. If the first approach is unrealistic or ineffective the next option is a more formal C&D. This should typically come from a lawyer, but if you’re still trying to avoid the need to lawyer up you will want to at least include the following:

  • An introduction that sets out your name, your product, and where your product can be found;
  • A description of the rights you hold in the work, including any music, artwork, engines or code you’ve exclusively licensed;
  • A description of their work, and how it is infringing;
  • A citation of the laws being infringed, including Copyright law, Copyright Circumvention laws, trademark and unfair competition;
  • A list of actions that they must cease and desist;
  • A request for damages, if relevant;
  • A “respond to by” date;
  • Your preferred contact method.

Before you go any further. Have you registered your work/trademark? Under U.S. law you can’t bring an action for copyright infringement against anyone until you’ve filed your application, paid your fee and submitted your deposit. In the case of trademark, monetary damages including profits aren’t available unless your mark is registered and you’ve included the ® symbol or some other notice of registration. The sooner you register the better. Under Copyright law you’re entitled to statutory damages so long as the infringement occurred after you’ve fully completed your application and submitted your fee/deposit, or within three months of the infringement. Since the minimum statutory award is $750 for each infringement registration really shouldn’t be put off. In fact you should make it a policy to register as soon as you complete a project and have something to submit to the copyright office.

Send Takedown Notices. Send takedown notices wherever you find your infringed work. Bear in mind that the DMCA safe harbor only applies to those sites with a registered DMCA agent. If the site or service provider doesn’t have an agent you may want to instead send another C&D explaining why they are also infringers.

File a Complaint. This is certainly the point of no return. If you haven’t lawyered up yet, do so now. If your C&Ds have gone ignored or the infringer has sent a put back up notice in response to your take down, the only way to get that infringing material taken down again is to file a complaint and send a copy of that complaint with a second take down notice. Most websites with DMCA provisions will explain that process in their EULA. You will likely be filing your complaint in federal court and you will want to include every possible cause of action available, including all possible state claims.

At this point the conflict could take a few turns. If this catches the infringer’s attention, you can try to achieve settlement quickly or use some of the mediation or arbitration techniques described previously. It’s typically at this point that enforcement gets pricy and time consuming, but it may be a necessary step to protect your rights.

*  Direct copying from any document including EULAs and other contracts without permission from the original drafter or document owner is typically considered copyright infringement. Draft your own or hire an attorney to draft it for you.

Clone Games and Fan Games: Legal Issues

November 20, 2009 Game Development, Intellectual Property No comments

There are a few misconceptions in the indie development community concerning the definition and legality of clone games. Some take it as given that a legal clone can be a fan game including many of the same visual and sound elements as the original. Others believe that because some game companies don’t enforce their IP rights against fan game developers all fan games must be legal. Some may even believe that a game is simple and general enough to not warrant IP protection. This entry is designed to dispel some of the confusion and inaccuracy surrounding clone games and fan games.

Let’s say you’re a huge fan of Zelda, you’re a programmer and competent indie developer, and you and your friends want to create a tribute game to the world of the Hylian race, Princess Zelda, Ganon, and, of course, Link. In your game you will likely create something akin to fan fiction as far as your storyline and script, and you want to implement the same characters in some way because you are, like most of us, somewhat attached to those icons. Obviously you want to use similar game rules and mechanics. Can you? Should you? What legal complications will arise, what risks are involved, and how can you avoid threats from the very entity to intend to honor?

Defining a “Clone”

According to Wiki a video game “clone” is a game that is “very similar” to or “heavily inspired” by another game. This is woefully vague from a legal perspective. A “legal” clone is one that does little more than implement unpatented game mechanics, rules, operations, and physics. Some “ideas” for games may also fall into the legal clone category for the simple reason that they are so common or vague that they no longer warrant copyright protection as unique expressions—for instance, a platformer or RPG with a male protagonist seeking a kidnapped princess is so common to the genre as to constitute scènes à faire under Copyright law.  On the other hand an illegal clone relies heavily on the creative content of a game—namely the trademarks and trade dress of a game product, as well as the unique audiovisual and scripted elements of that game. Note that game clones containing patented mechanics may also run afoul of intellectual property law.

Layers of Protection

Games aren’t all about code. Just because you wrote your clone or fan game from scratch does not guarantee that it is legal. The intellectual property contained in a video game is truly vast. For instance the copyrights alone may include (but are by no means limited to):

  • Audiovisual display
  • Sound recordings
  • Voice recordings
  • Script
  • Screenplay
  • Background drawings
  • Sprite drawings
  • Musical compositions
  • Source Code
  • Object Code

Furthermore you have trademark, trade dress and unfair competition claims in the original work to worry about, including:

  • Game name
  • Company name
  • Character names
  • Character appearance and clothing
  • The game’s look and feel
  • game packaging

And last but not least you may even have some random claims out of left field by game actors/SAG members, including:

  • Name and likeness
  • Defamation
  • Privacy rights

If you use any of this in your “clone” game, you may draw unwanted attention and create a legal risk for yourself. The Tetris Company has relied on several of the above-mentioned rights, including “look and feel” under both trademark and copyright law, to enforce IP rights against games that closely resemble its product. Furthermore the risk of legal action isn’t limited to clones of video game products. Creating a video game clone of board games, card games, and the like could create just as many problems. One famous example is the suit brought by Hasbro against the developers of Scrabulous, a well-known Facebook application.

As far as programming and code goes, commonplace commands are exceptions to the general rule of copyright protection. This is notable only because the most frequent argument I’ll hear concerning a person’s clone or fan game is that the “code is different” or that they “created the game from scratch”. Unfortunately the law doesn’t really care and is not on your side here if you relied on or used any of the other elements noted above. Even if you create the images, sound recordings, etc. from scratch, if those same components are clearly derived or ripped off from the original game, all your hard work may mean absolutely nothing from a legal perspective.

Protecting your Clone/Fan Game

You have a few choices here:

1. Make a “legal” clone. Rely on unprotected game elements, mechanics and processes that are so common and prolific in the game industry as to no longer warrant protection, copyright, patent or otherwise. If you’re unsure whether your particular idea falls into that category, contact an attorney.

2. Ask permission. Yes, this does put you on the owner’s “radar”, but show some respect. If you’re making a clone or fan game, at least be sincere about it—obviously you enjoy the game, so show some respect to the game’s creators and publishers and inform them of what you want to do. If they say yes, you have carte blanche right to use whatever you’ve told them you wanted to use in your product. If they don’t respond, you have a good faith laches/waiver defense. In English this means that the company/publisher has waited, with knowledge of the fact that the infringement was going to happen, until you’d already put yourself past the point of no return as far as production and distribution, before acting. Generally this conduct is frowned upon by the Court and is therefore treated as a “waiver”; otherwise the Court will honor your laches defense—this is especially true if notice to the company came in the form of a request for permission.

If the company says no, you’ve probably chosen the wrong IP to clone.

3. Come up with your own game. This is probably the best approach. If another game has inspired you, that is a wonderful thing. Let that propel your own creativity and make something unique that is truly worth playing.

« Older Entries   Recent Entries »