Code ownership and IP when outsourcing software development

Originally published on shipfastdev.com.

Paying someone to write your code does not, by itself, make you the owner. In the US, the UK and France, copyright in software written by a contractor stays with the contractor unless a written contract transfers it to you; only software written by employees in their job belongs to the employer by default. So when you outsource, you need three things: a written assignment of rights, the code in a repository your company controls, and a check of the open-source licences inside it.

This article is general information, not legal advice. Rules differ by country and by contract; have a lawyer review agreements that matter to your business.

Who owns the code by default

United States

The US Copyright Office explains that a "work made for hire" belongs to the employer or commissioning party. It covers a work prepared by an employee within the scope of employment, or a specially commissioned work, but only if it falls into one of nine listed categories (such as a contribution to a collective work, a translation or a compilation) and both parties sign a written agreement. Software is not one of the nine categories. In practice, code written by an independent contractor stays with the contractor unless they assign the copyright to you in writing.

United Kingdom

The UK Intellectual Property Office is blunt: when you commission a work, "the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing". Employees are different: their employer is the first owner of work made in the course of employment.

France

Article L113-9 of the French Intellectual Property Code gives the employer the economic rights in software and its documentation created by employees in the course of their duties or following the employer's instructions. That rule does not cover freelancers or agencies. As Bpifrance Création puts it, ordering specific software from a provider does not automatically make the client the rights holder; a rights-assignment contract is needed. And French law is strict about the form of that contract: under Article L131-3, each right assigned must be mentioned separately, and the scope of use must be defined by extent, purpose, place and duration. A one-line "all rights belong to the client" clause may not be enough.

What the contract should cover

1. Assignment, not just a licence. State that the provider assigns to you the rights in all code, documentation and designs created for you. Under French law, list the rights (reproduction, modification, adaptation, distribution, commercial exploitation) and define territory and duration.
2. When it happens. Usually on payment of each invoice. That is fair to the provider, and it means you should pay on time and keep the paperwork.
3. Pre-existing material. Providers reuse their own libraries, templates and tools. You do not need to own those, but you need a permanent, transferable licence to use them in your product.
4. Subcontractors. If the provider uses other developers, they must have assigned their rights to the provider first, or the chain breaks.
5. Third-party and open-source components. The provider should list them with their licences and confirm that they are compatible with how you use the product.
6. Deliverables at the end. Full source code, build and deploy instructions, documentation, and the credentials for every account they created on your behalf.
7. Confidentiality and data. Your code and data stay confidential; personal data is handled under a processor agreement (see how to choose a remote development partner).

Own the repository, not just the rights

A contract gives you the right to the code; the repository gives you the code itself. Create the GitHub, GitLab or Bitbucket organisation under your company from day one and invite the provider. If a repository already lives in the provider's account, ask for a transfer: on GitHub, issues, pull requests, wiki, stars and watchers are transferred with it, and links to the old location redirect automatically.

Keep in mind what an unlicensed repository means. GitHub notes that without a licence, default copyright law applies and nobody may reproduce, distribute or create derivative works. That is what you want for a private product. If you ever open-source part of it, choose a licence deliberately.

Bpifrance Création also recommends keeping proof of the date and content of your code, for example a deposit with the Agence pour la protection des programmes (APP) or an INPI e-Soleau envelope. A dated, company-owned Git history helps as well. Neither creates rights; they help you prove them.

Open-source licences: what to check

Almost every product depends on open-source packages, and most licences (MIT, BSD, Apache 2.0) ask little more than keeping copyright notices. Copyleft licences need more attention. According to the Free Software Foundation's GPL FAQ:

• You may modify GPL software and use it privately without releasing your changes; the obligation to share source code applies when you distribute it.
• The GNU Affero GPL (AGPL) goes further: if you run a modified version on a server, users interacting with it over a network must be able to get the source.
• If your program links to a library under the GPL (not the LGPL), the work as a whole must be licensed under the GPL.

For a SaaS product, AGPL components deserve a close look; for a mobile or desktop app you distribute, GPL ones do. Ask your developer for a dependency list with licences before each major release; package managers can produce one (for example composer licenses for PHP projects).

A short checklist

• Signed contract with an assignment of rights (French formalities if French law applies).
• Licence for the provider's pre-existing tools.
• Repository, hosting and accounts owned by your company.
• Dependency list with licences, no unexpected GPL or AGPL.
• Handover clause: source, documentation, credentials.

The same points apply whatever the model; see freelancer vs agency vs dev retainer and the access plan in onboarding a remote developer.

Frequently asked questions

Who owns the code written by a freelance developer?

By default in the US, the UK and France, the freelancer does. You become the owner only through a written assignment of rights. Employees are different: their employer generally owns the code they write in their job.

Is "work for hire" enough for software in the US?

Usually not for contractors. Software is not among the nine categories of commissioned works that can be "made for hire", so contracts with contractors should include an explicit copyright assignment.

Can I use GPL code in a commercial product?

Yes, but if you distribute the product, the GPL requires you to provide the source code under the GPL. AGPL extends that to software used over a network. Check licences before you ship.

What should I get from a developer at the end of a project?

The full source code in your repository, documentation, build and deployment instructions, credentials for every account created for you, and confirmation that rights have been assigned.

Sources

1. Works Made for Hire (Circular 30), U.S. Copyright Office, 2024-08
2. Ownership of copyright works, Intellectual Property Office, GOV.UK, 2014-08
3. Code de la propriété intellectuelle – Article L113-9, Légifrance, n.d.
4. Code de la propriété intellectuelle – Article L131-3, Légifrance, n.d.
5. Protection juridique d'un logiciel, Bpifrance Création, 2026-06
6. Frequently Asked Questions about the GNU Licenses, Free Software Foundation (gnu.org), n.d.
7. Licensing a repository, GitHub Docs, n.d.
8. Transferring a repository, GitHub Docs, n.d.