IP Ownership in Software Contracts: Who Owns the Code?

Paying for custom software does not transfer IP ownership. In the US, the UK and most of the EU, the developer who writes the code owns the copyright until a signed written assignment moves it — and software almost never qualifies as work made for hire.

That single rule surprises most founders and procurement teams. You funded the project, you approved every screen, your logo sits in the header. Then you decide to switch vendors, raise a round, or resell the platform to a second customer, and a lawyer asks to see the IP ownership clause. If it says the wrong thing, or says nothing, your options shrink fast.

The UK Intellectual Property Office puts the default rule plainly: when you commission a work, "the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing" (GOV.UK). US law reaches the same place through a different route. Neither route treats your payment as a transfer of IP ownership.

This guide covers IP ownership from the client's side of the table: what the default rules actually say, which clauses move ownership, which parts of your codebase you will never own, and what a delivery package has to contain before the hand-over counts as real.

Table of Contents

• Why Paying for Code Does Not Transfer Ownership
• The Work-for-Hire Myth in US Contracts
• UK and EU: Commissioning Is Not Buying
• Assignment, Licence or Joint Ownership?
• Foreground IP vs Background IP
• Open Source Is Already in Your Codebase
• AI-Generated Code Breaks the Chain of Title
• Nine Clauses to Get in Writing
• What Delivery Must Actually Include
• Registration, Escrow and Enforcement
• Frequently Asked Questions

Why Paying for Code Does Not Transfer Ownership

Copyright attaches to the code the moment a developer writes it, and it attaches to the person who wrote it. Nothing about an invoice, a purchase order or a statement of work changes that starting point.

US law makes the transfer requirement explicit. Section 204(a) of the Copyright Act states that a transfer of copyright ownership "is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed" (17 U.S.C. §204). An oral promise, a Slack message or a paid invoice will not do it.

Two consequences follow. First, without a signed assignment the developer keeps IP ownership and you hold, at best, a licence. Second, that licence may be narrower than you assume — courts may imply only a limited, non-exclusive right to use the software for the purpose you commissioned it for.

A non-exclusive licence creates a specific commercial problem. Your vendor can reuse the same code for another client, including a competitor, and you cannot stop them. If your software is a differentiator rather than a cost centre, the IP ownership clause is the clause that protects it.

The Work-for-Hire Myth in US Contracts

Plenty of development agreements still rely on a line that says the deliverables "shall be considered a work made for hire." For software, that line usually does nothing.

The Copyright Act defines a work made for hire in two ways: a work an employee prepares within the scope of employment, or a work specially ordered or commissioned in one of nine listed categories. The nine categories are a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, and an atlas.

Software is not on that list. The Copyright Office sets out four conditions for commissioned works and then closes the door: "If a work fails to satisfy any of these requirements, it is not a work made for hire" (Circular 30).

So a contractor's code falls outside the doctrine, no matter what the agreement calls it. IP ownership stays with the contractor until an assignment moves it. The employee branch still works — if your own staff write the code within the scope of their jobs, your company owns it from the start. For every freelancer, agency and offshore team, you need an assignment instead.

Practical drafting advice from US practitioners is to use both: an express assignment as the operative clause, with work-for-hire language as a fallback that costs nothing if it fails. Write the assignment so it survives on its own.

UK and EU: Commissioning Is Not Buying

Under the Copyright, Designs and Patents Act 1988, "the author of a work is the first owner of any copyright in it." Section 11(2) carves out employees: where an employee makes a work in the course of employment, the employer is the first owner, subject to any agreement to the contrary (CDPA s.11).

Section 11 says nothing about commissioned works, and that silence settles the IP ownership question by default. A contractor working under a contract for services keeps copyright in what they produce unless the contract says otherwise. GOV.UK warns that where the contract ignores copyright, a commissioner "may only get a limited non-exclusive licence."

Most EU member states follow the same logic for software written by contractors, and they add a wrinkle US buyers often miss: moral rights. In many civil-law systems the author keeps rights of attribution and integrity that no assignment can remove. You can usually agree a waiver of their exercise, but you cannot buy the rights themselves.

That matters for two practical items. Credit lines in the footer or the repository, and the freedom to modify the work substantially later, both touch moral rights. Address them in the contract rather than discovering them during a dispute.

Assignment, Licence or Joint Ownership?

"The client owns everything" is a slogan, not a clause. Four different IP ownership arrangements hide behind it, and they carry very different consequences.

