Who owns the code in a software development contract? EU, UK, US and Italian rules

Who owns the code if the contract says nothing?

Whoever wrote it, unless they wrote it as an employee. Copyright starts with the author; employers get an exception for staff working within their duties, and commissioning clients get no equivalent default for software. The table sets out where the main jurisdictions land.

The sources behind each row: Article 2(3) of Directive 2009/24/EC for the EU; section 11 and section 90(3) of the UK's Copyright, Designs and Patents Act 1988; the US Copyright Office's Circular 30 on works made for hire and 17 U.S.C. §§ 201 and 204; and Articles 12-bis and 110 of Italy's copyright law.

Two situations catch founders out. Code a co-founder wrote before incorporation still belongs to them until it is assigned, which is why it should be covered in the founders' paperwork alongside the equity split with a technical co-founder. And no-code platforms set ownership in their own terms of service, as we explain in no-code vs custom development. If you join a startup studio or incubator, ask in writing who will own the code.

Doesn't a ‘work made for hire’ clause solve it in the US?

Not on its own. Under US law a commissioned work is ‘made for hire’ only if it falls into one of nine categories, such as a contribution to a collective work, a translation or a compilation, and the parties sign a written agreement saying so. Software written by an independent contractor generally sits outside those categories, so the label alone may not move ownership. A well-drafted US contract therefore pairs the work-for-hire wording with an express assignment of copyright, signed in writing.

What does copyright protect in software, and what not?

It protects the expression of a program in any form, including preparatory design material; it does not protect the ideas and principles behind it, including those behind its interfaces (Article 1 of the EU directive). In practice, your old vendor cannot stop another team from building a product with the same features, but without an assignment the rights in the code they wrote may stay with them.

The rights at stake are concrete: reproducing the program, translating, adapting and altering it, and distributing it (Article 4). Without them, you need the rightholder's permission before a new team can modify the code. That is why investors ask who owns the technology early in due diligence.

What should the IP assignment clause cover?

It should say what is assigned, when, how broadly and what is carved out. This is our own checklist for the clause:

What about open-source components inside your product?

You never own those; you use them on the terms of their licence. Most modern software products use a lot of them, and some licences carry obligations, such as publishing your modifications, that can clash with how you plan to make money.

Black Duck sells code-scanning tools, so read the figure as a snapshot of companies that run these audits. The lesson still holds: ask your vendor for a list of third-party components and licences and keep it current with each release. Treat AI-generated code the same way and review it like any other code.

How do experienced buyers protect themselves?

They write it into every contract. The US Digital Services Playbook tells federal teams to keep software and data built by third parties under government control and to secure the rights needed so custom software can be reused. Italy goes further: its digital administration code requires public bodies to state in tender specifications that they hold all rights in software developed for them, unless that is excessively costly for documented reasons. If governments have to spell it out, so does a startup.

What should you get handed over, beyond the clause?

Everything another team would need to carry on without your current vendor:

• The code repository in your company's name, with full history.
• Hosting, domain, email, payments and analytics accounts owned by the company.
• Apple and Google developer accounts in the company's name, if you ship mobile apps.
• Technical documentation and instructions to install and release the product.
• A list of third-party components and their licences.
• A copy of the data and backups, with restore instructions.

These points belong in vendor selection too: see how to choose a software development company. And if you are still deciding between models, the ownership question looks different for employees, freelancers and agencies: compare agency vs freelancer vs in-house.