Who Owns the Code When You Outsource Software Development?
Paying an invoice does not transfer a copyright. That single legal fact is behind most ownership disputes between businesses and their development partners and those disputes almost never surface during the build. They surface 12 to 24 months later, during a funding round, an acquisition, or a vendor switch, when a diligence lawyer asks for the chain of title and nobody can produce one.
The question of who owns the code when you outsource is a copyright question, not a commercial one. Under US law, and under similar principles in the UK, EU, and India, whoever writes the code is its author and first owner. Payment buys delivery. It does not buy the exclusive right to copy, modify, distribute, or sell. Only a signed written assignment does that and a striking share of outsourcing contracts, especially fixed-scope agreements under $75,000, either omit one or draft it so narrowly it covers less than half the codebase you shipped.
The Black Duck 2026 Open Source Security and Risk Analysis (OSSRA) report, based on 947 commercial codebases across 17 industries, found that 68% of audited codebases contain open-source licence conflicts up from 56% the previous year, the largest single-year jump in the study’s 11-edition history. Open source now appears in 98% of codebases.
Read that figure alongside your assignment clause and the gap is obvious. A perfect transfer of everything your agency wrote still leaves you holding a licence problem in the code they merely imported. Ownership is layered; most contracts address only the top layer.
This article is general commercial information for buyers of IT services. It is not legal advice, and jurisdictional rules differ. Have counsel qualified in your governing-law jurisdiction review any agreement before you sign it.

What “Who Owns the Code When You Outsource” Actually Means
Who owns the code when you outsource is a copyright question resolved by contract, not by payment. By default, the developer or agency that authors the code is its first legal owner. Ownership passes to the client only through an express written assignment that covers deliverables, pre-existing components, and third-party or open-source dependencies.
Each of those three parts fails independently. A contract can assign the deliverables perfectly and still leave you licensing your own architecture back from the agency that built it, a risk that does not exist in the same form when you weigh in-house vs outsourced software development, because employee-authored work defaults to the employer.
Why Transfer of IP After Payment Is the Most Expensive Assumption in Outsourcing
The transfer of ip after payment is not automatic in any major jurisdiction. Under Section 101 of the US Copyright Act, a work qualifies as “made for hire” in only two situations: it was created by an employee within the scope of employment, or it was specially commissioned, falls within one of nine enumerated statutory categories, and both parties signed a written agreement saying so.
Software is not one of those nine categories. Neither is source code, an application, or a database. This is the detail that catches procurement teams: a contractor agreement can carry a beautifully drafted work-for-hire paragraph and still move nothing, because the statute does not reach that category of work.
The cost of discovering this late is measurable. Technical due diligence typically runs 3 to 6 weeks; a broken chain of title adds 4 to 10 weeks while retroactive assignments are chased, plus $8,000 to $40,000 in outside counsel time for a mid-sized codebase which is why IP sits near the top of any serious software development contract checklist.
Your leverage is also gone. Before you pay, an assignment clause costs one email. After launch, the agency knows what the signature is worth to you retroactive assignments in live deal situations get negotiated at 15% to 40% of original project value, and some agencies simply decline, because the reusable framework inside your product is their next five projects.
Three failure patterns account for most of these situations:
- The contract has no IP clause at all, only payment terms, scope, and a confidentiality section
- The clause assigns “deliverables” without defining whether deliverables include source code, build scripts, infrastructure-as-code, and design files
- The clause assigns everything the agency wrote but is silent on the frameworks, libraries, and boilerplate they brought with them

