About Contracts

This Editorial Feature was written by Howard Tsao, CEO and Founder of Muse Games Corp.

Recently, some friends and fellow indie devs have been asking me for help to read over a few contracts ranging from publishing, distribution, contests, to RFPs, or partnering on music or art. I’m not a lawyer, and I’m learning as I go as well, but I did accumulate some experience along the way, and learned from some pretty horrific situations, that I could at least offer some feedback on what I find, so hopefully others won’t suffer the same fate. Going over contracts is always difficult and laborious, especially with all the legal mumble jumble being so cryptic, like a code or a riddle to be deciphered. So my goal with this post is go into some examples and to not only point out some things to watch for, but also what I proposed as solutions.

More after the jump…

Before I go into the nitty-gritty though, I just want to preface on what I think about contracts in general. I think contracts are a way for two sides to talk and air everything there is to air before they get into a working relationship. But a contract is also an interest reflection of power. Each side has interests to protect and advance, and this is where potential for inequity lies. If both parties find it mutually beneficial together, then the goal of negotiation is just to get the contract to as equal of a state as possible, or to a point where both parties can win.

Because there are a variety of contracts types for different purposes, each with its own considerations, I’ll focus this post on publishing, as it is more complex and impactful. The examples referenced are from our own experiences with Guns of Icarus Online as well as from those I looked over with friends.

To me, in any publishing contract, the 3 most important things are:

 

1. Money – how revenue is shared, what expenses are deducted, and when payments are made.
2. IP – who owns what, what the publisher would want to own and license.
3. Termination – if things go badly, what rights does the developer have to get out of the contract.

Money

So to start, let’s take a look at how one contract example treats money. In this example, the overall sharing of revenue is pretty straight forward:

The term “exploitation” sounds a bit scary, but I’ve seen it use pretty often, so we are actually safe here. And having revenue from platforms such as Steam or iOS go first to publishers is also common practice based on my experience. What is trickier is how expenses are deducted from “Gross Receipts:”

With all the possible expenses listed, this is the most exhaustive I’ve seen. Some of these seem reasonable, such as deductions for refunds, taxes, cost of goods manufactured, if any. But (iv), (v), (vi), (vii), and (viii) takes the ability to control expenses and costs completely out of the developer’s hands. With the way this is phrased, there is no way for the developer to have a say as to what is reasonable spending. Obviously the intention here is not so that the publisher can fly private jets or eat caviar while promoting the game or getting the game delivered to a distribution platform, but the developer should also have some assurances and transparency as to how much the publisher is going to spend. In a publishing relationship, the risks (ex. financial) should be more evenly distributed.

With marketing, there are a few scenarios, and the best for an indie dev in my mind is for a publisher to commit to a marketing budget or a licensing fee for the game. The second best is if the publisher offers an advance because while it is recoupable against revenue, it does reflect the publisher’s to commit its resources to make at least the revenue amount equal to the advance so that the publisher can make back its upfront investment. More typically, the publisher revenue shares with the developer, and the developer assumes the production costs while the publisher assumes the marketing costs minus some applicable expenses such as transaction or refund costs. In the above clause, the expenses are more numerous, and the possibility exists, as remote as it is, for the developer to have all revenues deducted against publisher expenses. In other words, the possibility exists here for a developer to not make any money at all even if the game is successful. Therefore, the terms above should be better defined and quantified so that it’s more balanced for both the publisher and the developer.

After a conversation, these edits were added:

With these additions, the developer now has a voice in and control over marketing spending and therefore the expenses and the profit margin of the game. And the publisher still has the ability to spend any money it deems necessary and protection financially.  Hopefully this is an easy and straightforward way to attain a win-win.

When we started on the development of Guns of Icarus Online, we were working with a publisher in co-development. At the time, we thought it was great opportunity as the the publisher was providing the funding as well as revenue sharing for us to develop the game. Along the way, things unraveled for us. Aside from a growing chasm in creative directions, where the publisher’s marketing drifted more towards a more toony, anime look while we strived to keep to our original vision and aesthetics, there were other problems that ended up putting us in dire straits because we were not careful enough with our contract.

Here’s the part in the contract that really put us in a bind:

Before the project started, we drafted a concept doc and spec list for both prototype and alpha so that the publisher could get better sense of the game and its scope. Verbally, the publisher told us that it was meant to be revised along the way, as changes were inevitable as with any other project. But, the spec list was included as an exhibit in the contract that dictated the “deliverables” for each prototype milestone. At the time, we really didn’t think through the ramifications. The issue here is that the entire review process was contingent upon an “inspection,” and while the specs were defined, how to perform the inspection or its timeliness was not defined anywhere. With the publisher, we did have weekly calls, and the project was amazingly on track. A few items were mutually agreed upon to be out of scope or obsolete, so they were removed with publisher’s sign off.

But when we reached the “inspection” for the final milestone, the upper management wanted to get involved, and the review that was supposed to take a few days turned into over month, and along the way, the management went on a company retreat. When finally we heard back after weeks blown in the wind, we heard back that we failed the inspection. The reason was basically that alpha features not part of the original specs were requested. If we didn’t do them, we didn’t receive payment. In our case, the clause in the contract that gave the publisher justification for dumping alpha features on us at prototype and not wanting to pay is:

Since the contract did not clearly define how inspection was supposed to be conducted, we took a leap of faith that didn’t work out in our favor. The lesson for us was that, if there is a part of the co-development or review process that is critical to progress, it should not be completely out of the developer’s control and not be opaque.
IP
The next critical area in a contract or relationship is IP, and I’ll once again use my friend’s example as well as our own.

Here’s the example on the publisher’s licensing of the developer’s IP:

