Who Owns Your Code? The Clause That Decides Whether You Can Ever Switch Vendors

IP assignment, repo access, third-party licenses, and the 'proprietary framework' trap. How to make sure the system you paid for is actually yours.

You paid six figures for a system. It runs, it makes money, everyone moved on. Then one day you want to change vendors, or bring the work in-house, and you find out you can't. Not because the code is bad. Because of a clause nobody read.

Software ownership isn't one thing. It's a bundle: copyright assignment, repository access, license compliance, infrastructure control, and the knowledge to keep the thing running. A gap in any single one of these can trap you with a vendor forever. Here's each piece, and how to check it before it's too late to negotiate.

Copyright doesn't transfer just because you paid

In most jurisdictions, whoever writes the code owns it by default: the developer or their employer, not the client who commissioned it. "Work made for hire" is a US concept with narrow requirements. In much of LATAM and Europe, authorship stays with the creator unless a written assignment says otherwise. Paying an invoice is not an assignment.

• Look for explicit language: "Contractor irrevocably assigns all right, title, and interest…". A vague "deliverables belong to Client" may not hold up.
• Assignment should trigger on creation or delivery, not on final payment. Otherwise a payment dispute freezes your ownership.
• Moral rights (common in civil-law countries) can't always be assigned. Get a waiver where the law allows it.
• If subcontractors or freelancers touched the code, the vendor needs signed assignments from them too, or the chain of title breaks.

Ownership is worthless without the keys

You can own the copyright and still be locked out. If the vendor hosts the git repository, the CI/CD pipelines, and the cloud account under their own organization, "your" code lives on their infrastructure. When a relationship ends badly, access is the first thing to disappear.

• The repository lives in an org you own (GitHub/GitLab), with the vendor invited as a collaborator, not the reverse.
• You hold the root/owner account for cloud (AWS), DNS, and the domain registrar. Vendors get scoped IAM roles, not master credentials.
• Run a full export test before final payment: clone the repo, run the build, deploy to a clean environment you control.
• Secrets and environment variables are documented and handed over, not living only in one person's laptop.

The code you didn't write still has rules

Every modern system is 80-90% third-party code: open-source libraries, SDKs, and commercial components. Owning your code doesn't mean you own theirs, and some licenses carry obligations that survive the handover and attach to you.

• Copyleft licenses (GPL, AGPL) can force you to publish your source if you distribute, or, with AGPL, even if you merely expose the software over a network. AGPL inside a SaaS product is a real trap.
• Permissive licenses (MIT, Apache 2.0, BSD) are safe but still require attribution. Apache 2.0 also carries patent clauses worth understanding.
• Commercial licenses (a paid charting library, a font, a UI kit) may be tied to the vendor's account or seat count. Confirm the license actually transfers to you.
• Ask for an SBOM (software bill of materials), or at least the output of a scanner like license-checker or FOSSA. A clean dependency audit is cheap insurance.

The 'proprietary framework' trap

Some vendors build on top of an in-house framework, CMS, or "platform" they own. It speeds up their delivery, and it means the system only makes sense to them, or only runs with a license they control. You bought a house built on rented land.

• Red flag: core functionality depends on a closed package published to the vendor's private npm/PyPI registry.
• Red flag: the "admin panel" or "engine" is licensed separately, per year, and stops working if you don't renew.
• Acceptable: the vendor uses open, mainstream tools (Next.js, Django, Rails), and their reusable pieces ship as source in your repo under an assignment.
• The question to ask out loud: "If we hire a different team next year, can they run and extend this without paying you or knowing something only you know?"

Infrastructure and credentials are part of the asset

The application is one layer. The accounts around it, domain, email, cloud, payment processor, analytics, third-party APIs, are the other. It's common to finish a project and realize the domain is registered under the agency's account and the Stripe keys belong to their business entity, not yours.

• Domain registered to your legal entity, with you as the registrant, not "we'll manage it for you."
• Cloud, database, and CDN accounts owned by you, with billing on your card.
• API keys for third-party services (payments, email, maps) issued under your accounts, not shared from the vendor's.
• A written inventory of every account: who owns it, and how to recover access.

If only they understand it, you don't really own it

Code you can't read or run is a liability with your name on it. The last, quiet form of lock-in is knowledge: undocumented decisions, tribal setup steps, a deploy process that lives in one person's head. You own the files and still can't move. Insist on a README that takes a new engineer from clone to running locally, architecture notes, and a documented or recorded handover before you sign off.

A five-minute ownership test

Before the final payment, and ideally before you sign the contract, walk through this. If any answer is "no" or "the vendor," fix it now, while you still have leverage. After delivery, the leverage is gone.

• Is there a written IP assignment covering the vendor and every subcontractor, triggered at creation?
• Do the repo, cloud, and domain live under accounts you own?
• Has someone on your side cloned, built, and deployed the system independently?
• Do you have a license inventory with no AGPL/GPL surprises and no vendor-only packages?
• Could a different team take over next quarter using only what's in the repo and the docs?