Insights · 10 min read
Who owns the code when you outsource? IP assignment clauses, NDAs, open-source risks, and the practical controls that keep your software yours.
By GGP Editorial
When a founder or CTO tells me they are nervous about outsourcing, the intellectual property question comes up almost every time. Who actually owns the code when a vendor in another country builds your product? What stops them from reusing it for a competitor? These are fair questions, and the honest answer is that most IP problems in outsourcing are not theft. They are contract gaps. Someone skipped a clause, or signed a template, or assumed the law defaults in their favor when it does not.
This guide covers what you need to protect: the clauses, the practical controls, the open-source traps, and what to expect when your vendor sits in a different jurisdiction. It is written for business owners and founders, not lawyers. You should still have a lawyer review the final contract, but this will tell you what to ask for before you sign.
Here is the part most people get wrong. When you pay a software company to build something, you do not automatically own the copyright. In most jurisdictions, copyright belongs to the author, the person or company who wrote the code. Paying for the work does not transfer it.
In the United States, the work-made-for-hire doctrine covers employees. It does not automatically cover independent contractors. A software vendor is an independent contractor. Unless you have a written agreement that assigns the intellectual property to you, the vendor can in many cases hold the copyright to the code it wrote for you.
Patents work the same way. The inventor owns the patent application by default. If the vendor's engineers invent something patentable while building your product, you need a written assignment to own it.
This is why the IP clause in your contract is not boilerplate. It is the thing that makes the code yours.
You do not need a forty-page contract. You need a handful of clauses written clearly. These are the ones I check first.
| Clause | What it does | What to watch for |
|---|---|---|
| IP assignment | Transfers ownership of the delivered work to you | Should cover code, docs, and designs, with a clear trigger |
| Background vs foreground IP | Keeps the vendor's pre-existing tools theirs, makes your new work yours | List the vendor's pre-existing components in a schedule |
| Moral rights waiver | Lets you modify the code later without permission | Needed in several European jurisdictions |
| Non-disclosure (NDA) | Protects your business info and unregistered IP | Should cover subcontractors and survive the project |
| Open source disclosure | Forces the vendor to list all third-party components | Critical; see below |
| Non-reuse | Stops the vendor building a clone for a competitor | Hard to enforce across borders, but worth stating |
IP assignment is the core clause. Get one that says all work product created for the project, including source code, documentation, designs, and any inventions, is assigned to you, either on creation or on final payment. Both triggers work; just make sure the trigger is written down.
Background IP is the vendor's existing code, libraries, and tools. A good vendor brings reusable components it has built before, and that usually saves you money. What matters is that those stay licensed to you for use in your product, while everything new built for you becomes yours. If the contract is vague here, ask the vendor to list its pre-existing components in a schedule. That clears up most arguments later.
Moral rights are easy to overlook. In several European countries, an author keeps certain rights to a work even after selling the copyright, including the right to be credited and the right to object to modifications. You want a waiver of moral rights to the extent the law allows, so you can change the code years from now without asking permission.
An NDA protects your confidential information and, more importantly, your unregistered IP: the trade secrets, algorithms, pricing models, and customer data you share during the project. Make sure it covers three things.
First, it should cover everything you share before the contract is signed, not just after. You often hand over a lot during the sales process. Second, it should bind subcontractors. Vendors sometimes bring in a specialist for part of the work, and the NDA needs to reach them too. Third, it should survive the end of the project, typically for two to five years.
An NDA is still just a document. It does not stop a determined bad actor on its own. It gives you the legal basis to act if something leaks. The practical controls below matter just as much.
Open source is the most common way IP gets tangled up in outsourcing, and it usually happens without anyone meaning harm. A developer pulls in a library to save time, and that library carries a license with obligations.
Copyleft licenses, most famously the GNU GPL, require that if you distribute software that incorporates the licensed code, you release your own combined code under a compatible open-source license. For a SaaS product you host and never distribute, the analysis is different and often less strict. For anything you ship to customers as installable software or an app, a stray GPL component can force you to open your source code. That is a business decision you want to make deliberately, not discover in an audit.
The fix is simple. Put a clause in the contract requiring the vendor to maintain a list of every third-party component it uses, with its license. Require written approval before any copyleft-licensed component is used. A responsible vendor already does this as part of delivery.
Contract clauses matter. So do controls on how the work is actually done. These are the ones I recommend to every client.
Repository and access control. Your code should live in a repository your company owns or controls from day one, not in a private account held by an individual vendor employee. You should have admin access and be able to revoke the vendor's access instantly if the relationship sours. This single control prevents most hostage situations.
Account ownership. All cloud accounts, domain names, app store accounts, and third-party service accounts should be registered to your company's email and billing, not the vendor's. I have seen projects where the vendor held the Apple Developer account and the client could not update its own app after a dispute. Register everything in your name from the start.
No backdoors, no hidden calls. Require the vendor to confirm there are no undisclosed remote access mechanisms, no hardcoded credentials, and no calls to services you did not approve. You can verify this with an independent security review before launch.
Staged payments. Paying in milestones tied to deliverables, with the final payment held until you have the full source code and documentation, is part of your IP strategy. It keeps control in your hands through the handover.
When your vendor is in China, Brazil, or anywhere outside your own country, two extra questions matter: which law governs the contract, and where you can enforce it.
Choose the governing law explicitly. If you are a US or European company, you generally want your own jurisdiction's law to govern the contract, with disputes resolved in your courts or a neutral arbitration venue. A vendor that balks at reasonable governing-law and arbitration terms is a red flag. Most established offshore firms are used to this and agree without drama.
Enforcement is the honest limitation. A court judgment in your country is only as good as your ability to enforce it against the vendor's assets abroad. In practice, the stronger your day-to-day controls, the less you rely on courts at all. Prevention beats litigation, and it is far cheaper.
Register what you can. Copyright registration, trademarks, and patents are territorial. If your product will matter in a specific market, register the IP there. For software you sell as a product, registering the copyright in your home market gives you a stronger position if you ever need to act.
You should not have to fight for basic IP hygiene. A serious software company offers most of this as standard. When we take on a project at GlobeSoft, we sign an NDA before any detailed discussion, assign full ownership of the delivered source code and IP to the client in the contract, and structure delivery so the client owns the repository and all related accounts from the start. That is not special. It is the baseline you should expect from any vendor you consider.
When you are comparing vendors, ask one direct question: "Who owns the code, and how is that written in the contract?" A vendor that answers clearly, in writing, and puts it in the agreement has done this before. A vendor that hedges is telling you something.
Before you get to contracts, though, make sure you are choosing the right partner in the first place. Our guide to choosing an offshore software development partner walks through the due diligence, and how to outsource software development and keep control covers the working relationship after the contract is signed.
Does paying for the software make me the owner? No. Payment covers the service. Ownership comes from a written IP assignment clause. Without it, the author often keeps the copyright.
What is the difference between background and foreground IP? Background IP is what the vendor already owned before your project, such as its tools, libraries, and frameworks. Foreground IP is what is created for you. You should own the foreground IP and get a license to use any background IP in your product.
Do I need an NDA if the contract already has an IP clause? Yes. The NDA protects what you share before signing and your trade secrets and business information, which an IP clause does not fully cover.
Can open-source code put my IP at risk? Yes, if a developer adds a copyleft-licensed component, such as GPL, to software you distribute. Require a full third-party component list and approve any copyleft code before it is used.
What if the vendor is in another country? You can still protect your IP. Set the governing law in the contract, own the repository and accounts directly, register IP where it matters, and keep enforcement practical rather than relying on cross-border litigation.
Should I register the copyright? If you plan to sell or license the software as a product, registering the copyright in your key markets strengthens your position. It is a business decision, not always required.
Protecting your IP in outsourcing is not about distrust. It is about writing the rules down so neither side has to guess. Own the repository, get the assignment clause, approve your open-source list, and register the accounts in your name. Do those four things and most IP risk disappears before the first sprint.
Planning to outsource a build and want a team that treats IP assignment, NDAs, and source-code ownership as standard rather than something to negotiate? Talk to us about your project.
Tell us what you are building and where you are today. We typically reply within 24 hours.