Because this is a publishing and not a distribution agreement, the publisher asks for exclusive license. The important thing here is to make sure that “Market Versions” are clearly defined (ex. in an exhibit). If the developer only wants the publisher to distribute the PC version but may want to self publish an iOS version in the future, then that needs to be stated clearly. Another thing to note is the “territory,” which is where the publisher can publish the game. In this case, because the developer had wanted to reserve the possibility to explore the Asian markets with a free-to-play version, free-to-play version of the game and different Asian territories were removed from the contract.

Do note that in the above clause, the developer only grants the publisher a license of the game and not gives their IP away. What should definitely be avoided and taken out of the contract is something like this:

This is basically the publisher taking the game’s IP. I don’t believe this has a place in any publishing contract because taking IP ownership is not a justification or reflection of publisher commitment. This was in our original publisher contract for Guns of Icarus Online, and it really made us do a double take.

Another important IP related issue to note in a publishing contract is sequel and future version rights. Let’s take a look at the following:

This clause basically says that, for any alternative version of the game, the publisher has the right to, within 45 days see if they want to publish it first. Or if the developer negotiates with another publisher or distributor, the same terms have to be offered to the current publisher before any agreement is signed. Sequel rights can be written this way as well. Whether or not to give a publisher the rights to sequels or future alternative versions of the game should be up to comfort level the developer, and it should depend on the performance of the publisher as well. For a first project, this clause can be removed from the contract, and if the game is successful, then both the developer and the publisher have done a good job.  At that point, the sequel or future game version rights can be talked about again.

 

Termination

The third critical area of a publishing contract in my mind was termination. I will first use my friend’s publishing contract as an example and then continue with our own story on Guns of Icarus Online

Two things jump out in this clause. One is that, there is only termination for cause, and the burden of proof is on the originating party. For a small developer, to go through the hassle in case things go wrong is difficult. The second is that, if the publisher terminates, the developer has to pay for any expenses the publisher incurs. This appears to be rather one-sided. For any reimbursement, it should either be stricken or be governed by a budget agreed upon at the onset.

At first glance, termination seems pretty equal, then in the same contract, there’s another clause that says:

With this clause, the termination in the contract became pretty one-sided. The publisher dictates the course of action under various circumstances and can get out of the contract immediately if a game version doesn’t get approved by a distribution platform for whatever reason. Meanwhile, the developer has no way to get out of the contract here.

After a back-and-forth, the following is added:

Now, the termination becomes more balanced. If the game doesn’t get approved by a distribution platform for whatever reason, the developer can now get out of the contract.

Another item in this contract following the termination clauses is something called turnaround right, the right for the developer to acquire all rights and interest granted to the publisher under the contract, and here’s how it’s worded:

The turnaround rights here seems expensive. The publisher would keep all revenue shared, but also has full reimbursement. Also, it isn’t clear on what happens if the publisher has already recovered the amount of the expenses from revenues. Does this mean the developer has to pay twice? Any repayment to the publisher should be limited to only the amounts not otherwise recovered from revenues in this case. After all, the publisher is supposed to pay the developer only after deducting the costs from the gross receipts (gross revenue). Also, if in the event that the game is resubmitted to a platform, then the publisher should repay whatever the developer paid to publisher earlier.

In clearing away the issues and vagueness related to the turnaround rights clause, something simple was added:

Now let’s continue with the Guns of Icarus example and look at termination. We completed prototype development on schedule and per spec, but we failed inspection. People who were not involved with the project came in and decided that some features that were clearly for alpha and not on the prototype spec agreed upon were not in during prototype, and we failed. And because we failed, we can be demanded to implement these features. At this point, we wanted to terminate and get out of the contract and the relationship. But can we? Would the termination clause allow us to get out? Let’s see:

These termination clauses basically were not intended to give us an out at all. The publisher can terminate pretty much at anytime, and we could only terminate if we dissolve as a team. What’s even more one-sided is that, even if we pass inspections for prototype, the publisher can still terminate for whatever reason. And, the publisher can take a cut of the revenue up to the amount they paid toward the project. We eventually got out of the contract after long conversations with their management. Along the way, the publisher threatened to take the IP of Guns of Icarus Online. We were fortunate to have moved on and are still creating our dream game, but it would have all been for naught.

To conclude, the lessons that we learned through it all are:

 

1. Know what you are agreeing to do.
2. Know what you are getting for it all.
3. Have an acceptable exit strategy if you are unable to do what you promised to do or if you are not getting what you were asking for.

For a contract to be enforceable, the only thing that has to be clear is: who is agreeing to do what for what. In a publishing agreement, the developer agrees to provide the publisher with a game to sell and market, and the publisher agrees to sell the game, in exchange for a share of the profits. That’s really the essence of it, and anything else is extra. The extra stuff is really there to describe how the parties will do their jobs and to agree in advance what they will do if something should happen. The “what if something should happen” is not as much of a concern if the possibility is remote. But if the possibility is real, then we should really evaluate the terms especially if the terms are unfavorable. For example, toward the end of a contract, there is a provision for governing law. If that provision requires you to settle dispute in a foreign country, it can be unfavorable. But if you think the risk of a lawsuit is remote because the stake is so low, then that provision may be agreeable. If not, then that provision should be negotiated to something more mutual, such as the party originating the dispute should go to the other party’s country to settle it. So there is always going to be judgement calls on what you can live with, or not, in a contract.

If you have examples to share or have questions, please comment! Also want to give a shoutout to my friend Allan Liang who helped us get out of our difficult situation. He started his own law practice, and he’s concise, proposing simple and direct solutions and revisions. He’s also a gamer, always a big plus. If anyone ever needs help legally, feel free to get in contact with him mail@allanliang.com.