A client who has paid an invoice in full does not thereby become the owner of the delivered code’s rights. Under French law, intellectual property in a piece of software stays, by default, with the developer who wrote it, and only an explicit assignment clause can transfer it. The assumption that payment equals automatic transfer trips up freelancers and clients alike. This guide covers what a web services contract must include for an assignment to actually hold, and what can never be assigned at all.
Why assignment never happens automatically
Article L111-1 of the French Intellectual Property Code (CPI) vests copyright in the individual who creates the work, independent of any employment or services contract. Source code is protected on that basis from the moment it is written, with no filing required. A freelance developer therefore keeps ownership of the economic rights in the code they write, even after delivery and full payment, until a clause organizes their transfer. This is a common point of confusion with salaried work: for an employee who develops software as part of their duties, Article L113-9 of the CPI provides for an automatic transfer of economic rights to the employer. Nothing equivalent exists for an independent contractor.
What the formal requirements say
Since the law of July 7, 2016, a written document is required for any contract containing a clause assigning economic rights (Article L131-2 of the CPI). Article L131-3 goes further: each right assigned must be listed separately, and its scope of exploitation bounded by extent, purpose, territory and duration. Case law remains divided on whether this article strictly applies to software — some courts reserve it for representation, publishing and audiovisual production contracts, a reading confirmed by a ruling of the Aix-en-Provence Court of Appeal on January 28, 2021. As a precaution, a web services contract is still better off following this formalism even without certainty on whether it’s mandatory: the assignment gains in clarity, and the text is interpreted strictly — anything not explicitly assigned stays the developer’s property.
Clauses to include in the contract
A solid assignment clause specifies, for each right transferred (reproduction, representation, adaptation, translating the code into another language), its technical extent, its commercial purpose, the territory covered and its duration. It also states when the transfer takes effect: at signature, at delivery, or on full payment — the last option protects the developer in case of non-payment, since the rights only switch over once the invoice is settled. Finally, it prices the compensation tied to the assignment, even when it is folded into the overall fee, to avoid a judge later treating the lack of mention as an unintended assignment.
As an illustration, a typical wording for a project delivered in one go might read: “The contractor assigns to the client, from the date of full payment of the agreed price, the reproduction and representation rights over the source code specifically developed under this contract, excluding third-party libraries, worldwide, for the statutory term of copyright protection.” Such a clause still needs adapting to each engagement: a fixed-price project doesn’t call for the same wording as a monthly retainer, where assignment can apply module by module, as each deliverable is accepted.
Fixing a contract that was signed without one
A contract already underway, or already paid in full, that has no assignment clause can be corrected with an amendment signed by both parties. That amendment only takes effect from its signature date: it does not retroactively validate any use the client made of the code before that date, and so offers no protection against a dispute that has already arisen. For recurring maintenance work, where each intervention adds code without a new contract being signed each time, the better move is to fold a rolling assignment clause into the general terms governing the whole relationship, rather than leaving it to each individual purchase order.
The case of third-party libraries and dependencies
A web project almost always pulls in open-source libraries under MIT, Apache 2.0 or GPL licenses, whose rights belong to neither the developer nor the client and so cannot be assigned at all. The contract benefits from saying so explicitly: the assignment covers code specifically written for the client, not third-party dependencies, which remain subject to their own licenses. A copyleft license such as the GPL can also impose redistribution obligations that concern the end client directly; flagging them avoids a costly surprise down the line.
Assigning versus licensing: two different logics
Assignment transfers ownership of the economic rights to the client, who can then exploit, modify and resell the code without consulting the developer. A license, by contrast, authorizes a defined use without transferring ownership: the developer keeps title and can reuse portions of the code for other clients, provided the contract allows it. For a developer building their own reusable building blocks (an authentication module, a theme, a billing system), licensing protects capitalizable know-how; a full assignment gives that up for good.
| Option | What happens to the code | Reuse by the developer | Typical use case |
|---|---|---|---|
| Full assignment | Ownership transferred to the client | Not possible without authorization | Custom development, client wants exclusivity |
| Partial assignment | Ownership transferred for a defined scope | Possible outside the assigned scope | Specific module delivered within a larger project |
| License | Ownership stays with the developer | Free, including for other clients | Theme, plugin, reusable technical building block |
Without an assignment clause, the developer keeps the economic rights to the code, even after the invoice has been paid in full.
Worth watching: moral rights (attribution, integrity of the work) can never be assigned, under Article L121-1 of the CPI. Only economic rights can be assigned or licensed. A developer therefore keeps, in principle, the right to be identified as the code’s author, even after a full assignment.
In practice, writing this clause does not take a contract running to several pages. The essentials fit in one paragraph identifying the rights assigned, their scope, when the transfer takes effect and its financial counterpart, plus a separate paragraph explicitly excluding third-party dependencies from the assignment’s scope.
Key takeaways
- Paying an invoice does not automatically transfer rights to the code: only an explicit assignment clause does.
- The assignment must be in writing and, as a precaution, detail the extent, purpose, territory and duration of each right assigned.
- Open-source dependencies cannot be assigned: they remain under their own licenses.
- Assigning is not licensing: a license lets the developer reuse their own code for other clients.
- Moral rights stay, in every case, attached to the developer as a person.
This is the clause I see missing most often in web services contracts, even among experienced freelancers. The common assumption is that a settled invoice closes the question of ownership, when it says nothing about the fate of the rights. Fixing it costs one paragraph when drafting the contract; its absence can cost an entire standoff the day a client resells or modifies code they never actually had the right to — Simon Janvier.
Further reading: the French Intellectual Property Code on Légifrance, articles L111-1, L121-1, L131-2 and L131-3. See also the guide on freelance invoicing with Odoo and the article on web services contracts.