IP Ownership in Outsourced Software: The Five Layers a Contract Must Cover
Treating ip ownership outsourced software as one yes/no question is what produces incomplete contracts. A shipped application is a stack of legally distinct components with different owners, and a competent agreement like a competent process for protecting IP while outsourcing software development addresses each separately.
Layer 1: Newly Written Deliverable Code
This is the layer everyone remembers: application code, database schemas, API integrations, test suites, CI/CD configuration, and documentation written specifically for your project.
A properly drafted clause does two things: it states the work-for-hire position where it applies, then adds a present-tense assignment as a fallback for everything that does not qualify. The fallback is the part that actually works for software.
Relying on work for hire software development language alone is the single most common drafting error in IT outsourcing contracts, and it is entirely avoidable with one extra sentence the difference between a licence and owning your code completely when outsourcing.
Layer 2: Background IP and Pre-Existing Components
No agency builds from zero. A team that has delivered 40 marketplace projects has an internal authentication module, a payments wrapper, an admin scaffold, and a deployment pipeline. They will reuse them, and they should say that reuse is why your build took 11 weeks instead of 24.
The contract needs a named, listed schedule of that pre-existing IP, plus a perpetual, irrevocable, worldwide, royalty-free, sublicensable licence for you to use, modify, and distribute it as part of your product. Without the sublicence right, you cannot legally resell your own product to customers, a constraint that quietly rewrites every projection in your SaaS development cost model.
Insist on the schedule as an exhibit before signing. A vendor who refuses to enumerate their background IP is reserving the right to define it later, once their framework is load-bearing inside your product which is exactly when who owns the code when you outsource becomes an expensive conversation.
Layer 3: Developer Retains Rights Code You Paid For but Cannot Control
Some agreements deliberately keep ownership with the vendor and grant the client a licence instead. That is legitimate for white-label platforms and productised services, but it should be a choice, not a surprise.
The practical test is not who holds the copyright it is what you can do without asking permission. A non-exclusive licence lets the agency build the same product for your competitor next quarter. A non-transferable one hands an acquirer a consent requirement, making your vendor a party to your exit.
This is where who owns the code when you outsource stops being an abstract legal question and starts setting a ceiling on your valuation.

Layer 4: Open-Source Components and Third-Party Licences
Your agency cannot assign what it never owned. Every MIT, Apache 2.0, GPL, and AGPL component arrives with obligations attached, and those obligations survive any assignment clause you sign.
The material risk is copyleft. A GPL-licensed library linked into a distributed product can trigger an obligation to release your own source under GPL terms, and an AGPL component reaches even hosted SaaS delivery. Neither is theoretical at a 68% conflict rate across audited codebases.
Contractually you need three things: a warranty that no copyleft component entered distributed code without written approval; a delivered software bill of materials (SBOM) listing every direct and transitive dependency with its licence; and an indemnity for third-party IP claims capped at a number that means something relative to project value.
Commercial licences deserve the same treatment. Paid UI kits, mapping SDKs, and reporting engines are frequently registered to the agency’s account to ask who the licensee of record is, whether the seat transfers on completion, and whether renewal sits inside or outside the quoted custom software development cost.
Layer 5: AI-Generated Code and the New Provenance Gap
AI coding assistants have added a layer that most 2022-era contract templates do not contemplate. The 2026 OSSRA data attributes part of the licence-conflict surge to code entering codebases outside standard package managers, pasted snippets, direct inclusions, and AI generation which manifest-scanning tools cannot see. It is the fastest-moving item in current software development outsourcing trends.
Two clauses close the gap: a disclosure requirement naming which AI tools were used and where, and an unmodified IP warranty covering the deliverables regardless of how they were produced. Never accept an AI carve-out from that warranty. A vendor who will not stand behind the output is transferring provenance risk to you at no discount.
The Source Code Ownership Clause: Exact Language to Look For
A workable source code ownership clause contains four elements. Read your MSA against this list; if any element is missing, it is a redline, not a preference.
- Present-tense assignment with a work-for-hire fallback. Look for wording in this shape:
“All Deliverables shall be considered works made for hire. To the extent any Deliverable does not qualify as a work made for hire under applicable law, Vendor hereby irrevocably assigns to Client all right, title, and interest worldwide in and to such Deliverable, including all copyrights, patent rights, trade secrets, and moral rights, effective upon creation.”
The phrase carrying the weight is hereby irrevocably assigned. “Agrees to assign” or “shall assign” creates a future promise requiring a second signature you may never get.
- Vesting that does not depend on a dispute. Payment-conditional assignment is fine in principle, but it must state that ownership vests automatically on payment with no further action required. Otherwise a disputed final invoice freezes your entire IP position.
- A defined deliverables list. “Deliverables” should expressly include source code, object code, build and deployment scripts, infrastructure configuration, database schemas, design files, documentation, and work in progress including code written but not delivered. Mirror the wording used in your statement of work for software development so the two documents cannot be read against each other.
- Further assurances and repository control. The vendor agrees to sign whatever perfects the transfer, and to hand over repository administrator rights, domain registrations, cloud accounts, API keys, and app-store credentials within a stated number of days.
How to Check if Your Outsourcing Contract Transfers IP: A 9-Step Review
Work through this sequence before signature and again at closeout. It takes roughly 90 minutes, and it is the highest-return 90 minutes in the engagement.
- Locate the IP clause. Confirm it sits in the MSA, not only in a SOW that later SOWs may supersede.
- Check the verb. “Hereby assigns” is self-executing; “will assign” is a promise. Redline the promise.
- Read the deliverables definition. If source code and repositories are not named explicitly, name them.
- Find the background IP schedule. No exhibit listing pre-existing components means no schedule exists.
- Verify the background IP licence scope. Perpetual, irrevocable, worldwide, royalty-free, sublicensable, transferable on change of control.
- Confirm the SBOM obligation. A dependency list with licences at each milestone, not only at final delivery.
- Check the copyleft warranty. No GPL or AGPL in distributed code without written approval.
- Read the IP indemnity cap. Fees-paid caps are standard; for a product-critical build, negotiate above contract value or uncapped for IP claims.
- Confirm the handover schedule. Admin rights, credentials, and further-assurance documents, with a deadline tied to a payment milestone.
Answering who owns the code when you outsource costs nothing before signature. Litigating it afterwards is a five-figure exercise with an uncertain outcome, which is why handover deserves the same rigour you apply to milestone payments in software development.

