How to Protect Your IP When You Outsource Software Development

Related: How to Write a Software Requirements Document (With a Template)

This article is general information, not legal advice. Ownership rules differ between countries. Have a lawyer review any contract that matters.

A surprising number of businesses find out they do not fully own their own software at the worst possible moment: when they try to switch developers, sell the company, or raise money and an investor asks.

Here is how ownership actually works, and how to make sure you have it.

Paying for code is not the same as owning it

In many countries, copyright in code starts with the person who wrote it. Employment usually changes that, so an employer owns what staff write as part of their job. An outside contractor or agency is different. Unless a written contract transfers the rights, the author may keep them, even after you pay in full.

In the United States, for example, commissioned software from an independent contractor generally does not count as "work made for hire". A written assignment is what transfers ownership.

So the first rule is simple: get ownership in writing.

The contract terms that matter

1. IP assignment

The contract should assign all rights in the work created for you. Wording matters. Lawyers generally prefer language that assigns the rights now, such as "hereby assigns", over a promise to assign them later.

Assignment on full payment is common and fair. The developer is protected until they are paid, and you own the work once you have paid. Just make sure you understand exactly when the transfer happens.

2. Pre-existing IP

Good developers reuse their own tools, libraries and templates across projects. They cannot assign those to you, because they need them for their next client.

The right answer is a licence. The contract should give you a permanent, irrevocable licence to use, modify and keep running any pre-existing code included in your product. Without one, a piece of your system may belong to someone who can later object to how you use it.

3. Open-source components

Almost all software includes open-source packages, each with its own licence.

• Ask for a list of open-source dependencies and their licences.
• Permissive licences such as MIT and Apache 2.0 rarely cause trouble.
• "Copyleft" licences such as the GPL can require you to release your own source code in some situations. The AGPL can do so even when you only run the software as an online service.

That is not automatically a problem, but it should be a decision you made, not a surprise.

4. Moral rights

In some countries, authors keep certain personal rights in their work even after selling it. Where the law allows, the contract should include a waiver or consent so these cannot be used to block changes.

5. Confidentiality

An NDA stops the developer sharing your business information. It does not transfer ownership of the code. You need both.

6. Non-solicitation rather than non-compete

Broad non-compete clauses on contractors are often unenforceable and unfair. A narrower clause, such as not poaching your staff or clients, is more reasonable and more likely to hold.

The practical controls matter more

Clauses help if there is a dispute. Practical controls prevent the dispute.

• Own the code repository from day one. Create it in your own account and add the developer to it. Do not wait for a handover at the end.
• Own every account. Hosting, domain names, app store listings, email services, payment providers, analytics. The account should be yours, with the developer invited as a user.
• Own the API keys and credentials, stored where you control them.
• Get documentation as you go: how to deploy, how to run it locally, where things live.
• Make sure more than one person could pick it up. If only one developer understands the system, you own it on paper only.

The most common disaster we see is not a legal one. It is a developer who holds the only admin login to the hosting account, the domain name, or the app store listing, and then stops answering messages.

Working across borders

Suing a developer in another country is slow, expensive and uncertain. That is exactly why practical control matters so much. Choose a governing law and a way to resolve disputes, but do not rely on ever enforcing it. Rely on already holding the repository and the accounts.

For critical software where you cannot hold the source code, source code escrow is an option: a neutral third party keeps a copy and releases it to you if agreed conditions occur.

Checklist

1. Written assignment of all IP in work made for you
2. Permanent licence to any pre-existing code included
3. List of open-source dependencies and their licences
4. Moral rights waiver where the law allows
5. Confidentiality terms
6. Repository in your account from the first commit
7. Every service account in your name
8. Credentials held by you
9. Deployment documentation delivered during the project
10. A lawyer's review of the contract before you sign

At Apex Logic, the repository is the client's from the first commit and every account is in the client's name. If you want to check where you stand with an existing project, get in touch. Also see how to hire a development agency.