Free Word download • Edit online • Save & share with Drive • Export to PDF
A Software Development and Publishing Agreement is a legally binding contract between a developer — the individual, studio, or company building the software — and a publisher — the entity funding, distributing, and commercially exploiting it. The agreement governs the entire lifecycle of the commercial relationship: the development scope and milestone payment schedule, IP ownership or licensing terms, advance recoupment and royalty calculations, distribution territory and exclusivity, marketing obligations, quality assurance approvals, and what happens to the software if either party fails to perform or the relationship ends. Unlike a simple development contract or a standalone license, this document addresses both the creation and the commercialization of the software in a single enforceable instrument.
Without a signed publishing agreement in place before development begins, both parties operate in a legal vacuum with significant exposure on multiple fronts. Developers who start work without a contract risk losing IP ownership through implied work-for-hire arrangements, receiving no royalties despite commercial success, or being locked into an exclusive distribution relationship with a publisher who underinvests in sales. Publishers who advance funds without a signed milestone schedule have no enforceable delivery obligations, no quality acceptance rights, and no recourse if the developer abandons the project or shops the IP to a competitor. A properly drafted software development and publishing agreement eliminates these risks by creating clear, documented obligations on both sides — establishing exactly who owns what, what gets built by when, how revenue is shared, and what each party can do if the other defaults. This template gives you a professionally structured starting point that covers every critical clause, from advance recoupment to IP reversion, so that your commercial relationship is built on a foundation of written terms rather than assumptions.
| If your situation is… | Use this template |
|---|---|
| Developer retains IP and grants only a distribution license | Software Licensing Agreement |
| Publisher fully funds development and acquires all IP | Software Development Agreement (Work for Hire) |
| Two parties co-developing software with shared ownership | Joint Development Agreement |
| Ongoing software maintenance and updates post-launch | Software Maintenance Agreement |
| Contracting a freelance developer for a defined project | Independent Contractor Agreement |
| Distributing existing software through a reseller network | Software Reseller Agreement |
| White-labeling software for a third-party brand | White Label Software Agreement |
Why it matters: Publishers who can unilaterally define deductions have been found to charge marketing, overhead, and distribution costs that reduce net revenue to near zero, effectively eliminating developer royalties despite strong sales.
Fix: Enumerate every permissible deduction explicitly in the contract and cap platform fee deductions at 30%. Any deduction not listed is not permitted.
Why it matters: A broad IP assignment without a Schedule C exclusion can inadvertently transfer ownership of the developer's reusable engine, proprietary libraries, or tools — assets the developer needs for every future project.
Fix: List all pre-existing IP in a Schedule C at signing and confirm it is licensed (not assigned) to the publisher for use solely in the covered software.
Why it matters: A publisher with exclusive worldwide rights who underperforms can block the developer from seeking other distribution for years, with no commercial remedy available.
Fix: Include a minimum sales or revenue threshold per territory or globally. If the floor is missed in a 12-month window, exclusivity automatically converts to non-exclusive.
Why it matters: Without a clause triggering automatic reversion on insolvency, the software becomes an asset of the publisher's bankruptcy estate and can be frozen, sold, or tied up in proceedings for years.
Fix: Add an explicit termination trigger for insolvency, receivership, or assignment for benefit of creditors, with automatic IP and license reversion to the developer upon that event.
Why it matters: Acceptance criteria written as 'publisher's reasonable satisfaction' without objective technical benchmarks give publishers the ability to reject milestones indefinitely, withholding payment while demanding unpaid extra work.
Fix: Attach a technical acceptance checklist to each milestone in Schedule B and include a deemed-acceptance clause if the publisher does not reject in writing within the review period.
Why it matters: Work performed before a signed agreement can create implied IP licenses or work-for-hire arrangements under common law that override the intended ownership structure in the written contract.
Fix: Execute the agreement — including all schedules — before any development work begins or any funds are transferred. If circumstances require a retroactive agreement, include a clause confirming it covers all prior work.
In plain language: Identifies the developer and publisher as legal entities, summarizes the purpose of the agreement, and defines key terms used throughout the contract.
This Software Development and Publishing Agreement ('Agreement') is entered into as of [DATE] between [DEVELOPER LEGAL NAME], a [STATE/COUNTRY] [ENTITY TYPE] ('Developer'), and [PUBLISHER LEGAL NAME], a [STATE/COUNTRY] [ENTITY TYPE] ('Publisher').
Common mistake: Using trade names instead of registered legal entity names — if the entity name on the contract doesn't match the signing party's incorporation documents, enforcement and IP chain-of-title become contested.
In plain language: Defines the software to be built, the agreed feature set, target platforms, and the schedule of milestones with corresponding deliverables, acceptance criteria, and payment tranches.
Developer shall develop the Software described in Schedule A ('Scope of Work') and deliver each Milestone set out in Schedule B by the corresponding due date. Publisher shall review and accept or reject each Milestone within [14] business days of delivery.
Common mistake: Writing vague acceptance criteria — 'publisher satisfaction' without objective technical benchmarks gives publishers unilateral rejection power and gives developers no clear pass/fail target, leading to costly disputes mid-project.
In plain language: States who owns the software, underlying code, assets, and derivative works — and whether ownership transfers to the publisher or the developer retains it with a license granted to the publisher.
Developer hereby assigns to Publisher all right, title, and interest in and to the Software, including all copyrights, patents, trade secrets, and other IP rights, worldwide. Developer retains ownership of its Pre-Existing IP listed in Schedule C, which is licensed to Publisher solely for use in the Software.
Common mistake: Failing to carve out the developer's pre-existing tools, engines, and code libraries. Without a Schedule C exclusion, the assignment clause can transfer ownership of reusable assets the developer needs for future projects.
In plain language: Sets out the total development advance, the installment amounts tied to each milestone, payment timing, and the conditions that trigger or suspend payment.
Publisher shall pay Developer a non-refundable advance of $[TOTAL ADVANCE] in installments as set out in Schedule B, each payable within [10] business days of written acceptance of the corresponding Milestone.
Common mistake: No cure period before payment suspension — allowing the publisher to withhold an entire milestone payment over a minor defect gives publishers disproportionate leverage and can starve the developer of operating cash.
In plain language: Defines the royalty rate, the revenue base it applies to, permissible deductions, payment frequency, and the developer's right to audit the publisher's sales records.
Publisher shall pay Developer a royalty of [X]% of Net Revenue, defined as gross receipts less [platform fees not to exceed 30%, sales taxes, returns, and chargebacks]. Royalties shall be reported and paid quarterly within [45] days of period end. Developer may audit Publisher's records once per year with [30] days' notice.
Common mistake: Leaving 'net revenue' undefined or subject to unilateral publisher deductions — publishers have been found to deduct marketing, shipping, and overhead costs that eliminate royalties entirely, a practice sometimes called 'creative accounting.'
In plain language: Grants the publisher the right to distribute, sell, sublicense, or publish the software across defined platforms, territories, and channels, and states whether the grant is exclusive.
Developer grants Publisher an exclusive license to distribute, sell, and sublicense the Software in [TERRITORY] via [PLATFORMS/CHANNELS] for the Term. Publisher may not sublicense distribution rights without Developer's prior written consent.
Common mistake: Granting worldwide exclusivity without a performance floor — if the publisher fails to actively sell in certain territories, the developer is locked out with no recourse. Include a minimum sales threshold or a right to reclaim inactive territories.
In plain language: States the publisher's minimum marketing commitments — budget, activities, launch support — and the developer's obligations to cooperate with marketing efforts.
Publisher shall commit a minimum marketing budget of $[AMOUNT] to the Software launch, covering [CHANNELS]. Publisher shall consult Developer on creative direction for marketing materials. Developer shall provide promotional assets and participate in up to [X] media appearances per quarter.
Common mistake: No minimum marketing obligation on the publisher — a publisher with exclusive rights who then underinvests in promotion can doom a product commercially while preventing the developer from doing anything about it.
In plain language: Defines the QA and testing process, who bears certification costs, and the approval process for updates, patches, and DLC after launch.
Developer shall deliver a Gold Master to Publisher no later than [DATE]. Publisher shall conduct QA testing within [21] days. Costs of platform certification (e.g., Apple, Google, Sony) shall be borne by [PARTY]. Post-launch patches require Publisher approval within [5] business days.
Common mistake: Assigning all certification costs to the developer without a cap — platform certification can cost thousands of dollars per submission and per platform, and repeated rejections compound costs rapidly.
In plain language: Sets out the conditions for termination by either party — including material breach, insolvency, and milestone failure — and what happens to the IP and distribution rights upon termination.
Either party may terminate for material breach upon [30] days' written notice if the breach is not cured within that period. Upon termination for Publisher's uncured breach, all IP rights and distribution licenses shall automatically revert to Developer, and Publisher shall deliver all source code and assets to Developer within [10] business days.
Common mistake: No automatic reversion of IP upon publisher insolvency — if the publisher enters bankruptcy, the software can be frozen in an estate for years without an automatic reversion clause triggered by insolvency proceedings.
In plain language: Each party warrants that it has the authority to enter the agreement, that the software does not infringe third-party IP, and that each party will indemnify the other against claims arising from its own breach.
Developer warrants that the Software is Developer's original work, does not infringe any third-party IP, and contains no malicious code. Each party shall indemnify, defend, and hold harmless the other party from claims arising from its own breach of these warranties.
Common mistake: Broad mutual indemnification without a carve-out for open-source components — if the software includes GPL or LGPL code, the developer cannot warrant full IP ownership without disclosing and addressing the open-source license obligations.
Use each party's registered corporate name exactly as it appears in their incorporation documents. Include entity type (LLC, Inc., Ltd.) and jurisdiction of formation.
💡 Request a Certificate of Good Standing from the other party before signing — it confirms the entity is active and authorized to contract.
Describe the software with sufficient specificity — target platforms, core feature list, technical requirements, and any brand or IP being licensed into the project. Attach wireframes or a Game Design Document if available.
💡 Ambiguity in scope is the single most common cause of publishing disputes — if a feature is not in Schedule A, assume neither party agrees it is included.
List every major deliverable with a due date, an objective acceptance standard, and the corresponding payment installment. Include a publisher review period (typically 10–21 business days) for each milestone.
💡 Add a deemed-acceptance clause: if the publisher does not reject a milestone in writing within the review period, it is automatically accepted. This prevents indefinite holdups.
Agree the total advance, the installment amounts tied to each milestone, and the payment timing — typically within 10 business days of milestone acceptance. Include a cure period before the publisher may withhold payment for minor defects.
💡 Negotiate a kill fee for partial advances already paid if the publisher terminates early — this protects the developer's sunk costs.
List every permissible deduction from gross receipts to arrive at net revenue — platform fees (cap at 30%), taxes, returns, and chargebacks only. Set the royalty rate and the quarterly payment and reporting cycle.
💡 Require the publisher to provide a royalty statement with each payment showing gross receipts, each deduction line, net revenue, and royalty calculated — vague statements make auditing impossible.
Name every territory and distribution channel covered by the license and whether exclusivity applies. If exclusivity is granted, add a minimum annual sales threshold or unit floor that the publisher must meet to retain exclusivity.
💡 A tiered reversion clause — exclusivity converts to non-exclusive if sales fall below $[X] in any rolling 12-month period — protects the developer without requiring full termination.
State the breach cure period (30 days is standard), list automatic termination triggers (insolvency, criminal conviction, change of control), and confirm that all IP and source code reverts to the developer on any publisher-caused termination.
💡 Include a source code escrow arrangement so the developer's master repository is accessible to the publisher for maintenance if the developer dissolves — and vice versa for source code reversion.
Both parties must sign before the developer writes a line of code or the publisher transfers the first advance installment. In common-law jurisdictions, work performed before a signed agreement can create implied licenses that override the written contract.
💡 Use a dated e-signature platform to create a timestamped execution record. Store the fully executed agreement and all schedules together as a single PDF.
A software development and publishing agreement is a legally binding contract between a developer — who builds the software — and a publisher — who funds, distributes, and commercializes it. It governs IP ownership, the milestone and payment schedule, royalty terms, distribution rights, and what happens if either party fails to perform. It is the foundational document for any commercial software publishing relationship and should be signed before development begins or money changes hands.
IP ownership depends entirely on how the agreement is negotiated. Under a work-for-hire structure, the publisher acquires all IP rights. Under a license model, the developer retains ownership and grants the publisher an exclusive or non-exclusive distribution license. Most modern publishing deals use a license model with reversion rights — the developer keeps the IP, but the publisher holds exclusive distribution rights for the contract term. The specific structure should be reflected clearly in the IP clause and Schedule C.
A publisher advance is an upfront payment from the publisher to the developer, structured as a recoupable investment against future royalties. The developer receives the advance to fund development but does not receive royalty payments until the publisher has recouped the advance from sales revenue. After recoupment, royalties are paid at the agreed rate on net revenue going forward. The advance is typically non-refundable — the developer does not owe it back if the game underperforms — unless the developer is in material breach.
Royalty rates vary widely by industry segment. In video game publishing, developer royalties typically range from 15% to 35% of net revenue after recoupment, depending on the developer's leverage, the size of the advance, and exclusivity terms. For mobile apps and SaaS white-label arrangements, revenue shares of 20% to 50% are common. There is no universal standard — the rate reflects the relative bargaining power of each party and should always be paired with a clear, limited definition of net revenue.
Reversion rights are contractual provisions that return IP ownership or distribution rights to the developer if the publisher fails to meet its obligations — such as hitting sales minimums, paying royalties, or actively distributing the software. They are critically important because an exclusive distribution grant without reversion rights can trap a developer's software with an underperforming publisher indefinitely. Reversion clauses typically trigger on publisher insolvency, material breach, or failure to meet a minimum commercial performance threshold.
For most commercial publishing deals, yes — particularly where significant advances are involved, exclusivity is granted, or the software represents the developer's core IP. The IP ownership structure, net revenue definition, and termination and reversion provisions are technically complex and jurisdiction-sensitive. A lawyer review typically costs $1,000–$3,000 and is routinely worthwhile given that a typical publishing advance ranges from $50,000 to several million dollars. A template is a sound starting point, but specialist review before execution is strongly recommended.
If the publisher fails to meet a minimum marketing commitment written into the agreement, it constitutes a material breach — entitling the developer to serve a cure notice and, if uncured, to terminate and trigger reversion rights. This is why it is important to specify marketing obligations in concrete terms (minimum budget, launch channels, agreed media activities) rather than vague language like 'commercially reasonable efforts.' Vague obligations are nearly impossible to enforce.
Yes — if the original agreement limits the publisher's territory or platform scope, the developer may engage additional publishers for uncovered territories or platforms. This is a common deal structure when one publisher has strong distribution in North America but no presence in Asia or Europe. The agreement should explicitly define which territories and platforms are covered so that both parties understand what remains available for separate arrangements.
Each milestone entry in the schedule should include a milestone name and description, the specific deliverables required, objective acceptance criteria (not just 'publisher satisfaction'), the due date, the publisher's review period, and the payment amount triggered by acceptance. Including a deemed-acceptance provision — where silence for 14 business days constitutes acceptance — prevents publishers from stalling milestone payments indefinitely by failing to respond.
A standalone software development agreement covers only the build phase — scope, deliverables, and payment for development work. It does not address distribution rights, royalties, or post-launch commercial obligations. A software development and publishing agreement combines the build and distribution relationship into a single contract, making it the appropriate choice when the same party is both funding development and publishing the finished product.
A software license agreement governs the use of already-completed software — it grants defined usage rights without funding or directing development. A publishing agreement governs the creation and commercial distribution of software that does not yet exist, including milestone funding, QA, and royalties. If the software is already built, use a license agreement; if it still needs to be built, use a publishing agreement.
An independent contractor agreement engages a developer for a fixed project at a flat or hourly rate, typically with all IP transferring to the client as work for hire. A publishing agreement is a commercial partnership — the developer retains more control and IP, shares in commercial upside through royalties, and the publisher takes on distribution obligations. The two documents serve fundamentally different commercial relationships.
A joint development agreement is appropriate when two parties are co-developing software together, sharing costs, resources, and IP ownership. A publishing agreement has a clearer division of roles — one party builds, one party funds and distributes — and typically involves one party's IP being licensed to the other rather than jointly owned. Joint development introduces co-ownership complexity that publishing agreements are specifically designed to avoid.
Milestone-based gold master delivery, platform certification costs, digital storefront revenue splits, and DLC publishing rights are all standard negotiation points unique to game publishing deals.
App store platform fee deductions (Apple 15–30%, Google 15–30%) must be defined in the net revenue clause, and the agreement should address in-app purchase revenue treatment and operating system update obligations.
White-label and OEM distribution arrangements require clear branding rights, data ownership provisions, uptime SLA references, and source code escrow terms given the mission-critical nature of enterprise deployments.
FERPA and COPPA compliance representations are required for software handling student data, and the agreement should address content update obligations and curriculum alignment approvals that affect the publisher's institutional sales cycle.
US copyright law automatically vests in the creator unless the work qualifies as 'work for hire' under 17 U.S.C. §101 — commissioned software only qualifies if it falls into specific statutory categories and a written work-for-hire agreement is signed. Non-compete clauses in publishing agreements are unenforceable in California. State-specific UCC provisions may apply to software transactions, and choice-of-law clauses are generally enforced between commercial parties.
Canadian copyright law similarly vests in the author by default; assignment must be in writing and signed to be effective. Quebec publishers and developers must have French-language contract versions for provincially-regulated entities. PIPEDA and provincial privacy laws may impose data handling obligations if the software collects personal information from Canadian users. Royalty payments to non-resident developers may be subject to Part XIII withholding tax under the Income Tax Act.
UK copyright in software created by an employee vests in the employer, but IP created by an independent developer vests in the developer — making an explicit written assignment essential. Post-Brexit, UK and EU distribution rights must be addressed separately in the territory clause. The UK's Video Games Tax Relief (VGTR) may affect the structuring of development funding arrangements. Restraint of trade clauses, including exclusivity and non-solicitation provisions, are subject to reasonableness review under English common law.
The EU Software Directive (2009/24/EC) provides specific copyright protections for software and limits the scope of lawful decompilation rights granted to licensees — publishers should not grant end users rights beyond those mandated. GDPR applies if the software processes personal data of EU residents, and data processing obligations should be addressed in a separate DPA or within the agreement. Several EU member states require that royalty agreements be registered or notified to collecting societies in specific content categories.
| Path | Best for | Cost | Time |
|---|---|---|---|
| Use the template | Early-stage developers and small publishers negotiating deals under $50,000 in advances with straightforward domestic distribution | Free | 1–2 hours to complete |
| Template + legal review | Deals involving advances of $50,000–$500,000, exclusivity clauses, or multi-platform distribution across two or more territories | $1,000–$3,000 | 3–7 days |
| Custom drafted | Major publishing deals with advances above $500,000, multi-territory exclusivity, equity components, or complex IP portfolios requiring chain-of-title clearance | $5,000–$20,000+ | 2–6 weeks |
This document is one of 3,000+ business & legal templates included in Business in a Box.
Access over 3,000+ business and legal templates for any business task, project or initiative.
Customize your ready-made business document template and save it in the cloud.
Share your files and folders with your team. Create a space of seamless collaboration.
"Fantastic value! I'm not sure how I'd do without it. It's worth its weight in gold and paid back for itself many times."
"I have been using Business in a Box for years. It has been the most useful source of templates I have encountered. I recommend it to anyone."
"It has been a life saver so many times I have lost count. Business in a Box has saved me so much time and as you know, time is money."
Stop downloading documents. Start operating with clarity. Business in a Box gives you the Business Operating System used by over 250,000 companies worldwide to structure, run, and grow their business.
Free Forever Plan · No credit card required
