Code Ownership and IP Assignment for Contractors: 2026 Guide

TL;DR

If a contractor writes code for your product, you do not automatically own it just because you paid for it. Under U.S. copyright law, the author owns the work first, and transferring those rights requires a signed agreement with present-tense assignment language. Relying on “work made for hire” alone is risky for software contractors because only specific statutory categories qualify. Get the contract right before the first commit, not during your Series A.

Legal note: This is general information, not legal advice. Contract enforceability depends on jurisdiction, facts, and exact wording. Consult qualified counsel for your situation.

What Does “Code Ownership” Actually Mean?

Code ownership refers to the legal rights over software source code and related intellectual property. The person or company that owns the code holds the right to copy, modify, distribute, commercialize, sublicense, and enforce protections over it.

This is about more than who has the GitHub login.

The U.S. Copyright Office confirms that copyright protects original works of authorship, including computer software, but does not protect facts, ideas, systems, or methods of operation source. The Copyright Act defines a “computer program” as a set of statements or instructions used in a computer to bring about a result source. Source code (the human-readable version) is distinct from object code (compiled, machine-readable code).

What this means in practice: owning the code gives you control over the written software itself. It does not necessarily give you ownership of every abstract idea, feature concept, or business method behind the product. And critically, it does not mean you own the contractor’s pre-existing tools or third-party libraries baked into your app.

What Is IP Assignment?

IP assignment is the legal transfer of ownership rights from one party to another. When a contractor assigns intellectual property to your company, they are handing over their rights, not just giving you permission to use the work.

This is different from a license. A license says “you can use this.” An assignment says “you own this now.”

For copyright, that transfer must be documented in a signed writing source. Patent assignments also require a written instrument source. Oral agreements and handshake deals are not sufficient for copyright ownership transfer under U.S. law.

Orrick, one of the most respected startup law firms, puts it plainly: U.S. IP laws do not guarantee that IP created for a company will be owned by that company without a written agreement that transfers rights source.

The contract should also address patents, trade secrets, documentation, designs, and data models. Code ownership and IP assignment for contractors is not just about copyright. It covers the full spectrum of what gets created during a software project.

Who Owns Code Written by a Contractor by Default?

This is where most founders get surprised.

Under 17 U.S.C. § 201(a), copyright in a protected work initially vests in the author source. For contractor-created software, the author is typically the individual developer or agency, not the company paying for the work.

A&O Shearman, in their analysis across multiple jurisdictions, confirms that contractor-developed IP is generally owned by the contractor absent a valid assignment, with limited exceptions source.

Here is a concrete example: a founder pays a freelance developer $40,000 to build the first version of a SaaS app. The app works. The founder has repo access and a deployed product. But without a signed IP assignment, the freelancer may still own the copyright in every line of code. The founder has a product they can use but might not legally control.

This table breaks down the most common situations:

For startups building MVPs and hiring external developers, understanding these defaults is not optional. It is the difference between owning your product and renting it. If you are evaluating how to work with a development agency, make sure IP ownership terms are part of the conversation from day one.

Why “Work Made for Hire” Is Not Enough

Many contractor agreements include a clause saying “all deliverables are work made for hire.” That sounds definitive. It often is not.

For employees, the work-made-for-hire doctrine works well. Code written within the scope of employment generally belongs to the employer.

For independent contractors, U.S. copyright law is much narrower. The work must be specially ordered or commissioned, must fall within one of nine statutory categories, and must be designated as work made for hire in a signed written agreement. Those categories include things like contributions to collective works, parts of audiovisual works, translations, and compilations. “Custom software application” is notably absent from the list.

Willcox Savage, in their analysis of software development agreements, warns that merely calling software deliverables “work made for hire” may not be sufficient because commissioned works must fit those statutory categories source.

The practical approach: include work-made-for-hire language as a fallback if counsel advises it, but always pair it with a direct IP assignment. Do not treat “work for hire” as a magic phrase that solves contractor code ownership.