Write the assignment so it names what it transfers: the right to reproduce, modify, create derivative works, distribute, publicly display and publicly perform the software, plus the right to sublicense and to assign those rights onward. Say it is worldwide, perpetual, irrevocable and royalty-free.

Add timing. An assignment of code that does not exist yet is fragile in several jurisdictions, so tie the transfer to delivery and payment of each milestone, and sign a short assignment confirmation at each acceptance. A one-paragraph confirmation that names the release and the commit hash removes most future arguments about IP ownership.

Finally, deal with onward transfer. If you may sell the company, merge the asset into a group entity or license it to customers, say so in the clause. A silent contract invites a renegotiation at the worst possible moment.

Foreground IP vs Background IP

No competent team starts from an empty folder. They bring their own authentication module, form library, deployment scripts and internal utilities. Those are background IP, and demanding ownership of them is usually unrealistic.

The workable split is simple. Foreground IP — everything created specifically for your project — transfers to you, and that transfer is the IP ownership you actually need. Background IP stays with the vendor, and you take a perpetual, worldwide, royalty-free, sublicensable and assignable licence to use it as part of the delivered software.

Then ask for the list. A good vendor can name their reusable components in an afternoon; a vendor who refuses to list them is telling you something. Without the list you cannot tell which parts of the system you may rewrite, replace or hand to another team.

Three more categories sit outside both buckets, and contracts routinely forget them. Commercial fonts and stock assets come with their own licences, often per-seat or per-domain. Third-party SaaS and API dependencies stay on the provider's terms. And anything your own team contributed — content, data, brand assets — should be carved out as yours.

Open Source Is Already in Your Codebase

Even a perfect IP ownership clause only moves what your vendor can lawfully transfer. Most of a modern web application comes from open source packages that arrive with their own licences, and those licences do not change hands.

The scale here is easy to underestimate. Black Duck's 2026 OSSRA report audited 947 codebases submitted between November 2024 and October 2025. Only 2% of them contained no open source at all, and 68% contained licence conflicts, up from 56% a year earlier (OSSRA 2026). One audited codebase held 2,675 distinct conflicts.

Two further findings belong in your contract review. Around 17% of open source components now enter codebases outside traditional package managers, so manifest-based scanning misses them. And only 54% of organisations evaluate AI-generated code for IP and licensing risk before it lands in the repository.

The risk is not open source itself — it is the licence mix. Permissive licences such as MIT, BSD and Apache 2.0 sit comfortably in commercial products. Copyleft licences such as the GPL require you to release derivative works under the same terms when you distribute them (GNU on copyleft). Running software internally triggers far fewer obligations than shipping it to customers.

So ask for three things at delivery: a software bill of materials listing every component and its licence, a warranty that those licences fit the use you described, and a commitment to replace any component that does not. Tell your vendor up front whether you intend to distribute, resell or white-label the product, because that single fact changes which packages they should choose.

AI-Generated Code Breaks the Chain of Title

Assistants now write a meaningful share of production code, and that creates a gap in the chain of title that contracts written three years ago do not address.

US registration practice is already clear on the principle. The Copyright Office states that if a work's traditional elements of authorship "were produced by a machine, the work lacks human authorship and the Office will not register it" (Copyright Office AI guidance). Protection attaches to the human-authored parts of a mixed codebase, not to raw generated output.

For you as the buyer, the IP ownership consequence is narrow but real. You cannot assert exclusivity over material that no one owns, which weakens your position against a competitor who ships something similar. It also means an assignment clause can transfer less than both parties assumed.

There is a second exposure running the other way. If a model reproduces copyleft-licensed code without carrying its licence metadata, that obligation still travels with the code. Black Duck calls this pattern "licence laundering," and it is part of why conflict rates jumped.

Handle it with disclosure rather than prohibition. Ask the vendor to state which tools they use, to confirm that humans review and materially shape generated code, and to warrant that outputs do not knowingly incorporate third-party code under incompatible licences. Banning assistants outright is unenforceable and usually just moves the practice out of sight.

Nine Clauses to Get in Writing

The table below is the IP ownership checklist to run through before signing a software development contract, with the failure mode for each line.

Line 9 earns its place more often than any other. Projects stop for commercial reasons, not just technical ones, and a vendor with no exit obligation holds considerable leverage. A sentence setting a fixed hand-over window turns that leverage into an administrative step. Our guide on choosing a software development company covers how vendors react to this clause during selection.

What Delivery Must Actually Include

IP ownership without technical transfer is a receipt for something you cannot use. If you own the copyright but cannot build and deploy the system, you are still dependent on the vendor who can.

Specify the hand-over in the contract itself:

• Repository ownership. Create the repository in your own organisation on day one. The vendor's team joins as collaborators, not owners.
• Accounts in your name. Domain, DNS, cloud, CI/CD, monitoring, app store and payment provider accounts all belong to your legal entity.
• A build and deploy runbook. Steps that take a new engineer from clone to production, with runtime versions and a full environment variable list.
• Architecture and data documentation. Module map, database model, integration diagram, API reference.
• Secrets handling. Where keys and tokens live, and a rotation step at hand-over.
• Signed assignment confirmation. The delivered release and commit reference, named in writing.

For systems your operations genuinely depend on, add source code escrow. A neutral agent holds an encrypted deposit and releases it to you when defined conditions occur, such as the vendor ceasing to trade or failing to provide support. Write the release triggers precisely, because vague conditions like "ceases business" rarely fire cleanly, and budget for periodic verification that the deposit actually builds.

Two related documents round out the package. Support, response times and fees belong in a separate software maintenance agreement, since owning the rights creates no obligation to maintain anything. And if your product is a mobile app, the hand-over has its own failure modes, which we covered in app source code ownership.

Registration, Escrow and Enforcement

Copyright exists from the moment of creation, so registration is never a precondition for IP ownership. In the US it is, however, a precondition for enforcing it.

Section 411(a) bars a civil infringement action for a US work "until preregistration or registration of the copyright claim has been made." Section 412 goes further on remedies: statutory damages and attorney's fees require registration before the infringement began, or within three months of first publication (17 U.S.C. ch. 4).

The cost is modest. Electronic filing runs $65 for the Standard Application, or $45 for the single-author Single Application, at the time of writing (Copyright Office fees). The Office has proposed increases, so check the schedule before you file.

Registration only helps if you hold the rights, which brings the argument back to the assignment clause. Register after the assignment confirmation is signed, record the chain of title in your own files, and keep the component list with it. Teams that skip this step tend to discover the gap during due diligence, when software projects already under pressure can least afford a delay.

One closing caveat: this article is general information, not legal advice. The statutes and official guidance quoted here come from primary sources, but IP ownership rules differ by jurisdiction and your contract will be read against the law you chose. Have an IP lawyer review the clauses before you sign.

Frequently Asked Questions

I paid for the software — do I own the code?

Not automatically. Payment buys the deliverable, not the copyright. In the US a transfer requires a signed writing under 17 U.S.C. §204(a), and in the UK a commissioner owns nothing unless the contract says so. Without an assignment clause you hold a licence whose scope a court would have to infer.

Does a work-for-hire clause give me IP ownership of software?

Usually not, if a contractor wrote it. US law limits commissioned works made for hire to nine categories, and software is not among them. The clause works for your own employees acting within the scope of their jobs. For contractors, rely on an express assignment and treat work-for-hire wording as a fallback.

Can the agency reuse my code for another client?

It depends on what you signed. Under a non-exclusive licence they can, including for a competitor. Under a full assignment they cannot reuse the foreground IP, though they keep the right to reuse their own background components. The component list is what makes that boundary auditable.

Do open source libraries affect my IP ownership?

Your project-specific code remains yours, but open source components stay under their own licences. The practical risk is copyleft obligations triggered by distributing the software. Ask for a software bill of materials, a licence inventory and a warranty that the mix suits how you intend to use the product.

What should an IP assignment clause actually list?

Name each right you are taking: reproduction, modification, derivative works, distribution, public display and public performance, plus sublicensing and onward assignment. State that the grant is worldwide, perpetual, irrevocable and royalty-free, and tie the transfer to acceptance and payment of each milestone.

Who owns code written by an AI assistant?

Nobody owns purely machine-generated output in the US, because registration requires human authorship. Protection covers the human-authored parts of a mixed codebase. Ask your vendor to disclose tool use, confirm human review and warrant that outputs carry no incompatible third-party licences.

Is source code escrow worth the cost?

It is worth it when a single system carries operations you cannot pause, and when the vendor will not transfer rights outright. Escrow does not replace an assignment clause; it protects availability rather than ownership. Insist on precise release triggers and periodic verification that the deposit builds.

IP ownership is a contract problem, not a technical one. Teams ship excellent software under agreements that quietly leave the rights somewhere else, and the gap only surfaces years later during a vendor change, an acquisition or a resale decision. Three habits close it: name the rights you are taking, sign an assignment confirmation at every delivery, and demand a component list with the code.

We run software projects with the contract and hand-over terms spelled out from the start. Take a look at our web software development services, or get in touch to talk through the IP ownership and delivery clauses for your own project.