Code Ownership in Software Outsourcing — Legal Framework and Best Practices

Code ownership in software outsourcing defaults to the developer in most jurisdictions — not the client — unless the contract explicitly assigns it. In the US, software created by a non-employee is NOT automatically work-for-hire under copyright law; it requires a written assignment agreement. This single legal reality catches more outsourcing buyers off guard than any other contract issue, and the consequences range from losing the right to modify your own product to watching a vendor reuse your proprietary logic for a competitor.

This resource covers the default ownership rules, the contract clauses that override them, what happens when an engagement ends, how open-source components complicate the picture, and how the law differs across the three jurisdictions most relevant to outsourced development: the United States, the United Kingdom, and India.

Who owns the code in an outsourcing arrangement by default?

The developer owns it. Under US copyright law (17 U.S.C. § 201), the author of a work is the initial copyright owner. When an outsourcing vendor writes code, the vendor is the author. The client paid for it, scoped it, reviewed it — none of that changes the default rule.

The "work made for hire" doctrine only applies automatically to employees working within the scope of employment. An outsourcing vendor is a contractor, not an employee. For contractors, work-for-hire status requires both a written agreement signed before work begins AND the work must fall into one of nine statutory categories — and "software" is not one of them.

This means a client who signs an outsourcing contract without an IP assignment clause may have a license to use the software but no ownership of the underlying code. The vendor retains the right to reuse, modify, or license that code to others — including competitors.

What's the legal difference between work-for-hire and IP assignment?

Work-for-hire and IP assignment both transfer ownership to the client, but they operate differently and carry different risks. The distinction matters because using the wrong mechanism can leave ownership ambiguous — exactly the situation that leads to disputes.

The practical recommendation for any outsourcing arrangement: use an IP assignment clause, not a work-for-hire clause. IP assignment works regardless of whether the work qualifies as work-for-hire, so it eliminates the statutory category risk entirely. Many well-drafted MSAs include both — a work-for-hire statement as a belt, and an IP assignment as the suspenders.

What happens to code ownership when an outsourcing contract ends?

What happens depends entirely on what the contract says — and what it fails to say. If the MSA includes a proper IP assignment clause, ownership transferred at creation. Ending the contract does not reverse the transfer. The client owns the code and can continue using, modifying, and deploying it with a different team.

If the contract only grants a license instead of assigning ownership, the license terms govern what happens at termination. Some licenses survive contract termination. Some do not. A perpetual, irrevocable license gives the client ongoing use rights but still leaves ownership with the vendor — meaning the vendor can license the same code to others.

The most dangerous scenario is a contract that says nothing about post-termination rights. In that case, the default copyright rules apply: the vendor owns the code, and the client's implied license to use it may terminate when the relationship ends. We have seen companies unable to modify their own production software after switching vendors because the original contract lacked a survival clause.

Three contract provisions prevent this:

1. IP assignment clause — ownership transfers at creation, not at contract end
2. Source code escrow or repository access — ensures the client has the actual code, not just the legal right to it
3. Transition assistance obligation — requires the vendor to cooperate with handover for a defined period after termination

How do open-source components affect code ownership?

Open-source components do not transfer ownership to the client — they remain under their original open-source license. What the client owns (via the IP assignment clause) is the custom code written on top of, around, or integrated with those open-source components. This distinction is critical because some open-source licenses impose conditions on the entire combined work.

The most significant risk comes from copyleft licenses like GPL (GNU General Public License). If a vendor incorporates GPL-licensed code into a proprietary product without proper isolation, the GPL's viral clause can require the entire combined codebase to be released under GPL terms. This effectively makes the client's proprietary code open-source — permanently.

Permissive licenses (MIT, Apache 2.0, BSD) carry fewer risks. They allow commercial use, modification, and distribution without requiring the combined work to be open-sourced. Most modern web frameworks and libraries use permissive licenses, which is why the risk is manageable — but only if someone is tracking what's being used.

The contract should require the vendor to maintain a Software Bill of Materials (SBOM) — a documented list of every open-source component, its license type, and its version. Without an SBOM, the client has no way to assess their exposure during due diligence, an acquisition, or a licensing audit.

What code ownership clauses should every outsourcing contract include?

Six clauses form the minimum viable IP protection framework for any outsourced software engagement. Missing any one of them creates a specific, exploitable gap.