The “Magic Words”: Present Assignment Language

This is arguably the most important section for anyone drafting or reviewing a contractor agreement. The difference between a present assignment and a future promise to assign has been litigated at the highest levels of U.S. courts.

The distinction matters: saying “contractor will assign” or “contractor agrees to assign” can be interpreted as a promise to do something later, not as an immediate transfer. If the contractor never follows through, or if a third party gets involved first, the company may not hold clean title.

Multiple authoritative sources confirm this. Cooley says contractor agreements must include a present assignment of IP source. Orrick says assignments must include present-tense language to be valid. Willcox Savage explains that language like “agrees to assign” may imply a future act.

The case law is instructive:

• In Stanford v. Roche, the Supreme Court examined a situation where Stanford’s earlier “agree to assign” language was trumped by a later agreement using present assignment wording. The language difference affected who held rights source.

• In Omni MedSci v. Apple, the Federal Circuit held that “shall be the property of” language was, at most, a future agreement to assign, not a present automatic transfer source.

Think of it this way: a promise to sign a deed on a house is not the same as signing the deed right now.

Weak wording: “Contractor will assign all rights to Company.”
Stronger concept: “Contractor hereby assigns all right, title, and interest in the work product to Company.”

Have counsel draft the actual clause for your jurisdiction and deal. The point here is to understand why the tense of a single verb can determine whether your company owns its own product.

Code Ownership vs. Source Code Delivery

Owning the code and receiving the code are two different things. A signed IP assignment says your company holds the legal rights. But if you cannot access the source code, build the project, or deploy updates, the legal rights alone will not keep your product running.

Community discussions make this painfully clear. A question on Law Stack Exchange asked whether a client-owned IP clause automatically required source-code delivery source. The answer is no, not unless the contract says so. Practitioners on Reddit’s r/Upwork and r/webdev forums regularly describe disputes where clients assumed “IP ownership” meant they would receive editable source files, only to learn the contract never specified delivery format.

A good software contract should define both ownership and delivery. The IP clause covers legal rights. The statement of work or handoff clause should list what gets delivered.

Source Code Handoff Checklist

• Repository access and ownership transfer

• Full commit history

• Build and run instructions

• Deployment process documentation

• CI/CD pipeline configuration

• Infrastructure-as-code files

• Environment variables and secrets rotation process

• Cloud account ownership transfer

• Package manager and container registry access

• Database schema, seeds, and migrations

• Test suite

• Architecture decision records and documentation

• Dependency and open-source license inventory

• Admin accounts and credential rotation

• Warranty or support period terms

If you are working with a development partner, this handoff should be part of the project plan from the start, not an afterthought. Startups that struggle with common technical challenges often find that incomplete handoffs compound every other problem.

Background IP, Reusable Code, and Contractor Tools

This is the most under-discussed issue in contractor IP assignment, and where the most disputes start.

Contractors and agencies bring pre-existing code to projects all the time. Starter kits, internal frameworks, deployment scripts, testing harnesses, design systems, boilerplate templates. This is their “background IP,” the tools and code they had before your project existed.

If your contract says “company owns all IP,” you might accidentally claim ownership of tools the contractor needs for every other client engagement. That is not fair, and in many cases it is not what either side intended.

The reverse problem is equally dangerous. If the contractor retains too much, the client may not have sufficient rights to modify, maintain, or sell the product independently.

Practitioners on Dev to Agency recommend being explicit: agencies should make clear when they use in-house code, plugins, or components, and those parts should remain reusable by the agency source.

A detailed post in Reddit’s r/ContractManagement described the most common disputes: clients demanding source files not specified in the contract, agencies reusing internal frameworks without disclosure, no distinction between deliverables and background tools, and unclear ownership-transfer timing. The post recommended separating background IP, work product, third-party open-source components, license scope, and payment-gated assignment as distinct concepts.

The Four-Bucket Ownership Model

This framework simplifies what should belong to whom:

The fair outcome is not always “client owns everything.” It is more often “client owns the custom product; contractor keeps their reusable tools; client gets a license to anything needed to run the deliverable.”

Third-Party Code, Open-Source Dependencies, and AI-Generated Code

A contractor cannot assign rights they do not hold. This is obvious in theory and constantly ignored in practice.

If your contractor’s code includes open-source libraries, copied Stack Overflow snippets, licensed SDKs, fonts from a paid subscription, or output from an AI coding assistant, those components carry their own license terms. Your IP assignment clause does not override the GPL, MIT license, or any other third-party license.

A study of code provenance found 214 code snippets on Stack Overflow that could potentially violate original software licenses, appearing 7,112 times across 2,427 GitHub projects source. Copied code is everywhere. The question is whether anyone tracked where it came from.

What to require from contractors:

• A dependency inventory listing all third-party and open-source components

• A license scan confirming compatibility (no surprise copyleft licenses)

• Confirmation that no code was copied from prior clients

• No undisclosed proprietary libraries

• An AI-code usage policy, especially if your company has restrictions

• A warranty that deliverables do not knowingly infringe third-party rights (subject to negotiated limits)

None of this replaces a proper legal review. But it dramatically reduces the chance that your “owned” codebase contains someone else’s property.

Payment and Ownership Transfer Timing

When exactly does ownership transfer? On signing? On payment? On acceptance? On final milestone?

The answer depends entirely on what the contract says. And if the contract says nothing specific, you have a dispute waiting to happen.

Discussions on Freelancing Stack Exchange describe platform terms (such as those on Upwork-style marketplaces) where the freelancer owns the work product until the client pays, after which rights are deemed assigned to the client source. Hacker News discussions from software contractors echo this pattern: many development contracts provide that code transfers at final payment or an agreed milestone.

From the client side, waiting until final payment to receive ownership can be risky if the project spans months. From the contractor side, transferring ownership before being paid removes the primary incentive for the client to pay.

The transfer trigger should match the billing model. For milestone-based development, consider milestone-based assignment: ownership transfers in stages as each paid milestone is accepted. This aligns incentives for both sides.

If you use a freelancer marketplace, read the platform terms carefully. They may include default work-product ownership rules that override both parties’ assumptions.

Subcontractors and the Assignment Chain

If an agency hires subcontractors to work on your project, and those subcontractors never signed IP assignments to the agency, the agency cannot cleanly transfer rights it does not hold. The chain breaks.

This is the “back-to-back assignment” problem. Every person who contributes code needs to have assigned their rights upstream: subcontractor to agency, agency to client.

For cross-border teams, this gets more complicated. A&O Shearman emphasizes that first-ownership rules are not harmonized internationally source. A U.S. template may not automatically capture rights created by a developer in another country. Orrick notes that IP created outside the U.S. will be subject to local laws governing proper assignment.

The agency you hire should warrant that its employees, subcontractors, and contributors have signed agreements sufficient to let the agency assign the deliverables to you. Ask for this explicitly. It is a reasonable request, and any professional agency will expect it.

When evaluating an agency’s strengths and capabilities, look for how they handle contributor agreements and handoff discipline, not just their tech stack.

Contractor Classification: A Related Risk

Code ownership and IP assignment for contractors does not exist in a vacuum. The way you classify and treat your contractor affects both the IP outcome and your legal exposure.

Cooley warns that if a company hires someone as a contractor and that person is later reclassified as an employee, the company can face liability for employment taxes, penalties, and benefits source. The contractor agreement should include provisions showing the contractor controls how work is performed, including hours, location, work method, and ideally milestone-based or project-based payment.

California is especially relevant. The state’s ABC test presumes workers are employees unless the hiring entity satisfies all three conditions: freedom from control, work outside the usual course of the hiring entity’s business, and an independently established trade or business source. Willful misclassification can carry civil penalties between $5,000 and $25,000 per violation.

IP assignment language should not be drafted in a vacuum. It needs to work alongside contractor classification rules, not undermine them.