Case Studies: What This Looks Like in Practice
A logistics SaaS at Series A. A 30-person startup outsourced its dispatch platform to an offshore agency across 14 months and roughly $210,000 in fees. The MSA assigned “all deliverables” but listed no background IP, and diligence found the agency’s proprietary routing engine at the centre of the product. Renegotiating a perpetual sublicensable licence cost $46,000 and delayed the round by seven weeks, a bill with a two-line schedule at kickoff would have been erased.
An enterprise vendor switch. A retail group moving its e-commerce integration layer to a new partner found the previous agency owned the AWS account, the private repository, and three commercial SDK licences. With a handover schedule but no further-assurance clause, the transition ran 5 weeks instead of 2, and re-licensing the SDKs added $12,400. The replacement contract ties credential handover to the final 20% payment milestone, and account ownership is now checked during technical vetting of the development company rather than at closeout.
Decision Framework: Four Ownership Models Compared
Full assignment is the right default for most product builds, but it is not the only defensible structure. Match the model to what you are actually buying.
| Ownership model | What you get | Main risk | Best fit |
| Full assignment + background IP licence | Copyright in all custom code; perpetual sublicensable licence to vendor frameworks | Requires a complete background IP schedule to be meaningful | Funded startups, product companies, anything with an exit path |
| Full assignment, no reuse rights for vendor | Exclusive ownership; vendor cannot reuse anything built | 20–35% higher cost; some agencies will decline | Proprietary algorithms, regulated systems, competitive differentiators |
| Perpetual exclusive licence to client | Unlimited use and modification; vendor retains copyright | Weak position in M&A diligence; assignability questions | Internal tooling with no resale or exit plan |
| Vendor-owned, client licensed | Fast, cheap delivery on a proven platform | Vendor can serve competitors; you cannot fork or migrate freely | White-label products, short-lifecycle marketing builds |
In the middle two rows, negotiate source code escrow with a named agent, released on defined triggers such as insolvency, acquisition, or sustained support failure. Escrow does not settle who owns the code when you outsource, but it removes the worst case: a vendor disappearing with the only working copy.
What Most Teams Get Wrong
The dominant mistake is not ignorance of IP clauses. It is sequencing. Teams treat who owns the code when you outsource as a legal formality to settle after the commercial terms are agreed which means they raise it once the vendor is selected, the timeline is committed, and the leverage has quietly moved to the other side of the table.
Ownership terms should be a vendor selection criterion, not a post-selection negotiation. Ask for the standard IP clause during shortlisting, alongside rates and portfolio. It costs one line in your software development RFP and it filters out vendors whose business model depends on retaining your code.
The second pattern belongs to bidding marketplaces. When agencies compete on price under platform commission pressure of 10–20%, margin gets recovered somewhere often through reuse rights, because the boilerplate they keep is what makes a below-cost bid viable. That is arithmetic, not bad faith, and it is a structural difference worth understanding in agency marketplaces vs direct matching. The cheapest bid and the weakest assignment clause tend to arrive in the same proposal.
The third is treating verification as separate from ownership. An agency with a registered entity, traceable domain, checkable client history, and named team members can be held to an indemnity. An unverified vendor operating through a personal account cannot, however strong the clause reads. The enforceability of your contract is capped by the substance of your counterparty, which is why vendor vetting and IP protection are one exercise, not two.
Finally, scope drift affects the assignment itself. A clause signed against SOW #1 rarely covers the three change orders that follow to confirm at every SOW that the master IP terms flow through.