1. IP assignment clause — "All intellectual property created under this agreement is assigned to the Client upon creation." This is the foundation. Everything else is secondary.
2. Pre-existing IP carve-out — The vendor identifies any pre-existing code, libraries, or frameworks they will use. These remain the vendor's property, and the client gets a perpetual, irrevocable license to use them within the delivered product.
3. Open-source disclosure and SBOM requirement — The vendor must document all open-source components, their licenses, and update the SBOM with each release. No GPL or other copyleft code without prior written approval.
4. Repository access and source code delivery — The client has direct access to the source code repository throughout the engagement, not just at the end. Client-owned repositories (e.g., the client's own GitHub or Bitbucket organisation) are the strongest protection.
5. Non-compete on derivative works — The vendor cannot use, license, or create derivative works from the client's custom code for any other party. This prevents a vendor from building a SaaS product using logic developed for the client.
6. Survival clause — IP assignment, confidentiality, and non-compete provisions survive contract termination. Without this, the vendor's obligations end the day the contract expires.

Every MSA we sign at Madgeek includes full IP assignment, client-owned repositories from day one, and documented open-source usage policies. The client's GitHub or Bitbucket organisation owns the repo — our engineers are added as contributors with defined access levels. When the engagement ends, we remove our access. The client never has to ask for "their" code because it was always in their repository.

How does code ownership law differ between US, UK, and India?

The three jurisdictions most common in outsourcing arrangements — the US (where most clients are), the UK (second-largest outsourcing buyer market), and India (where most development teams sit) — each handle code ownership differently. The governing law clause in the contract determines which country's rules apply.

The moral rights issue deserves specific attention for India-based outsourcing. Under Indian law, the developer retains moral rights — including the right to claim authorship and the right to object to modifications that damage their reputation — even after a full IP assignment. These moral rights cannot be waived by contract. In practice, moral rights claims on commercial software are rare, but the legal exposure exists and should be documented in the contract rather than ignored.

For cross-border outsourcing, the governing law clause determines which country's IP framework applies. A US client working with an Indian vendor should specify US law as governing law for IP matters. This is standard practice and enforceable — Indian courts generally respect choice-of-law clauses in commercial contracts.

What mistakes do companies make with code ownership in outsourcing?

The same five mistakes come up repeatedly across outsourcing engagements, regardless of vendor size or geography. Each one is preventable with the right contract language.

1. Relying on work-for-hire alone. Work-for-hire does not cover software created by contractors under US law. An IP assignment clause is the correct mechanism.
2. Using the vendor's repository. If the code lives in the vendor's GitHub organisation, the vendor controls access. When the relationship ends — whether amicably or not — access becomes a negotiation point instead of a given.
3. Ignoring open-source license tracking. Without an SBOM, the client has no visibility into copyleft exposure. This surfaces during due diligence for funding or acquisition — and it surfaces as a problem, not a detail.
4. No pre-existing IP carve-out. When the vendor uses their own libraries or frameworks without disclosing them, the client may believe they own code that includes components the vendor retains rights to.
5. No survival clause for IP terms. If IP assignment and non-compete provisions do not survive contract termination, the vendor's obligations vanish when the contract expires. The IP assignment itself may be valid, but the non-compete and confidentiality protections are gone.

How Madgeek handles code ownership

We treat IP protection as a structural issue, not a legal afterthought. The ownership framework is set before the first line of code, not negotiated at the end of the engagement.

Every engagement starts with a signed MSA that includes a full IP assignment clause, a pre-existing IP disclosure, and an open-source usage policy. The client's repository is the single source of truth — our engineers commit to the client's GitHub or Bitbucket organisation, with branch protection rules and code review requirements enforced from day one.

We maintain an SBOM for every project, updated with each release. No copyleft-licensed component enters the codebase without explicit client approval. The SBOM is part of the project documentation — not something generated for the first time during a due diligence process.

When engagements end — and some do — the transition is clean. We remove our access to the client's repository, deliver final documentation, and provide transition support for a defined period. The client never has to request their own code. It was always theirs.

If you are evaluating an offshore development partnership and want to understand how we structure IP ownership, code access, and transition provisions — reach out for a conversation. We will walk you through the exact MSA clauses and repository setup we use across every engagement.