Why Startups and Investors Care About Contractor IP Assignment

For many software startups, the code is the core asset. When investors or acquirers evaluate a company, they are not just looking at the product. They are looking at whether the company can legally control, modify, license, defend, and sell the technology.

Missing contractor IP assignments create what lawyers call “chain of title” risk. H&B CPA notes that companies sometimes discover they do not own IP assets only when preparing for a sale or when workers leave source. By then, fixing the problem is expensive and sometimes impossible if the original contractor is unavailable or uncooperative.

TechCrunch’s startup-law guide identifies “hereby assign” as critical language and points founders toward using proper IP assignment agreements for both employees and independent contractors source.

Practitioners on Reddit’s r/InsideAcquisitions describe founder horror stories: contractor-built MVPs with no assignment trail, co-founders who never assigned their contributions, and agencies that retained background IP without disclosure. These gaps can delay or kill a financing round.

A working product is not the same as a fundable asset. Investors want evidence that the company owns or controls the code it depends on.

Before fundraising, confirm that every founder, employee, contractor, advisor, and subcontractor who contributed to product IP signed the right assignment. This is not bureaucracy. It is the foundation of what you are selling.

Practical Checklist: Before, During, and After Hiring a Software Contractor

Before work starts

• Sign a contractor agreement with present IP assignment language

• Include work-made-for-hire language as a fallback where applicable

• Add a confidentiality and non-disclosure clause

• Create a background IP schedule (list what the contractor brings to the project)

• Set rules for third-party and open-source disclosure

• Require subcontractor approval and flow-down IP assignment

• Define the payment and ownership-transfer trigger

• Specify deliverables in the statement of work

• Agree on security and access-control rules

• Review governing law and jurisdiction

• Include invention disclosure and further-assurance obligations

During the project

• Use company-controlled repositories where possible

• Keep commits traceable to individual contributors

• Review dependencies regularly

• Require pull requests, code review, and documentation

• Track all contractor and subcontractor contributors

• Maintain architecture decision records

• Keep the statement of work and change requests updated

At handoff

• Confirm the assignment trigger has occurred (payment, acceptance, milestone)

• Transfer repositories and admin rights

• Rotate all credentials and secrets

• Deliver documentation, build scripts, tests, and deployment instructions

• Deliver the dependency and license inventory

• Confirm no unpaid third-party licenses

• Archive all signed agreements

• Get final invoice, payment confirmation, and acceptance records

• Keep further-assurance obligations alive for future needs

Common Mistakes in Contractor IP Agreements

1. Assuming payment equals ownership.
Payment satisfies the business deal. Copyright ownership transfer generally requires a signed writing source. These are two separate legal events.

2. Using only “work made for hire” language.
For independent contractors, U.S. work-made-for-hire status applies only to specific statutory categories plus a signed written agreement. Many software projects do not fit source.

3. Using future-tense assignment language.
“Will assign” or “agrees to assign” can create only a promise, not an immediate transfer. Case law has repeatedly punished this mistake source.

4. Forgetting background IP.
Agencies and contractors use pre-existing tools, libraries, and frameworks. If the contract does not carve them out and license them appropriately, both sides face risk source.

5. Ignoring subcontractors.
If subcontractors contributed code but never assigned rights, the agency cannot transfer clean title upstream.

6. Confusing GitHub access with ownership.
Repo access is practical control. Copyright ownership depends on law and contract. They are not the same thing.

7. Skipping open-source review.
Contractors cannot assign third-party rights they do not own. Open-source and copied code carry their own license obligations source.

8. Waiting until diligence to fix it.
Retroactive cleanup during a financing or acquisition is harder, more expensive, and sometimes impossible compared to getting assignments signed before work begins source.

Real-World Examples

Startup hires a freelance developer for an MVP

A founder pays a freelancer to build the first version of a SaaS app. There is no signed IP assignment. The founder has a deployed app and repo access, but the freelancer may still own copyright in the code. Before the startup can raise a seed round, it needs to track down the freelancer, negotiate a retroactive assignment, and hope the freelancer cooperates.

