Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Thinking through Publishing Contracts: Tips and Lessons Learned

Recently, I helped some friends review publishing contracts. Having read quite a few contracts by now, learning from theirs as well as our own experiences, I hope this post helps other indie devs with the complexities and caveats of the contract.

Howard Tsao, Blogger

July 26, 2012

21 Min Read

title image

Contract, not so easy

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.  

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.  

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:

Gross Receipts”.  For purposes of this Agreement, “Gross Receipts” shall mean all monies actually received by [Publisher] in connection with the licensing, distribution, sale, or other exploitation of copies of the Game.

[Publisher] shall pay to [Developer] a royalty of [X%] of the Adjusted Gross Receipts derived in connection with [Publisher] exploitation of the Market Versions of the Game.  

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:”

For purposes of this Agreement, “Adjusted Gross Receipts” means the Gross Receipts less (i) promotional, markdown, or similar credits against amounts received (if applicable); (ii) returns, refunds, and credits (if applicable); (iii) cost of goods manufactured (if applicable); (iv) all marketing, advertising, promotion, and business development expenses funded by [Publisher], paid to an unrelated third party, and directly related to the Game; (v) any royalties, licensing charges, or manufacturing charges payable to any third party as a condition to exploitation of the Game on a proprietary Platform; (vi) [Publisher]’s actual out‑of‑pocket cost to prepare the Game for Electronic Delivery, if applicable (including any royalties [Publisher] is required to pay to a third party in connection with the preparation of the Game for Electronic Delivery); (vii) [Publisher]’s actual out‑of‑pocket cost to deliver the Game via Electronic Delivery, if applicable (including any commissions, fees, bounties, or royalties payable to any unrelated online service provider or other unrelated party for delivery via Electronic Delivery); (viii) market development funds and cooperative advertising funds provided by [Publisher] directly related to the Game; and (ix) any federal, state, or foreign sales, excise, or other taxes or tariffs imposed on the exploitation of the Game.

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: 

No later than thirty (30) days after preparation of the Project Plan, [Developer] and [Publisher] shall jointly prepare a written plan for the marketing and publication of the Game (the “Marketing Plan”), which shall include a marketing budget and any other provision that the Parties mutually agree upon.  The Marketing Plan shall be signed by both Parties and attached hereto as Exhibit C.  Subject to and consistent with the parameters set forth in the Marketing Plan, and the other provisions of this Agreement.

Notwithstanding anything to the contrary in this Agreement, [Publisher] shall not recover any expenses under this Section 5.2.1 beyond the marketing budget [Developer] has approved.

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: 

Within 7 days after the deliverables for Milestone X are completed by [Developer], pass the inspection of and become accepted by [Publisher].  Payment Method: [Publisher] shall remit to the account designated by [Developer] according to the agreed due date.

To proceed with the Prototype Development smoothly, both parties shall discuss the Prototype Development related matters through video or telephone conference on a regular basis or whenever necessary.

In the event that [Developer] cannot deliver the Prototype Development to [Publisher] timely on the delivery date stipulated in Article 2, [Developer] shall notify [Publisher] immediately and consult [Publisher] for instructions.

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:

Unless the event is caused by force majeure, in the event that [Developer] fails to complete the Prototype Development within the scheduled period stipulated in Article 1 or the Prototype Development delivered fails to pass the inspection of [Publisher], [Publisher] shall be entitled to terminate the Agreement by written notice after [Developer] fails to improve or complete the improvement within one month from the receipt of the written notice of [Publisher].

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. 

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:

[Developer] hereby grants to [Publisher] the exclusive license during the Term of this Agreement to manufacture, publish, market, and distribute copies of all Market Versions of the Game prepared pursuant to this Agreement, in object code form only, in all channels and classes of trade, via all manner and media of distribution, whether now known or hereafter developed (including, for the avoidance of doubt, Electronic Delivery), throughout the Territory.  Such license includes authorization for [Publisher]’s unrestricted use of the Game and the names and trademarks of [Developer] for the purposes of publicity, advertising, and sales promotion.  In view of the exclusive nature of the license granted to [Publisher], [Developer] shall not, directly or through a third party, exploit or permit the exploitation of the Game in the Territory during the Term, other than the exploitation authorized in this Agreement.

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:

[Developer] agrees that [Publisher] shall be the author of all materials contained in the Project under this Agreement, and that [Publisher] shall be entitled to the ownership, intellectual property rights (including, without limitation, copyrights, patents and trademarks) and any other legal rights or interests of the materials. [Developer] shall not object the aforesaid agreement afterwards. [Developer] also agrees not to assert any moral rights of the author related to such materials. In the event that [Publisher] deems it necessary to apply the register of copyright or to exercise any other intellectual property rights of the materials, [Developer] shall cooperate with [Publisher] in dealing with the registration and matters concerned.

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: 

Both during and after the Term, [Publisher] has the right of first refusal for the right to Exploit the Product on alternative platforms.... If [Developer] agrees terms with a third party for such exploitation, [Publisher] shall be offered the rights on the same material terms as such third party before [Developer] conclusively signs the agreement with such third party. In the event that [Publisher]’s acceptance or rejection of the terms is not received within 45 days from the receipt of [Developer]’s offer, the terms will be deemed as rejected by [Publisher].

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.  

TerminationThe 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.

Either Party may terminate this Agreement at any time effective upon written notice of termination to the other Party in the event that such other Party materially breaches any material provision of this Agreement and such breach continues unremedied for a period of thirty (30) days after written notice of such material breach; provided, that, such notice shall specify in reasonable detail the provision(s) of this Agreement alleged to be breached, the specific facts and circumstances that give rise to such breach, and what specific steps such other Party can take in order to remedy such breach.   In the event [Publisher] terminates this Agreement, then [Developer] shall reimburse [Publisher] for any expenditures incurred by [Publisher] to perform under this Agreement through the date of such termination. 

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:

In the event that any Market Version fails to achieve any Platform Approval by the date prescribed in the Project Plan for any reason whatsoever, [Publisher] may take any of the following actions, without limiting any of [Publisher]’s other remedies in this Agreement or otherwise:
(i) cancel the preparation of the particular Market Version, but proceed with the preparation of the other Market Version(s); 
(ii) terminate this Agreement, effective immediately upon written notice; or
(iii) continue the preparation of the particular Market Version, provided that if [Developer] believes, reasonably and in good faith, that additional time must be added to the schedule in the Project Plan, the Parties will negotiate in good faith what, if any, adjustments will be made.

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:

Either Party may terminate this Agreement at any time effective upon written notice of termination to the other Party in the event the Game has not been approved by a Platform Proprietor or distribution channel on or before the date set forth for such approval in the Project Plan.  

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 Right shall commence, if at all, upon [Publisher]’s cancellation of a Market Version or termination of this Agreement.  Once the Turnaround Right has arisen, it may be exercised at any time.  [Developer] may exercise the Turnaround Right only by reimbursing [Publisher], in immediately available funds, for all amounts paid by [Publisher] to [Developer] under this Agreement with respect to the affected Market Version(s), plus all amounts paid or payable by (or due from) [Publisher] to any third parties (or allocated to [Publisher] in the Project Plan for marketing or production services provided by [Publisher]) in preparation for, or in connection with, the marketing or preparation of such Market Version(s).  [Developer] shall not enter into any agreement with a third party publisher with respect to publication of such Market Version(s) unless either (a) [Developer]  has exercised the applicable Turnaround Right by making the required payments, or (b) such agreement provides for the exercise of the applicable Turnaround Right by making the required payments, with the amounts owed being reimbursed promptly upon such agreement becoming effective.  Upon receipt in full of the foregoing amounts (a “Turnaround”), [Publisher] shall quitclaim all of its rights to and interest in the affected Market Version(s) in favor of [Developer]  or [Developer] ’s designee.

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:  

Notwithstanding anything to the contrary in this Agreement, [Publisher] shall not recover any expenses under this Section 5.2.1 beyond the marketing budget [Developer] has approved.

Now let’s continue with the Guns of Icarus Online 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:

Both parties agree to perform the Agreement in good faith. In the event that the change of the circumstance affects the collaboration of the parties, [Publisher] may terminate this Agreement by one-month prior written notice to [Developer].

During the term of the Agreement, in case of the dissolution, suspension, bankruptcy, reorganization and liquidation of either party, the Agreement is deemed terminated.

In the event that the Prototype Development passes the inspection of [Publisher] and [Publisher] is not willing to accordingly continue to complete the formal development of the Project, [Developer] shall be entitled to complete the Project at its own expense and maintain ownership of the Project. All revenue earned by [Developer] from the operation of the Project under this section shall be shared by [Developer] and [Publisher] in proportion to the amount of money [Publisher] has paid [Developer] towards the Project. 

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 reach out to him at [email protected]

Read more about:

Featured Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like