Who owns the code? What the contract says, and what happens without one
The contract decides who owns the code. With no written assignment, US law leaves copyright with the agency that wrote it and gives the client an implied license to use what it paid for. Most good contracts split it: the client owns the deliverables on full payment, and the agency keeps its background IP.
Ownership of code is decided by the contract. Everything else, who paid, who had the idea, whose repository it sits in, is background. If the contract assigns the code to the client, the client owns it. If the contract is silent, or there is no contract, the law has a default, and the default surprises almost every client and about half the agency owners I talk to.
This page covers the default, the three ownership models you will see in practice, the addendum I use to put the split in writing, and the part most owners never get to: what you still hold after the client takes the deliverable. It sits in the contracts hub next to the statement of work template, which is where the deliverables get defined in the first place.
What happens when there is no contract
Under US copyright law, the author of a work owns it from the moment it is written. For code written by your employees within their jobs, the author is your company. Your agency is an independent contractor to the client. So with no written agreement, the agency owns the copyright in the code it wrote for the client.
Clients often assume that paying for the work makes it theirs. Payment alone does not transfer copyright. A transfer of copyright ownership has to be in writing and signed by the owner giving it up. An invoice marked paid is evidence of a sale of services. It is silent on title.
What the client does get is an implied license. Courts reason that nobody pays for software they are forbidden to use, so the client gets a non-exclusive right to use the code for the purpose both sides had in mind. How far that license stretches is uncertain. Whether it covers modification by another vendor, resale as a product, or transfer to an acquirer depends on the facts of the deal, and it gets decided after a dispute has already started.
Why “work made for hire” does less than clients think
Client paper loves the phrase “work made for hire”. For an independent contractor, it only works when two things are true: the work falls into one of a short list of categories in the statute, such as a contribution to a collective work, a translation, or a compilation, and there is a signed written agreement saying so. Custom software usually fits none of those categories cleanly. A contract that relies on the label alone can leave the client without the ownership it thought it bought.
Competent client lawyers know this, which is why their clauses say “work made for hire, and to the extent it is not, Contractor hereby assigns”. The assignment is the part doing the work.
| Situation | Who owns the copyright | What the other side holds |
|---|---|---|
| No contract, agency wrote the code | Agency | Client has an implied license to use it |
| Contract says “work made for hire” and nothing else | Probably the agency | Client has an implied license and an argument |
| Contract contains a signed assignment | Client, from the trigger in the clause | Agency holds whatever the contract licenses back |
| Agency’s freelancer wrote it with no assignment to the agency | The freelancer | Agency and client both hold implied licenses at best |
Check your own chain of title
That last row is the one that hurts. Your employees’ work belongs to your company automatically. Your freelancers and subcontractors are in the same position toward you that you are in toward the client: they own what they write until they sign it over. You cannot assign to a client something you never owned. Every contractor agreement you sign needs a present assignment of IP to the agency, and this applies doubly if you run any staff augmentation arrangement where people from another firm write code under your name.
UK and EU
The UK reaches the same starting point. The contractor is the first owner of commissioned work, and an assignment must be in writing and signed by the person assigning. English courts will sometimes imply a license, or occasionally an assignment, where the deal makes no sense without one, which is an expensive way to find out what you agreed.
Across the EU, code written by employees belongs economically to the employer, and commissioned code stays with the contractor unless the contract moves it. In some countries, Germany being the usual example, copyright itself cannot be transferred. The contract grants exclusive usage rights instead. If your client is there, an “assign everything” clause needs a fallback license written in.
What an assignment clause does
An assignment clause moves ownership from the agency to the client. Three details in the drafting decide how it behaves.
Tense. “Agency hereby assigns” transfers ownership by itself when the trigger happens. “Agency agrees to assign” is a promise to sign something later. Clients want the first. You can live with the first as long as the trigger is right.
Trigger. Assignment on creation means the client owns each commit as it lands, paid or unpaid. Assignment on full payment means title stays with you until the invoices clear. This is the single most useful clause to have when a client stops paying, because a client running unassigned code has a real problem that an overdue-invoice email does not create.
Scope. “All work product” sweeps in everything you touched. “The Deliverables listed in the Statement of Work” covers what was sold. The definition matters more than the assignment sentence.
A clean agency-side version:
Upon Agency’s receipt of full payment of all Fees due under the applicable Statement of Work, Agency hereby assigns to Client all right, title and interest in the Deliverables, excluding Background IP, Third-Party Materials and Open Source Software.
The IP clause article goes through the anatomy line by line, with agency-friendly, balanced and client-friendly wording.
The three ownership models
Nearly every software deal lands on one of three structures.
| Model | Client gets | Agency keeps | Where it fits |
|---|---|---|---|
| 1. Client owns everything | Title to all work product, sometimes including tools the agency brought | Nothing unless a license back is negotiated | Enterprise paper, funded startups preparing for diligence |
| 2. Client owns deliverables, agency keeps background IP | Title to the custom work, plus a perpetual license to the agency’s components inside it | Libraries, frameworks, tools, know-how, generic code | Most custom development. This is the default I propose |
| 3. Agency owns, client is licensed | A license to use the software, exclusive or non-exclusive | Title to everything | Productized builds, platforms deployed for many clients, discounted work |
Model 1 is fine when it is priced. If a client wants title to everything including the tooling you carry from project to project, you either strip your tooling out and build from zero at their cost, or you charge for giving up the right to reuse it. What you cannot do is sign model 1 and then keep using your component library. Once assigned, it is theirs.
Model 2 matches what both sides want. The client gets clear title to the thing it paid to have built and the freedom to take it to another vendor. You keep the parts that were yours before you met and the general skills you sharpened along the way. It needs two things to work: a definition of background IP, and a list of which background components went into this build.
Model 3 is underused. If you are deploying your own platform with configuration on top, or building at a discount in exchange for keeping the product, the honest structure is a license. Clients in this model often ask for source code escrow, which is a reasonable request when they do not hold the source.
Which model applies to a given engagement is normally set in the master services agreement and can be varied per statement of work. A standalone software development agreement carries the same clause in one document.
The IP assignment and code ownership addendum
When the main contract is thin on IP, or it is the client’s paper and says “all work product” with no carve-outs, I attach an addendum. It implements model 2: deliverables assigned on full payment, background IP retained and licensed, a schedule listing the background components, a schedule for open source, a right to reuse generic code, and a firm wall around the client’s data and secrets.
IP Assignment and Code Ownership Addendum
This IP Assignment and Code Ownership Addendum (the "Addendum") is entered into on [EFFECTIVE DATE] between [AGENCY LEGAL NAME], a [STATE AND ENTITY TYPE] ("Agency"), and [CLIENT LEGAL NAME], a [STATE AND ENTITY TYPE] ("Client"). It supplements the [MASTER SERVICES AGREEMENT / STATEMENT OF WORK] between the parties dated [AGREEMENT DATE] (the "Agreement") and applies to [ALL STATEMENTS OF WORK UNDER THE AGREEMENT / STATEMENT OF WORK NO. X].
If this Addendum and the Agreement conflict on the ownership or licensing of intellectual property, this Addendum controls. Capitalized terms used and not defined here have the meanings given in the Agreement.
1.Definitions
1.1Deliverables means the software, source code, documentation, designs and other items that are identified as deliverables in a Statement of Work and delivered by Agency to Client, excluding Background IP, Third-Party Materials and Open Source Software.
1.2Background IP means all software, source code, libraries, frameworks, components, tools, templates, scripts, methods, processes and know-how that (a) Agency owned or controlled before the Effective Date, (b) Agency develops or acquires independently of the Services, or (c) is an enhancement, modification or derivative of any of the items in (a) or (b), whenever made. Background IP includes the items listed in Schedule A.
1.3Third-Party Materials means software, content or other materials owned by a third party and licensed commercially, other than Open Source Software. Third-Party Materials used in the Deliverables are listed in Schedule B.
1.4Open Source Software means software distributed under a license approved as open source or a similar public license that permits use, modification and redistribution of source code. Open Source Software used in the Deliverables is listed in Schedule B.
1.5Client Materials means all data, content, credentials, specifications, trademarks, software and other materials supplied to Agency by or on behalf of Client, and all data processed by the Deliverables on Client's behalf.
1.6Generic Components means portions of the Deliverables that are of general application, that are not specific to Client's business, products or processes, and that contain no Client Materials and no Confidential Information of Client. Examples include utility functions, interface components, integration wrappers, build and deployment scripts and test helpers.
1.7Full Payment means Agency's receipt in cleared funds of all Fees and approved expenses due under the Statement of Work to which the relevant Deliverables relate.
1.8Intellectual Property Rights means copyrights, patent rights, trade secret rights, database rights, design rights and all other intellectual property rights anywhere in the world, whether registered or unregistered.
2.Assignment of Deliverables
2.1Effective automatically upon Full Payment, Agency hereby assigns to Client all right, title and interest, including all Intellectual Property Rights, in and to the Deliverables under the applicable Statement of Work. No further document is required for the assignment to take effect.
2.2Where a Statement of Work provides for payment by milestone, the assignment in clause 2.1 takes effect for the Deliverables of each milestone when all Fees due for that milestone have been received by Agency.
2.3Until the assignment takes effect, Agency owns the Deliverables and grants Client a non-exclusive, non-transferable, revocable license to use them solely for testing, evaluation and acceptance. This license ends if Client fails to pay any undisputed amount within [30] days after its due date.
2.4The parties do not intend the Deliverables to be works made for hire. Ownership of the Deliverables passes to Client only by the assignment in this clause 2.
2.5The assignment in clause 2.1 does not include Background IP, Third-Party Materials or Open Source Software, each of which is dealt with in clauses 3 and 4.
2.6Agency confirms that each employee and contractor who contributes to the Deliverables has signed, or will sign before contributing, a written agreement that assigns to Agency all Intellectual Property Rights in that contribution.
2.7If the Agreement or a Statement of Work ends before completion, the assignment in clause 2.1 applies to all work in progress delivered to Client, effective when Client has paid all Fees due for Services performed up to the end date.
3.Background IP
3.1Agency retains all right, title and interest in the Background IP. Nothing in the Agreement or this Addendum transfers ownership of any Background IP to Client.
3.2Effective upon Full Payment, Agency grants Client a perpetual, irrevocable, worldwide, non-exclusive, royalty-free license to use, copy, modify and create derivative works of the Background IP solely as incorporated in or required to operate the Deliverables, for the purpose of using, operating, maintaining, supporting and enhancing the Deliverables.
3.3Client may sublicense the rights in clause 3.2 to its affiliates and to contractors working on Client's behalf, and may transfer the license together with the Deliverables to a successor to Client's business or to a purchaser of the Deliverables. Each sublicensee and transferee is bound by clause 3.4.
3.4Client will not extract Background IP from the Deliverables in order to distribute, license or commercialize it as a standalone product or as a development tool for third parties.
3.5Enhancements and modifications to Background IP made by Agency in the course of the Services are Background IP, are owned by Agency, and are licensed to Client under clause 3.2.
3.6Agency will list in Schedule A the Background IP it expects to use, and will deliver an updated Schedule A with the final Deliverables. An item that meets the definition in clause 1.2 is Background IP whether or not it is listed, provided Agency can show by reasonable evidence, such as repository history, that the item existed before the Effective Date or was developed independently of the Services.
3.7The license in clause 3.2 survives the expiry or termination of the Agreement for any reason, provided Full Payment has been made.
4.Third-Party Materials and Open Source Software
4.1Third-Party Materials and Open Source Software are licensed to Client by their respective owners under their own license terms. Agency does not assign or sublicense them except as those terms permit.
4.2Agency will identify in Schedule B each item of Third-Party Materials and Open Source Software included in the Deliverables, with its license, and will deliver an updated Schedule B with the final Deliverables.
4.3Agency will not incorporate into the Deliverables any Open Source Software under a license that would require Client to disclose, license or distribute the source code of the Deliverables to third parties, unless Client has approved that use in writing in advance.
4.4License fees for Third-Party Materials are payable by [CLIENT / AGENCY] as set out in the Statement of Work. After delivery, Client is responsible for complying with the license terms of Third-Party Materials and Open Source Software in its use of the Deliverables.
5.Reuse and Residual Knowledge
5.1Nothing in the Agreement or this Addendum restricts Agency or its personnel from using the general skills, knowledge, experience, ideas, concepts, techniques and know-how gained or used in performing the Services.
5.2Client grants Agency a perpetual, irrevocable, worldwide, non-exclusive, royalty-free license to use, copy, modify, create derivative works of, and license to others the Generic Components, for any purpose. This license takes effect at the same moment as the assignment in clause 2.1.
5.3Subject to clause 6, nothing in the Agreement or this Addendum prevents Agency from developing for itself or for others software that is similar in function to the Deliverables, provided Agency does so without using Client Materials or Client's Confidential Information.
5.4Agency will not reuse, or license to others, the Deliverables as a whole or any portion of the Deliverables that is not a Generic Component.
6.Client Confidentiality Carve-Out
6.1Nothing in clauses 3 or 5 permits Agency to use, disclose, reuse or license to others any of the following: (a) Client Materials; (b) personal data or any other data of Client or its customers; (c) credentials, keys, tokens, secrets or security configurations; (d) Client's trade secrets or Confidential Information; (e) business rules, algorithms or data models that are specific to Client's business; or (f) Client's name, trademarks or branding.
6.2Before reusing any Generic Component, Agency will remove from it all items described in clause 6.1, including from comments, configuration files, test fixtures and version history made available to any third party.
6.3If it is reasonably unclear whether a portion of the Deliverables is a Generic Component, Agency will treat it as a Deliverable owned by Client unless Client agrees otherwise in writing.
6.4The confidentiality obligations in the Agreement continue to apply and are not reduced by this Addendum.
7.Warranties
7.1Agency warrants that (a) it has the right to make the assignment in clause 2 and to grant the license in clause 3; (b) to Agency's knowledge, the Deliverables and the Background IP as delivered do not infringe the Intellectual Property Rights of any third party; and (c) Schedules A and B, as updated on delivery, are accurate to Agency's knowledge.
7.2Client warrants that it has the right to supply the Client Materials to Agency for use in the Services and that Agency's use of them as instructed by Client will not infringe the rights of any third party.
7.3The limitations and exclusions of liability in the Agreement apply to this Addendum.
8.Further Assurances and Moral Rights
8.1Each party will sign any documents and take any steps reasonably requested by the other party to perfect, record or confirm the rights assigned or licensed under this Addendum. The requesting party will pay the reasonable costs of doing so.
8.2To the extent permitted by law, Agency waives, and will obtain from its personnel a waiver of, all moral rights in the Deliverables. Where moral rights cannot be waived, Agency agrees that they will not be asserted against Client or its successors and licensees.
8.3On Client's written request after Full Payment, Agency will provide a short written confirmation of the assignment in clause 2.1 for Client's records.
9.General
9.1Clauses 2 through 8 survive the expiry or termination of the Agreement.
9.2This Addendum is governed by the law that governs the Agreement and is subject to the same dispute resolution terms.
9.3This Addendum may be amended only in writing signed by both parties. Schedules A and B may be updated by Agency on delivery as described in clauses 3.6 and 4.2.
9.4This Addendum may be signed in counterparts and by electronic signature.
Schedule A: Background IP
The following Background IP is used in or with the Deliverables.
| Component | Description | Where it is used in the Deliverables | Owner |
|---|---|---|---|
| [COMPONENT NAME AND VERSION] | [WHAT IT DOES] | [MODULE, SERVICE OR DIRECTORY] | Agency |
| [COMPONENT NAME AND VERSION] | [WHAT IT DOES] | [MODULE, SERVICE OR DIRECTORY] | Agency |
| [COMPONENT NAME AND VERSION] | [WHAT IT DOES] | [MODULE, SERVICE OR DIRECTORY] | Agency |
Schedule A last updated: [DATE]
Schedule B: Third-Party Materials and Open Source Software
The following Third-Party Materials and Open Source Software are included in or required by the Deliverables. A dependency manifest generated from the repository may be attached in place of individual rows.
| Component | Version | License | How it is used | Modified by Agency |
|---|---|---|---|---|
| [PACKAGE NAME] | [VERSION] | [LICENSE NAME] | [LINKED / BUNDLED / BUILD TOOL ONLY] | [YES / NO] |
| [PACKAGE NAME] | [VERSION] | [LICENSE NAME] | [LINKED / BUNDLED / BUILD TOOL ONLY] | [YES / NO] |
| [PACKAGE NAME] | [VERSION] | [LICENSE NAME] | [LINKED / BUNDLED / BUILD TOOL ONLY] | [YES / NO] |
Schedule B last updated: [DATE]
Signatures
The parties have signed this Addendum as of the Effective Date.
| Agency | Client |
|---|---|
| [AGENCY LEGAL NAME] | [CLIENT LEGAL NAME] |
| Signature: | Signature: |
| Name: [NAME] | Name: [NAME] |
| Title: [TITLE] | Title: [TITLE] |
| Date: [DATE] | Date: [DATE] |
Download the editable .docx
IP assignment and code ownership addendum, as a Word file you can change, with the clause notes at the back. Free. No email, no sign-up.
Download the fileOne question before your download starts.
Does your agency have any old repos?
You can license those to AI labs. Earn $500+ per repo.
It is free to check prices. Want to try?
Fair enough. One thing before you go.
This probably will not last. In three to six months AI may be good enough that code like yours stops selling at all. Checking what it is worth today is free.
See what you’d earnYour download has started. If it has not, download the .docx here.
How the addendum works in practice
The payment trigger (clause 2). Title moves when the fees for that statement of work are paid in full. Until then the client has a license to test and evaluate. Clients sometimes ask for assignment per milestone, which is a fair trade. Give it.
The background IP license (clause 3). The license is perpetual, non-exclusive and royalty-free, and it travels with the deliverables if the client sells the business. The client can modify your components and hand them to another vendor to maintain. The one restriction is that the client cannot pull your library out and distribute it as a separate product. Clients accept this once they see they lose nothing they need.
The schedules. Schedule A lists your background components by name. Schedule B lists open source and third-party packages with their licenses. Fill them in at signing and update them at delivery. A dependency manifest export covers most of Schedule B in ten minutes.
Reuse (clause 5). You keep your general know-how, and the client licenses back to you the generic, non-client-specific parts of the deliverables: a date utility, an authentication wrapper, a queue helper. Without this clause, a strict reading of the assignment would stop you writing the same helper function twice.
The confidentiality carve-out (clause 6). Nothing you reuse may contain client data, credentials, trade secrets or client-specific business logic. This is the clause that gets the client’s lawyer to accept clause 5, and it is also simply the right rule.
What you keep when the client takes the deliverable
Under model 2, and under any contract that left ownership with you, the agency ends each project still holding real property:
- Background IP: the libraries, starter kits, internal tools and deployment scripts you brought in.
- Improvements to that background IP made during the project, if the contract says so. The addendum does.
- Generic code licensed back to you.
- Whole projects where the contract was model 3, or where there was no assignment at all and the default rule left title with you.
- Internal products and experiments you built on your own time and money, including the ones you shelved.
And the list of what you do not hold is just as firm. Code a client owns under an assignment is the client’s. You cannot reuse it wholesale, and you cannot license it to anyone. Client data, credentials and confidential information are off limits whatever the ownership position. If a contract is ambiguous, treat the code as the client’s until a lawyer tells you otherwise.
What the retained code is worth
Most agencies have never counted what they hold. After ten years of projects there is typically a shelf of internal tools, two or three abandoned products, a component library, and a number of finished builds where the paperwork left title with the agency. On the balance sheet all of it is carried at zero.
It has value in three ways. Reused in your own delivery, it shortens every build that follows, which matters most on fixed-fee work where the hours you save are margin you keep (see fixed price versus time and materials). Packaged, some of it becomes a product. And because you own it, you can license it to third parties on a non-exclusive basis and still keep it, use it and license it again.
Start with an inventory. List every repository. Next to each, write the contract it was built under and which model applied. You will end up with three piles: clearly yours, clearly a client’s, and unclear. Only the first pile is available to license. The second is closed. The third needs the contract read properly before anything else happens.
You kept the IP on most of what you built, and it has a value you can find out. See what your repositories are worth.
The longer version of this argument, including why working code written by experienced teams has become more useful than it was a few years ago, is in what your old code is worth.
What to tell a client who asks “do we own it?”
Answer with the contract open. Under model 2 the answer is: “You own everything we built for you once the final invoice is paid. Our own components inside it are licensed to you forever at no extra charge, and they are listed in the schedule. You can take the whole thing to another vendor tomorrow.” Clients hear that as a yes, because for every practical purpose it is one. The ones who still want title to your toolkit are asking for model 1, and that conversation is about price.
This is a working document from a practitioner. Have a lawyer in your jurisdiction review it before you sign.
Common questions
- Who owns the code if there is no contract?
- In the US, the agency or contractor that wrote the code owns the copyright. The client holds an implied, non-exclusive license to use the code for the purpose it was built for. Paying the invoice does not transfer ownership. A transfer of copyright needs a written document signed by the owner.
- Does 'work made for hire' make the client the owner of custom software?
- Often it does less than the client thinks. For an independent contractor, work made for hire only applies to a short statutory list of work types plus a signed agreement, and custom software rarely fits the list. That is why well-drafted contracts add an express assignment as the operative clause.
- Can an agency reuse code it wrote for a client?
- It depends on the contract. Code the client owns under an assignment is the client's, and the agency needs a license back to reuse any part of it. Background IP, general know-how, and anything the contract left with the agency can be reused, provided no client data or confidential information travels with it.
- What is background IP?
- Background IP is code and other material the agency owned before the project or built outside it: libraries, frameworks, internal tools, scaffolding, deployment scripts. A good contract leaves it with the agency and gives the client a perpetual license to use it inside the deliverables.
- Does the client own the code before the final invoice is paid?
- Only if the contract says so. An agency-side contract makes the assignment effective on full payment, so ownership stays with the agency until the money arrives. If the clause assigns work product on creation, the client owns it whether or not it has paid.