Who owns the code of a custom application?

It is the first question we get asked, and it is the right one. Not "what does it cost" but "and afterward, whose is it?". It almost always comes from someone who has already paid for an application, and who found out — the day they wanted to change supplier — that what they had paid for was not theirs.

What the law says, and what everyone assumes#

The instinct is simple: I paid, so it's mine. For a piece of furniture, that holds. For software, it doesn't.

A program is protected by copyright. Whoever writes it holds the rights, and those rights do not change hands because an invoice was settled. Article L131-2 of the French Intellectual Property Code is explicit: contracts transferring copyright "must be recorded in writing". No writing, no transfer.

Article L131-3 sets the level of precision expected: each assigned right is stated separately, and the scope of exploitation is defined as to its extent, its purpose, its territory and its duration. Its exact reach for a development contract is still argued in court — but it is the drafting standard practice follows, and the one to insist on. A vague clause protects you badly. No clause protects you not at all.

There is one exception, and it explains why the confusion is so widespread. Article L113-9 provides that software written by an employee in the course of their duties belongs to the employer, automatically. Many directors conclude that this is true of any developer. It is true only of yours. A contractor, an agency, a freelancer are not employees: without a written assignment, they keep their rights.

What you have probably signed without noticing#

Three formulations keep coming up, and none of them makes you the owner.

1. "The Client is granted a right of use of the solution." A right of use is a license. It can be withdrawn, time-limited, or made conditional on a subscription.
2. "The deliverables are the property of the Client." Deliverables often mean the screens, the documents, the data — not the source code, which is then mentioned nowhere.
3. Nothing at all. The contract describes a service, a schedule and a price, and stays silent on ownership. By default, it remains with the provider.

Ownership, access, reversibility: three different things#

"Who owns the code" hides three questions, and they need separating, because you can have one without the others.

A provider can assign you the rights and keep the repository on their side. You can have access to the repository without holding the rights. And you can have both, then discover that half of what makes it run is missing: the configuration, the secrets, the deployment procedure, the database structure.

All three are checked separately. All three are asked for separately.

The six questions to ask before signing#

Ask them as they are, and ask for written answers. A provider playing it straight answers in two minutes.

1. Does the contract contain an assignment of rights? If so, ask to see the clause. It must name the rights assigned and their scope.
2. Whose name is the code repository in? The right answer is: your company's, with your provider invited onto it — not the other way around.
3. What about everything around it? Hosting, database, domain names, mailboxes, API keys for third-party tools: each has an account, and each account has an owner. It should be you.
4. What happens if the relationship ends? Ask what is handed over, within what time, and in what form. Have it written down.
5. Is a closeout to another team documented? The question is not "is it well documented", to which everyone says yes. It is: "can an outside developer install and run the project by following a file?".
6. What about the parts you didn't write? Every application leans on external libraries. Ask for the list and their licenses: one restrictive license can contaminate the whole.

We just wanted to add one field. We were told it wasn't in the contract, and that another provider couldn't touch it.

Why we settled this the other way#

At Edenio the client owns their code. The repository is in their name, the assignment is in the contract, and they can at any time have it audited, hand it to someone else, or bring it in-house.

This isn't generosity, and it isn't a sales line. It is a constraint we accept, because it changes the way we work. When a client can leave at any moment, you cannot hold them with the contract: you have to hold them with the tool. That forces you to write code somebody else can pick up, to document deployment for real, and never to hide a dependency behind a black box.

The flip side has to be said: a tool you own is a tool you are responsible for. It will need maintaining, its libraries updating, its future deciding. We do that for as long as we work together — but it is your asset, not ours.

How we handle it#

We hand over the source code and the hosting credentials, and the contract says so in plain terms before the first line is written. You can walk away with it, hand the work to another supplier, or bring maintenance in-house. We have no license to protect: we sell work, not a right to use.

It is the first thing we settle in a meeting, before any talk of features. See how we build an application — what is yours, what stays with you, and what happens if you stop us after six months.

Who owns the code: what to take away#

Paying is not enough. Under French law, ownership of software passes only through an explicit, written and delimited assignment; the automatic rule of article L113-9 applies to employees, not to a contractor.

Before signing, check three things separately — the assignment of rights, access to the repository and the accounts, real reversibility — and get written answers to the six questions above. If one of them makes your counterpart uncomfortable, you have just found the thing to negotiate.