Before You Sign the Next SOW
This question gets settled cheaply or expensively, and the difference is entirely when you ask it. Put the assignment clause, the background IP schedule, and the SBOM obligation into your shortlisting criteria. The same 72-hour discipline described in how to shortlist an IT agency and who owns the code when you outsource stops being a diligence discovery and becomes a procurement checkbox.
If you are comparing development partners now, GetProjects connects businesses directly with verified IT companies with no bidding wars, no platform commission, and agency profiles vetted across website, domain, reviews, and team details before they go live. Post a project in under two minutes, ask every shortlisted agency for their standard IP clause, and compare the answers side by side.
The agencies that send it back the same day are usually the ones worth talking to.
FAQ
Do I own the code if I paid for it?
Not automatically. Payment is consideration for services; it does not transfer copyright by itself in the US, UK, EU, or India. Ownership moves only through an express written assignment signed by the party that created the work. A contract with payment terms but no assignment clause likely leaves the developer as legal owner, whatever you paid.
Is a “work for hire” clause enough for software?
On its own, no. US law limits work-for-hire treatment of commissioned works to nine statutory categories, and software is not among them. A work-for-hire paragraph without a present-tense assignment fallback can fail entirely. The reliable construction states the work-for-hire position and then adds “to the extent any Deliverable does not qualify, Vendor hereby irrevocably assigns…”
Who owns the code an offshore development team writes?
Governing law and enforcement venues decide this more than geography does. Most jurisdictions default ownership to the author, so the analysis is unchanged: an express assignment, a named governing law, and a realistic enforcement route. Confirm the contracting entity is a registered company you could actually pursue.
Can a development agency reuse your code for another client?
It depends on what the contract permits. With a full assignment and no reuse carve-out, they cannot reuse your custom code. With a licence-back or an unlisted background IP claim, they often can include competitors. If exclusivity matters, add an explicit non-reuse covenant and expect to pay 20–35% more.
What is a source code ownership clause?
It is the provision transferring copyright and related rights in the code from vendor to client. A complete version includes a present-tense assignment, a deliverables list covering source code and repositories, a moral rights waiver where the jurisdiction recognises them, and a further-assurance obligation.
What happens to your IP if the agency shuts down?
If the assignment was properly executed and effective upon creation, you already own the code but you can still lose access to repositories, credentials, and environments held in the vendor’s accounts. Escrow with a named agent, plus a contractual requirement to mirror the repository weekly to client-controlled infrastructure, are the practical protections. Raise both during vendor selection, not at closeout.