If you find this article contains errors or problems rendering it unreadable (missing images or files, mangled code, improper text formatting, etc) please contact the editor so corrections can be made. Thank you for helping us improve this resource
The vast majority of the work I do for developers involves contracts - reviewing proposed contracts, analyzing contracts, discussing contracts, drafting contracts, negotiating contracts and, sometimes, litigating contracts. All sorts of contracts - contracts for leases, licenses, publishing, distribution, employment, termination, confidentiality, non disclosure, non circumvention, consulting, development, buy outs, asset sales, asset purchases, stock sales, IP transfers...like I said, all sorts of contracts. Contracts are at the core of most of the good and the bad stuff that goes with running a successful studio. A significant part of the time I spend on these agreements is with clients helping them understand what different contract provisions mean and their potential impact on the deal and the studio might be. So, I though it might be good to provide a little basic ôContracts 101" for developers to provide a little insight into the basic elements of any contract to help demystify them a little.
A contract is basically an agreement between two or more parties. It can be to do or to not do something and sets out the duties and responsibilities of each to the other. It is the common agreement between the parties, what is referred to as the ômeeting of the mindsö that establishes the contract. Once this ômeeting of the mindsö occurs, the contract is formed. In general, oral contracts are just as valid and enforceable as written ones, though certain types of contracts must be written. The term ôhang shakeö agreement reflects the tradition of confirming the ômeeting of the mindsö by the mutual acknowledgment by the parties by the parties shaking hands to seal the deal. At the core of every argument is this acknowledgment, though we usually see it in the form of a signature on the bottom line.
ôConsiderationö is a term used by lawyers to describe the subject matter of the contract. By that I mean whatever of value that is being delivered or exchanged. The dollar for the candy bar or money for the source code are the easiest examples. It is basically what the contract is really about and is a necessary part of any contract. Without mutual ôconsiderationö itÆs not really a contract, itÆs a gift and as such may not be enforceable. Finally, the parties to the contract also must have the legal capacity to enter into the agreement. That means that they are competent to know what they are getting into. This goes back to the whole ômeeting of the mindsö thing...no mind, no meeting.
Evolution and Iteration
ThatÆs it. Pretty simple huh? So, how do we end up with a 24 page written publishing contract with over 200 pages of attachments? No, itÆs not just because all of us lawyers are out here making things more complicated in order to make a living off of all your hard work. Well, maybe some of it is...but the real reason is that most industry business relationships are complicated and not merely a simple bargained for exchange of goods for dollars. Even the basic employer/employee relationships often involve multiple issues that ought to be considered and resolved in advance. This is especially true in an industry based on intellectual property like ours. And since these are not simple purchase and sale agreements, the relationships that most industry contract addresses are ongoing over time and involve numerous mutual duties and obligations.
In effect, they describe the parameters for these ongoing business relationships ands attempt to account for all of the foreseeable issues that may arise so that the partiesÆ expectations are met and there is a minimum of unknown risk throughout the relationship. We have all heard stories of the early days in the industry when a publisher would give several million dollars to a developer along with the simple directive, ôMake us some cool games.ö Now thereÆs a publisher contact any developer can live with. Unfortunately, those days are gone. And we all know why. Unforeseen events occurred in the course of the performance of these contracts and just like the way a game design iterates over time, the contracts in our industry have iterated as well. It is probably just a natural part of the maturation process of our industry.
Things to Watch
The problem for developers is that most of the folks we do business with, especially publishers, have just done so many more deals that developers do. That means that they have been able to address more problem issues that negatively affect them in these deals. However, they have not addressed the issues that have negatively affected developers. Why should they, thatÆs not their job. ThatÆs your job, or mine. For example, contract provisions addressing what happens if the developer goes into bankruptcy or receivership are in every contract. What happens if the publisher goes under is never addressed. Publishers go out of business all the time. And no business person should want to get tied up in a bankruptcy proceeding, especially someone elseÆs. ItÆs always a good idea to shoot for mutuality throughout these various contract provisions. After all, ôwhatÆs sauce for the goose is sauce for the gander.ö
It is also important to realize that these complex ongoing contracts are not static. They represent the agreement regarding the ongoing relationship between the parties and just as things changed in the industry over time, thing change in any individual working relationship over time as well. The business relationship is an organic one that by necessity adapts to changes. Unfortunately, most written agreements are static and do not account for these changes. Keep in mind that even after the contract is signed, the deal is not done. The deal is just starting. Make sure that at the end of the relationship the contract accurately reflects that actual relationship, not the one you planned at the beginning. And since virtually all of these written contracts can not be modified by an oral agreement, make sure this gets done by memorializing any significant changes in the performance of the contract through written addenda signed by both parties.
Everyone has to deal with contracts, both inside and outside of our jobs. Try to keep the basic elements in mind any time you make an agreement. Cowboy up and accept responsibility for making sure that you understand what you are getting into. DonÆt get so involved in performance that you forget to keep the terms of the contract in mind throughout the entire term of the agreement. Ultimately, there is no such thing as a good contract with a dishonest person, or a bad contract with an honest one. But even in the best situations, things come up that need to be dealt with. The more forethought you put into the process in the beginning and the more vigilant you are throughout the performance, the better off youÆll be.
[Tom Buscaglia, The Game Attorney, writes frequently on subjects of interest to game developers. The above article is for the information and education of members of the development community. Feel free to distribute or disseminate this article. But please include the legend "Copyright 200_, Thomas H. Buscaglia, Esquire" and an active link to in each article posted or published elsewhere. The sale or any other commercial exploitation of this article, in whole or in part, is strictly prohibited.]