Agency uses its internal framework

A development agency builds a marketplace using its own reusable starter kit plus custom code. The client should own the custom marketplace code. The agency should retain ownership of the reusable framework. The client should get a perpetual, royalty-free license to use the framework as embedded in their product. Both sides benefit from clarity. If you are exploring custom marketplace development, this kind of background-IP separation is standard practice for professional engagements.

Contractor creates a patentable feature

A contractor invents a novel device-control method while building embedded software. The contract covers copyright, but nobody thought about patent rights. Patent assignments require separate written instruments and ideally should be recorded with the USPTO source. Without patent counsel involved early, the company may not own the invention.

Offshore developer contributes to a U.S.-led project

A U.S. company hires an overseas developer through an agency. The client agreement says the client owns the work. But the overseas contributor never signed a local-law-compliant assignment. First-ownership rules differ by country source. This can create a chain-of-title gap that only surfaces during diligence.

Choosing a Development Partner That Gets This Right

Legal ownership language should come from counsel. But the engineering partner you choose should make ownership and handoff operationally real: clean repos, documented decisions, dependency visibility, acceptance criteria tied to milestones, and a complete transition plan.

The contract matters. So does the execution behind it. When code ownership and IP assignment for contractors are treated as project fundamentals rather than afterthoughts, both the legal and technical handoff happen smoothly.

If you are planning an MVP, marketplace, or custom software project and want a partner that structures work around clear milestones, client IP ownership, documentation, and handoff, get in touch with Horizon Labs for a free consultation.

Frequently Asked Questions

Who owns code written by an independent contractor?

It depends on the contract and applicable law. Under U.S. copyright law, the author (the contractor) owns copyright first unless work-made-for-hire rules apply or the rights are assigned in a signed writing source. Without a valid assignment, the contractor likely retains ownership even if the client paid for the work.

Does paying a contractor mean I own the code?

Not necessarily. Payment is part of the business deal, but copyright ownership transfer generally requires a signed writing source. The contract should specify when and how ownership transfers, tied to payment, acceptance, or another clear trigger.

Is “work made for hire” enough for software contractors?

Often not by itself. For independent contractors, U.S. work-made-for-hire status applies only to certain statutory categories and requires a signed written agreement source. Many custom software projects may not fit those categories. The safer approach is to include present-tense IP assignment language alongside any work-for-hire clause.

What is a “present assignment” and why does it matter?

A present assignment is language that transfers rights immediately, as opposed to promising to transfer them in the future. The phrase “hereby assigns” is the standard formulation. Courts have repeatedly held that “will assign” or “agrees to assign” creates only a promise, not an actual transfer source. This single-word difference has determined the outcome of major IP disputes.

Can a contractor reuse code from my project?

It depends entirely on the contract. A balanced agreement distinguishes custom work product (assigned to the client) from contractor background IP and general know-how (retained by the contractor). If there is no carveout, the contractor may be restricted from reusing anything, which is often neither fair nor intended.

What should startups do before fundraising?

Collect signed IP assignments from every founder, employee, contractor, advisor, agency, and subcontractor who contributed to the product. Investors and acquirers will look for a clean chain of title proving the company owns or controls its core technology source. Missing assignments are one of the most common diligence problems.

Does GitHub access prove code ownership?

No. Having access to a repository proves you can view and modify the code. It does not prove you hold the copyright or other IP rights. Ownership is a legal status determined by authorship, contract, and applicable law, not by who has the SSH key.

What if my contractor used open-source code?

Open-source libraries remain governed by their respective licenses (MIT, Apache, GPL, etc.). The contractor cannot “assign” rights in code they do not own. Require your contractor to maintain a dependency inventory and license scan. Code ownership and IP assignment for contractors should always account for third-party components that cannot be transferred.

Explore more software development terms or browse startup resources for additional guidance on building and scaling your product.