Table of Contents
Code Ownership Contract: Who Really Owns Your Software?
You paid for it. Your team spent months in requirements sessions, sprint reviews, and UAT cycles. The vendor delivered. The project closed. You moved on.
Then something changed. You needed to modify the product. Or a competitor made an acquisition offer. Or your vendor went quiet. And someone in legal asked a question that stopped the room: “Do we actually own this code?”
The answer, for a startling number of mid-market companies, is no. Or at minimum, not clearly. A code ownership contract is not automatically created by payment. It requires specific language. Without it, U.S. copyright law hands ownership to the developer by default. Paying for development gives you a working product. It does not give you the legal right to do anything you want with it. Those are two different things.
This guide covers the specific contract clause that determines ownership, the exact language that transfers it (and the wording that doesn’t), real scenarios where the gap has cost companies serious leverage, and what to require in any vendor agreement before you sign.
The Default Rule No One Tells You: Your Vendor Owns the Code Until a Contract Says Otherwise
Under U.S. copyright law, the person who creates a work owns it. Full stop. Section 17 U.S.C. 201(a) establishes that copyright ownership vests initially in the author. In outsourced development, that means the developer, not the client who paid for it.
This surprises executives every time. The intuition is that commissioning work equals owning the result. It doesn’t. Not under U.S. copyright law. Not without a contract that explicitly says otherwise.
What U.S. Copyright Law Says About Contractor-Written Code
A visual comparison of who holds copyright by default under U.S. law versus what a contract assignment clause changes.
When an employee writes code, the company owns it under the “work made for hire” doctrine: employment creates an automatic transfer of IP rights. Contractors are different. An independent developer or an outsourced vendor working under a services agreement is not an employee. They own what they build unless the contract transfers ownership to you.
The law is unambiguous on this point, and it doesn’t care about your invoice history or the number of Zoom calls you attended.
Why “We Paid for It” Doesn’t Mean You Own It
The common assumption is that payment creates ownership. It creates an obligation, sometimes a license, but not a transfer of intellectual property. You may have the right to use the software as delivered. You likely do not have the right to modify, sub-license, resell, or build additional products on top of it without the vendor’s consent.
Possession and IP ownership are also distinct. Having access to code files is not the same as owning the legal rights to that code. A vendor can hand over a GitHub repo while retaining the IP. The distinction isn’t technical. It’s contractual.
For the parallel risk of owning code without documentation, see: “Outsourcing Software Development: Why Documentation Is the New Competitive Advantage.“
Work for Hire: What It Covers, What It Doesn’t, and Why Software Falls in the Gap
“Work for hire” sounds like a complete solution. Commission work, receive ownership. But the doctrine has specific legal requirements, and software written by independent contractors doesn’t meet them automatically.
The Nine Categories That Define Work for Hire (and Why “Software” Isn’t Always One of Them)
U.S. copyright law defines two situations where a work qualifies as “made for hire.” First: work created by an employee within the scope of employment. Second: work specially ordered or commissioned, but only if it falls into one of nine specific statutory categories AND the parties sign a written agreement calling it “work for hire.”
Those nine categories include things like contributions to collective works, compilations, instructional texts, and translations. Custom software written for a client’s internal use does not appear on that list by default. A contract can include “work for hire” language, but without a written agreement and a qualifying category, the classification doesn’t hold.
Even when “work for hire” language is in the contract, courts have questioned whether custom software actually fits the statutory categories. That legal uncertainty is the gap.
The Contractor Exception: When Independent Developers Fall Outside Work-for-Hire
An independent contractor (a freelancer, a boutique dev shop, a nearshore vendor) is not an employee. The automatic work-for-hire rule that applies to employees does not apply to them. Every piece of software they write for you defaults to their ownership unless you contract specifically for IP transfer.
This is the scenario 39% of mid-market companies find themselves in after delivery. According to SmallBizClub (via Netcorp Software Development), 39% of IT outsourcing projects fail due to poor planning. Inadequate IP provisions are a structural planning failure, not an execution one.
The fix is not to rely on “work for hire.” The fix is an assignment clause.
The Assignment Clause: The Exact Language That Transfers Ownership (and the Wording That Doesn’t)
The assignment clause is where the code-ownership contract is actually executed. Get this right, and you own the product. Get it wrong, and you’ve paid for a license, not an asset.
Side-by-side contract language comparison: a present assignment clause versus a promise-to-assign clause, with the legal consequences of each.
Promise to Assign vs. Present Assignment: Why One Word Changes Who Owns the Product
This distinction was cemented in federal case law. In Advanced Video Techs. LLC v. HTC Corp. (Federal Circuit, 2018), the court ruled that a contract clause stating the developer “will assign” IP constitutes only a promise of future transfer, not an actual present assignment. The practical consequence: the IP transfer doesn’t happen automatically when the project closes.
A present assignment uses a different language. “Hereby assigns” or “does hereby assign” creates the transfer at the moment of signing. No additional action required. No future obligation to fulfill. The IP moves to you when the ink is dry, not later.
The difference in writing is often a single word. “Will assign” versus “hereby assigns.” The business consequence is enormous.
Contract Language That Actually Works, and Red Flag Phrases to Reject
Language that transfers ownership:
– “Vendor hereby assigns to Client all right, title, and interest in and to the Work Product, including all intellectual property rights therein.”
– “All Work Product created under this Agreement shall be and is hereby assigned to Client upon creation.”
Red flag language to push back on:
– “Vendor agrees to assign” (future promise, not present transfer)
– “Vendor will provide Client with a license to use the Work Product” (you’re getting a license, not ownership)
– “Client shall have a perpetual, irrevocable license…” (a license, even a broad one, is not ownership)
– No IP section at all (silence defaults to the developer)
An IP assignment clause that transfers “all right, title, and interest,” including “intellectual property rights,” is the minimum standard. Anything less warrants a conversation with legal before signing.
For a vendor selection framework that includes IP screening, see: “Staff Augmentation vs. Dedicated Team: Who’s Accountable?“
What Happens When the Clause Is Missing: Real Scenarios Mid-Market Companies Face
Abstract legal risk becomes real when the vendor relationship changes, the product needs to evolve, or an acquisition shows up. Here are the three scenarios mid-market CEOs and CTOs most commonly encounter.
Scenario 1: Vendor Delivers, Goes Dark. Who Controls the Codebase?
The vendor finishes the project. The engagement closes. Six months later, a critical bug surfaces. Your team can’t modify the code because the vendor retained IP rights. You can’t bring in another developer without the original vendor’s consent. The vendor isn’t responsive. Or worse: they’ve pivoted to a new business model and want a fee to grant modification rights.
You’re not stuck because your team lacks skills. You’re stuck because you don’t own the software you’re running.
S3Corp’s industry analysis notes that between 50% and 70% of software outsourcing projects miss their original scope, budget, or timeline. Operational lock-in after delivery is a direct consequence of the same planning failures that produce those outcomes.
Scenario 2: Company Wants to Pivot the Product, Vendor Demands License Fees
Your market moved. The internal tool needs new capabilities, or you want to spin off a product line. Your legal team discovers that the original development contract left IP with the vendor. Any modification requires their consent. Any derivative product requires a license negotiation.
You’ve built on a foundation you don’t own.
The vendor isn’t necessarily acting in bad faith. They may simply be enforcing the signed contract. But the leverage is entirely theirs, and the cost of extracting yourself comes entirely from your budget.
Scenario 3: Acquisition Due Diligence Uncovers Unclear IP Chain
An acquirer shows up. Their legal team runs IP due diligence. They discover the code ownership contract either doesn’t exist or contains “will assign” language rather than a present assignment. The IP transfer was never actually completed.
The deal stalls. The acquirer wants price adjustments or representations and warranties that the founders can’t honestly make. Some deals die here entirely. Others close at reduced valuations with expensive indemnification provisions attached.
An unclear IP chain is one of the most common due diligence deal-killers in software company acquisitions. By the time an acquisition offer appears, it’s too late to fix the original contract.
Three common risk scenarios showing the business consequences of a missing or incomplete IP assignment clause.
Documentation Transfer: The Second Ownership Problem Most Contracts Ignore
Owning the code is necessary. It’s not sufficient. A codebase without its documentation is an asset you legally own but practically can’t operate.
Why Owning the Code Without the Documentation Leaves You Operationally Dependent
A mid-market CTO who receives a GitHub repo at project close owns the source files. But without architecture diagrams, API documentation, system design decisions, and onboarding materials, their team can’t extend the system, debug production issues with confidence, or hand it off to a new vendor if the relationship ends.
As Dreamix’s research on vendor transitions notes, documentation gaps, undocumented dependencies, and lost configuration details create expensive problems months after transition completion. Legal IP ownership doesn’t resolve operational dependency on the people who built the system.
You can own the code and still be dependent on the vendor who understands it. That dependency becomes visible only when something breaks or the relationship ends.
What a Complete Handover Actually Includes
A complete documentation transfer covers at a minimum:
– UML architecture diagrams and system design documents
– Architecture decision records (why key technical choices were made, not just what was chosen)
– API references (Swagger/Postman collections)
– User story libraries and sprint documentation
– Test coverage reports and QA artifacts
– Deployment and configuration documentation
The most commonly omitted item is architecture decision records. Those capture the reasoning behind design choices. Without them, the team inheriting the system has the what but not the why. And “why” is exactly what they need when something breaks or needs to change.
Documentation transfer should be a contractual obligation with defined deliverables, not a best-effort handoff at project close.
How to Audit Your Current Vendor Contract Before It Becomes a Problem
A checklist-style visual showing five contract sections a CEO or CTO should review with their legal team before an issue surfaces.
If you have an active vendor engagement or a recently closed project, spend 30 minutes with your legal team on these questions. Not when an issue surfaces. Now.
Five Questions to Ask Your Legal Team About the IP Section
Is there an IP assignment clause at all? Many development contracts are drafted from generic service agreement templates that omit IP sections entirely. The absence of a clause is as dangerous as a weak one.
Does it say “hereby assigns” or “will assign”? Look for present tense. Future-tense language indicates the transfer hasn’t happened yet. If you find “will assign” or “agrees to assign,” ask your legal team whether a separate assignment agreement was ever executed.
Does the clause cover all work product? Watch for narrow definitions. Some contracts assign IP in the final deliverable but leave derivative works, pre-existing vendor IP incorporated into the project, or improvements created during maintenance in ambiguous territory.
Does documentation appear as a defined deliverable? Source code and documentation should both be listed explicitly. A contract that specifies code delivery but not documentation creates the second ownership gap described above.
Is there an exit clause defining what happens to the codebase if the relationship ends? A vendor who retains some rights under a license model may have conditions attached to that license. Know what those conditions are before you need to invoke them.
When to Renegotiate Mid-Engagement
Mid-engagement contract revisions are uncomfortable but not unusual. If you discover IP ambiguity during an active project, the leverage to fix it exists now, before delivery, when the vendor still has an incentive to negotiate. Most professional vendors will accept clarifying assignment language as a routine matter. If a vendor resists adding a present-assignment clause, that resistance itself is information worth acting on.
A reasonable ask: a standalone IP assignment agreement executed at project close, confirming that all work product created under the engagement transfers to the client. Short document. One page. No new commercial terms.
What “Unconditional Ownership Transfer at Delivery” Actually Means in a Contract
Nearshore is better than offshore for most mid-market teams when it comes to IP outcomes. Not because of proximity, but because the vendor model drives how contracts are written. Here’s the distinction that matters.
The Difference Between a Contractual Guarantee and a Handshake Promise
“We always give clients full ownership” is something every development vendor says. What separates that claim from a contractual guarantee is whether it appears in the contract with specific language or exists only as a verbal commitment.
Handshake promises don’t survive vendor leadership changes, acquisitions, or the moment a vendor realizes they can extract fees from a client who has nowhere else to go. Contractual guarantees do. The specific language must appear in the signed agreement.
Unconditional ownership transfer means:
– The assignment is present, not future (“hereby assigns,” not “will assign”)
– Coverage includes all work product created under the engagement, including modifications, derivative works, and AI-generated components
– Documentation is explicitly included as a transferred deliverable
– No license-back to the vendor is created that conditions the client’s use rights
“Unconditional” is the operative word. Some IP assignment clauses include carve-outs for vendor pre-existing IP, third-party libraries, or the vendor’s “know-how.” Those carve-outs can be legitimate, but they need to be defined clearly enough that you know exactly what you own and what remains licensed.
What to Require From Any Nearshore or Offshore Vendor Before Signing
Before a contract signature, your legal team or your procurement process should verify:
- Present-tense IP assignment language (not future promise)
- Coverage of “all right, title, and interest” including all intellectual property rights
- Documentation explicitly listed as a deliverable in scope, with specifics (architecture diagrams, API docs, ADRs)
- No conditional language tying your use rights to the continuation of the vendor relationship
- An exit clause defining the state of the codebase and documentation if the engagement ends early
This is table-stakes vendor screening for any mid-market company commissioning custom software development. Treating it as optional is how the 39% get there.
At Nexa Devs, unconditional codebase ownership transfer at delivery is a contractual guarantee, not a post-sale commitment. Every engagement closes with a complete documentation package transferred to the client, ownership of every line of code delivered, and no conditions on what the client does with it afterward. That’s the model.
The Bottom Line on Code Ownership Contracts
The vendor delivered. The invoice is paid. None of that means you own the software.
IP ownership is determined by a single clause in a written contract. Either the assignment language is present and correctly worded, or it isn’t. There’s no middle ground under U.S. copyright law, and verbal commitments from vendors have no legal standing when a dispute surfaces.
The companies that get this right treat IP assignment as a non-negotiable contract term, not a negotiation point. They require present-assignment language, full documentation transfer, and no conditions on their ownership rights before any engagement begins. The companies that get it wrong discover the gap at the worst possible moment: a vendor transition, a product pivot, or an acquisition table.
Review your current vendor contracts now. Add the five questions above to your legal team’s pre-engagement checklist. And before you sign anything new, confirm you’re getting a contractual guarantee of ownership, not a handshake promise.
Ready to work with a development partner who guarantees unconditional codebase ownership and full documentation transfer at delivery? Schedule a conversation with the Nexa Devs team to see what a contract-first approach to custom software development looks like.