Introduction
The most common form of development contract between an independent videogame developer (“Developer”) and a game publisher (“Publisher”) in connection with any console, computer, wireless, stand-alone, or Internet platform game (“Game”) is work-made-for-hire. Under such a model, ownership of the Game and related and intermediary work product is transferred to Publisher from the moment it is first “fixed in any tangible medium of expression”[1] as a “work-made-for-hire,”[2] “specially ordered or commissioned for use as a contribution to a collective work,”[3] or as a part of an “audiovisual work.”[4]
This is consistent with the well-known model utilized in the recorded music industry. Recording contracts nearly always provide that the record company is the sole owner, as a work-made-for-hire, of master recordings containing the performances of the recording artist.
It’s not surprising that this work-made-for-hire model was adopted from the beginning for videogames. As an industry in its infancy in the late-1970s to early-1980s, videogames attracted executive talent from other entertainment industry segments, notably the recorded music industry, and those game software pioneers brought with them the business models and methods with which they were most familiar.
But videogames are not the same as recorded music. The all-in work-made-for-hire model that prevails to this day in the record industry did not work so well for game development deals. The form of agreement used for recordings proved to be a square peg trying to squeeze into a round hole. Over time, the games contracting model evolved as recognition grew of the unique ways in which games software, as an intellectual property asset, differed from master recordings.
As a result, while work-made-for-hire remains the cornerstone from which nearly every game development deal is negotiated, carve-outs from monolithic work-made-for-hire terms have emerged that provide benefits for each side in these deals.
Videogame development is an enormously complicated, enormously complex creative and technical task. Production of master recordings involves simply turning on the tape machine (or computer) and capturing the performances of the artist. Once captured, there are no technical issues in reproduction.
On the other hand, videogame production requires programming of computer software at an extremely high level of competence. Game programs are extremely complex; they are written in high level computer “languages,” take advantage of programming “tricks” to squeeze the maximum performance out of the hardware platform on which they will operate, and can take years of effort by huge teams to write. If all of this complex software code is not perfect, “bugs” or “glitches” can disrupt execution of the program. To the extent that steps can be taken to shorten the amount of costly development time it takes to create a game and to reduce the incidence and risk of bugs or glitches, it is in the best interests of both Developers and Publishers to adopt them.
When game development is on an all-in work-made-for-hire basis, where ownership of every line of code vests in the Publisher as the owner and author for copyright purposes, there is no opportunity to bring to bear previously existing proven code elements that could reduce development time and mitigate against software bugs. In such a case, in order to be an “original work of authorship” under copyright law, the software program that constitutes the videogame must be written from line 1 of computer code.
This model makes game development costlier and riskier for the Publisher. That is because it removes any opportunity for the Developer to apply its accumulated knowledge and methods. To do so could result in infringement of the last Publisher’s work-made-for-hire IP rights in its game. And each line of new code brings with it the risk of bugs or glitches and must be thoroughly tested at great cost in personnel and time.
Such a situation also makes game development a more difficult and uncertain proposition for the Developer. There are no economies to be employed in development. To the extent the Developer becomes known for its work in a genre or on a platform, it cannot build on what it has done in the past—all of its past work is the property of its past clients as work-made-for-hire.
As games became more complex and costly to produce, the industry sought ways to shortcut development time and technical risks. One result is a huge carve-out, now nearly universally applied across game development deals, in which the Developer retains ownership of certain development tools, methods, processes, technologies, and elements of the software program delivered to the Publisher. Rights to these elements, which may be integrated into and exist alongside work-made-for-hire elements of the videogame, are considered the Developer’s “toolbox” and licensed to the Publisher under terms which are the subject of this Article.
Such an accommodation means that Developers can retain, build upon, and apply aspects of their software code to each project. Using existing, bug-tested, proven code mitigates risk in software programming. It also speeds development—and, consequently, reduces cost—because the wheel no longer needs to be reinvented each time a project is undertaken.
For the Developer, retaining ownership of its code base gives value it can provide to each client in each new game and provides a tangible asset on which to build a reputation for its work.
Once Publishers and Developers understood the mutual benefit of such an arrangement, it became generally recognized and accepted in the industry.
This Article will examine the range of what may be retained by the Developer, the nature and extent of the license granted to the Publisher, and how this license appears in game development contracts.
By understanding the purpose and nature of the carve-out, counsel for both Publishers and Developers can craft language that serves the needs of their clients in speeding development and mitigating risk for the Publisher, and in building a technological base that can serve as the foundation and calling card of the Developer.
Tools and Technology: The Definition
The materials in which Developers retain ownership are commonly referred to as “Developer’s Tools and Technology” or “Developer’s Proprietary Tools” (for purposes of this Article, these will be interchangeably referred to as “Tools.”)
“Tools” is generally a defined term in a game development agreement. Because the Developer will retain ownership, it is in its interest to negotiate as broad a definition of “Tools” as possible.
Language in a first draft agreement, prepared by the Publisher, may narrowly define Tools as follows:
“Proprietary tools and utilities of Developer as they are in existence as of the date of execution of this Agreement, enumerated in the attached Exhibit [X], and utilized by Developer in connection with production of software code or assets created for the Game.”
From the Developer’s standpoint, such a definition is inadequate for at least two reasons.
First, limiting the carve-out to enumerated Tools as they exist at the time of execution of the agreement is too narrow. Tools development is an ongoing process that builds on itself. In selecting the Developer to take on its project, the Publisher expects to get the benefit of the Tools-base created by the Developer up to the point of the deal. The Developer uses its Tools as they continue to evolve, be updated and enhanced to grow as a developer. It is important for the Developer to reserve ownership of its Tools as they exist at the time of the deal, as well as any further developments, enhancement, updates, or new developments that relate to the Tools. Without a more expansive definition covering enhancements, etc., ownership of these improvements or new Tools developments could pass to the Publisher under the general work-made-for hire language in the development agreement. Future use by the Developer would be infringing on the Publisher.
The second issue to consider is the narrow description of what constitutes a Tool. The Developer and its counsel should always be asking themselves which elements from development of this Game could: (1) have value to Developer going forward; (2) enhance the technological base and game creating ability of the Developer; and (3) contribute to the reputation of the Developer. Those elements should be retained by the Developer.
The answers to those questions likely go far beyond the Developer’s tools and utilities as narrowly defined above. Over the course of development, there is code that will be written that is not game-specific and may have future value to the Developer. Steps should be taken to include such code in the definition of Tools.
For example, every Game has an “engine”—the core software code that drives the Game. An engine is the equivalent of an operating system like Windows, Linux, or Apple’s OSX, only it is specially purposed for the Game and the hardware platform on which the Game runs.
While every Game has an engine, the engine is not necessarily unique to the Game. It consists of a code base that performs functions that may be part of the Game but are also common to other games.
A well-known engine, one that is known to be reliable and powerful, can have great value to both a Publisher and a Developer. But each derives different value. For the Publisher, the engine is the proven item, a shortcut in development that saves time and money, provides reliable performance, and offers readily available features needed for the Game. For the Developer, the engine is a calling card that can help it grow its reputation among game developers, publishers, journalists, and even game players; this can lead to fame and future opportunities.
Beyond the Game engine, elements that are pre-existing in Developer’s code library or that may be developed in connection with the Game but are not specific to the Game are often included in the Developer’s definition of Tools. Such elements may include databases and data tables, physics routines, algorithms, interfaces, navigational devices, menus, menu structures or arrangements, “help” and other operational instructions, and the literal and non-literal expressions of ideas that operate, cause, create, direct, manipulate, access, or otherwise affect the Game. Any computer source code that can facilitate or implement any of these elements can be part of Tools.
Assets that the end user would recognize and identify with the Game, such as graphics, animations, original music, sound effects, and unique “signature” game play elements, are generally beyond the scope of an expanded definition of Tools.
Taking into consideration the broader scope of Tools that would be advantageous to the Developer, while not necessarily depriving the Publisher of any value in its Game, an alternative definition of “Tools” could be:
“Proprietary tools and utilities of Developer as enumerated in the attached Exhibit [X], any enhancements, modifications, extensions, redevelopments, improvements, or customizations of the foregoing that may be undertaken during development of the Game, together with the Game engine, physics and 3-D engines and routines, artificial intelligence, general purpose, non-Game-specific databases, data tables, code libraries, algorithms, interfaces, navigational devices, menus, menu structures or arrangements, “help” and other operational instructions, and the literal and non-literal expressions of ideas that operate, cause, create, direct, manipulate, access, or otherwise affect the Game, utilized by Developer in connection with production of software code or assets created for the Game, together with related source code.”
Tools and Technology: The License
Having reserved rights to its technological base, it is necessary for the Developer to grant rights to the Publisher to use this material in and in connection with the Game. Without a license and with the carve-out for the Tools, the Publisher’s rights in the Game, gained under the general work-made-for-hire provisions of the game development contract, are incomplete.
Language in a first draft work-made-for-hire game development contract, prepared by the Publisher, may broadly provide as follows:
“Developer hereby grants to Publisher and its affiliates, assigns, and successors, the nonexclusive, transferable, irrevocable, worldwide, royalty-free, fully paid right in perpetuity (with full rights to grant said rights to any third party) to use, reproduce, exploit, modify, alter, reverse engineer, integrate with other works and enhance the Tools as necessary for development, publishing, performance and display (publicly or otherwise), distribution, manufacture and sale of the Game and any other game(s) developed by or for Publisher, including all versions, expansion packs, add-ons, updates, ports, sequels, prequels and other derivative works thereto, and any and all corrections, revisions, and/or updates thereof.”
Such a grant of rights dovetails with the work-made-for-hire provisions that control the other elements of the Game. This broad grant permits the Publisher to exercise virtually unrestricted control of the Game and to revise, extend, expand, alter, and otherwise change the Game as it determines in its exploitation. It also permits use of the Tools in connection with future endeavors in games, whether connected to this Game or not. Such broad rights are fully consistent with the rights obtained in the remainder of the Game pursuant to the work-made-for-hire provisions of the game development agreement.
From the Developer’s perspective, however, this broad grant goes beyond what is necessary or appropriate. The Developer’s Tools remain the property of the Developer; the Tools are a valuable, confidential, and unique asset and the Developer does not want to lose control of its technology base.
In determining the extent of a grant of rights in a Tools license, the Developer and its counsel may want to consider the following:
- What is the extent of rights Developer would grant Publisher in connection with use of Tools beyond their integration into the Game?
- Under what circumstances, if any, would Developer permit Publisher to provide Tools to third parties?
- Would Developer permit Publisher or any permitted third party to modify Tools? If so, who owns the modifications?
- Would Developer permit uncompensated use of Tools by Publisher in connection with further products, whether add-ons, extensions, or expansions of the subject Game, other derivative works, or other games?
- Would Developer deliver Tools as part of a milestone delivery, escrow, or archival milestone in source code form?
The narrowest license that may be provided to the Publisher in connection with Tools could read as follows:
“Developer hereby grants to Publisher the nonexclusive, worldwide, royalty-free, fully paid right and license to use, reproduce, and exploit the Tools, in binary (object) code form only, and only as they are integrated into and made part of the Game.”
This grant provides the means to bring the Game to market, but may limit the Publisher’s ability to further develop and exploit the product by way of add-ons, additional—sometimes downloadable—content, ports to other hardware platforms, and perhaps further localizations to other languages and cultures. By the Developer providing Tools only in binary form, and only in the fragmentary manner in which they may appear in the Game, the Publisher is severely limited in its ability to reuse or modify them.
The Developer may be willing to broaden the rights it grants to use Tools, but such concessions may be tied to agreements related to the Publisher’s continued use of the Developer to create the further work.
A threshold issue for the Developer in weighing the breadth of rights it is willing to grant in its Tools, and the path such negotiations may take, is how strongly the Developer determines it must maintain the Tools’ confidentiality.
If the Tools are a general set of utilities but not otherwise unique or extraordinary, the Developer’s threshold may be lower. But if the Tools represent a major technological investment by the Developer—the “family jewels” so to speak—, are unique or extraordinary in the games industry, and provide a clear and important technological advantage over game development competitors, the Tools may be treated as a trade secret and the Developer may not be willing to grant access under any circumstances. Here, the only path to further access to the Tools would be for the Publisher to engage the Developer to do further work.
If the Developer would consent to the Publisher providing its Tools to a third party, that consent may be conditioned on the third party signing a confidentiality agreement binding itself and its employees. The Developer would want to be recognized as a third party beneficiary of that agreement and may seek to hold the Publisher liable for any default by the third party.
Before permitting disclosure of the Tools to a third party developer, the Developer and Publisher may agree to some sort of first right of negotiation between them in which the Developer could become the developer of further Game elements or content. Only after the parties were not able to come to an agreement would the Publisher be able to provide Tools to a third party developer undertaking the project.
An example of such language could be as follows:
“The Tools are Confidential Information of Developer and will not be disclosed by Publisher to any third party, or used for any purpose other than as expressly set forth herein. In the event Publisher desires any add-on, port, or other content (“Additional Content”) to be developed to further exploit the Game, it will first notify Developer and the parties will negotiate in good faith for a period of not less than thirty (30) days in an attempt to settle material terms of an agreement under which Developer would develop the Additional Content. If the parties reach agreement, they will continue to negotiate an agreement using the terms set forth herein as the basis. In the event the parties are not able to come to agreement, Publisher may negotiate with any third party, provided, however, that it will not enter into any agreement with any third party on terms more favorable to the third party than those terms last offered to Developer. In the event Publisher enters into such an agreement with a third party, the license granted to Publisher herein in connection with Developer’s Tools will be extended to permit access to Tools by the third party and use of the Tools by the third party, but only in connection with development of the Additional Content. No Tools will be provided to the third party until the third party first executes a Confidentiality Agreement in a form reasonably acceptable to Developer under which the third party agrees not to disclose the Tools or use them for any purpose other than development of Additional Content. Developer will be identified as a third party beneficiary of the Confidentiality Agreement. Publisher will be liable for any default by the third party or any of its employees of the Confidentiality Agreement.”
Some Publishers seek rights to use Tools in sequel or prequel games, or going further, in any future games of the Publisher. The Developer must determine whether it is prepared to grant such broad rights under any circumstances. When the Developer is willing, the grant may be tied, as above, to a first right of negotiation to be the developer of the later work. When such an agreement cannot be reached (for example, when economic terms can’t be reached, or when the Developer is booked with other projects), it may still be willing to extend the license to Tools in exchange for a license fee. Both flat fee and royalty participation in the new projects are common.
Generally, when the Developer is paid for use of Tools in games the Developer does not produce, some level of general support for the Tools is negotiated as part of the license. In such a situation, the Developer will have to make its confidential source code available to the Publisher or the third party developer.
Tools and Technology: The Restrictive Covenant
When the Developer is successful in reserving rights to its Tools, the Publisher may raise a legitimate concern about how the Developer will exploit its rights and property going forward.
From the Publisher’s point-of-view, it has paid the Developer to enhance the Tools and received the benefit in the form of its Game, but the Publisher does not want to see these newly enhanced Tools applied to a game that could be in competition with the Game.
Videogames are a tough, competitive business. To the extent a Publisher has invested in a product, it does not want to find itself competing with another similar game created using the Tools that the Publisher paid to enhance! The Developer, however, has built a reputation for working in a genre and does not want to be unduly restricted from building on its reputation and successes.
The generally accepted solution is a restrictive covenant imposed on the Developer. These covenants, or “non-competes,” have both horizontal and vertical elements; each of which is subject to negotiation.
A typical first draft restrictive covenant in a Publisher-prepared agreement may read as follows:
“Developer agrees, as a material term of this Agreement, that it will not, for a period of three (3) years from the date of first commercial release of the Game, engage in, assist, facilitate, or provide resources, directly or indirectly, in connection with the design, development, or release of a Directly Competing Game. As used herein, ‘Directly Competing Game’ means any interactive game in the first person shooter genre.”
Such a limitation can give the Publisher much comfort, but it can shut the Developer out of the business segment in which it has had the most success and in which it is best known.
The goal of a restrictive covenant should be to give the Publisher a reasonable window to establish its game, so the public can decide whether it is a hit.
The period of time in which the Developer is restricted is the horizontal element of the covenant. A period of no longer than one year should be enough to accomplish the Publisher’s objective. The Developer should also resist starting the clock from release of the Game—a date totally out of its control. As an alternative, the restriction period may be set to run from the date on which the Developer delivers and the Publisher accepts, the final “gold master” Milestone.
In restricting the Developer from “design, development, or release of a Directly Competing Game,” the period of exclusivity afforded to the Publisher is actually closer to five years than three. That is because development of games can take a very long time. If the Developer cannot even begin this work until the restricted period ends, it will not be able to bring the new work to market for years after.
A better alternative here for Developer is to delete “design” and “development” and limit the restriction to “release.” This permits the Developer to work on a future game, but requires the Developer to withhold it from the market—and competition with the Publisher’s Game—until the end of the time period set forth in the covenant.
The definition of Directly Competing Game is the vertical restriction in the covenant. The Developer’s counsel should take steps to define the “Directly Competing Game” as narrowly as possible. For example, the restriction might be limited to games that operate on the same hardware platform as the Game that is the subject of the covenant; there could be more qualifying language than simply identifying the genre.
An alternative clause that takes into account narrowing of both the horizontal and vertical restrictions might be this:
“Developer agrees, as a material term of this Agreement that it will not, for a period of one (1) year from the date in which the gold master deliverable is accepted by Publisher, release into commercial distribution any Directly Competing Game. As used herein, ‘Directly Competing Game’ means any interactive game that operates on the Microsoft Xbox 360 hardware platform, and has an M rating, in the first person shooter genre that is set on a planet at war in the future and features humanoids and war machines engaged in combat.”
Conclusion
While ownership and control of every line of software code may be superficially attractive to game Publishers, it can also be costly and inefficient—two conditions that may be deadly in today’s highly competitive games market.
By working together with its chosen Developer, who was certainly selected because of its experience and abilities with similar types of games, a Publisher can take advantage of the pre-existing code base to short-cut game development and the Developer can continue to develop and refine its core technology while developing its game for the Publisher.
Such an arrangement is win-win. Licensing of Tools provides a key for both sides to achieve important objectives in their game development deals.
# # #
Jim Charne is a California, New York, and New Jersey lawyer who has provided legal representation for clients in all phases of the computer software and videogame industry since the mid-1980s.
Jim has been chair of the Legal and Business tutorial at the annual Game Developers Conference (gdconf.com) since 1998; serves as chair of the volunteer lawyers committee that wrote the three releases of the International Game Developers Association (“IGDA”) Business Committee “Contract Walk-Through” (found at www.igda.org); is a program moderator and speaker for the Practicing Law Institute (www.pli.edu) on games industry topics; and writes "Famous Last Words," a long-running monthly column on games contracting and legal issues at www.igda.org/columns/famous-last-words.
Jim has been recognized as a Most Valuable Player by the IGDA and honored three times by the Game Audio Network Guild (audiogang.org) for his work on behalf of composers and licensors of music in the videogame field.
Jim is a member of the California State Bar Association; the Beverly Hills Bar Association; Santa Monica Bar Association; New York County Lawyers Association; various trade and professional groups in the videogame, music, and general entertainment industry; and is a past president of the Academy of Interactive Arts and Sciences (interactive.org).
[1] 17 U.S.C. § 102(a) (2012).
[2] § 101.
[3] Id.
[4] Id.