Who owns the code your freelance developer wrote?

You paid the invoice. The code is running in production. You think it is yours.

Under Belgian law, that is not automatic. And since part of the lines now come out of an assistant, the question has changed in nature: it is no longer only about who holds the rights, but about whether there are rights to hold.

What the invoice does not transfer

Software is protected by copyright. The Code of Economic Law (CDE) treats computer programs, preparatory design material included, as literary works (art. XI.294 CDE). Protection requires the program to be original, and it covers the expression, not the ideas and principles underlying it (art. XI.295 CDE).

The author is the person who wrote it. A natural person. Payment for a development service pays for work: it does not, on its own, transfer the economic rights in the result.

Three situations, three regimes.

Code written by an employee

The law of 19 April 2014, which inserted Book XI "Intellectual property" into the Code of Economic Law, provides for a presumption: the employer is presumed to be the assignee of the economic rights in programs created by its employees. The presumption applies to code written in the performance of their duties or following the employer's instructions (art. XI.296 CDE). A contrary contractual or statutory provision sets it aside.

Two words matter in that sentence. Presumed: it is a default rule, which an agreement or a statute can set aside. Employees: the presumption is interpreted strictly and does not extend to anyone who is not in a relationship of subordination.

Code written by a self-employed person

No equivalent presumption. Freelancer, agency, consultant, trainee under an immersion agreement: the assignment must be organised by the contract. Failing that, the provider remains the holder of the economic rights in what they wrote. Payment changes nothing. Nor do your specifications.

Specifications do not make you an author. Giving detailed instructions, financing, approving the deliverables: none of that brings about an assignment.

The case people forget: the freelancer who invoices through a company

This is the most frequent configuration in Belgium, and the link most often broken.

You contract with your developer's SRL. But the code was written by a natural person: the director. Yet the presumption of article XI.296 covers the employer and its employees. A self-employed director working for their own company is, in principle, not its employee. Possible result: the SRL assigns to you rights it never itself acquired.

The chain of title therefore has two links, not one:

1. from the developer as a natural person to their company;
2. from their company to you.

A proper clause covers both. It has the natural person join the deed. Another route: the company warrants that it does hold the rights it assigns, with a named declaration of the persons who contributed to the code.

The clauses to check

1. An express assignment of the economic rights

The wording "the customer owns the deliverables" is not enough. It designates a medium, not a right. What is needed is a clause that expressly covers the assignment of the author's economic rights in the software, source code included.

Belgian law is not accommodating on this ground: towards the author, the assignment is proven in writing and interpreted restrictively (art. XI.167 CDE). What is not written is not assigned. A vague clause is not read in your favour: it is read in the author's favour.

Also check that the assignment covers future code delivered after signature, upgrades, fixes, modules added along the way, and not only the initial scope.

2. The scope of the assignment

An assignment can be limited. Check that it covers:

• the modes of exploitation you contemplate, listed;
• the duration and the territory;
• the right to adapt, correct and develop the code, including through a provider other than the one who wrote it;
• the right to sub-license and to assign in turn, without prior consent (a sale of the business must not depend on your former developer's signature).

The right of modification is the point that most often blocks. An assignment that does not provide for it turns every development of your product into a negotiation.

There is a statutory safety net, but it is narrow. The lawful acquirer of software may perform the acts necessary for its use in accordance with its intended purpose, including error correction. The Court of Justice even accepted decompilation to fix a bug (CJEU, 6 October 2021, Top System, C-13/20). The judgment concerns Directive 91/250/EEC, since codified by Directive 2009/24/EC. It is a troubleshooting exception, not a right to develop your product. It never replaces a clause.

3. Delivery of the sources, and what happens if the provider disappears

Many contracts deliver an executable and keep the sources with the provider. Technically, you then can no longer develop your product without them, whatever the quality of your assignment clause.

So require, in addition to the assignment: the sources actually delivered, technical documentation and build scripts, at each milestone, on a repository whose account you hold. If the provider refuses, a frequent case when it runs a code base shared across several customers, use an escrow arrangement with defined release events: bankruptcy, cessation of activity, persistent failure to maintain.

4. The fate of third-party code

Your provider cannot assign to you what it does not own. A modern project embeds dozens of open source libraries, sometimes a component under a commercial licence, sometimes code reused from an earlier project.

Ask for an inventory of the dependencies and their licences (an SBOM, in technical language). Some free licences impose obligations that flow up to your product, in particular if you distribute it. Add a warranty from the provider on the origin of the code and on the absence of infringement of third-party rights, and an indemnity clause that holds, capped, but not token.

Check the other direction too: many contracts contain a discreet clause. In it, the provider keeps its "pre-existing tools, building blocks and know-how" and only grants you a licence over them. That is not illegitimate. But you must know what part of your product rests on them, and on what conditions that licence can end.

5. What is not code, but is part of the product

Title does not stop at the Git repository. On a typical project, you also have to deal with:

• the preparatory design material, specifications, architecture diagrams, written algorithms, expressly covered by article XI.294 CDE;
• the mock-ups, the interface, the icons, the illustrations: ordinary copyright regime, possibly designs;
• the database and its content, which fall under a separate regime (Book XI, Title 7, CDE);
• the product name and the logo, which fall under trademark law and are not assigned by a software clause;
• the accounts and access: domain name, DNS, hosting, API tokens, deployment accounts, Apple and Google stores. They must be opened in your company's name, not the provider's.

A contract that only assigns "the software" leaves four of these five lines outside.

Code written with an AI

This is the subject that makes all the clauses above insufficient if it is not addressed.

In 2026, a substantial part of the code delivered by a provider was not typed by them. It was suggested by an assistant built into their editor, generated from a prompt, then reviewed, corrected, integrated. Your contract, for its part, still assumes a human author writing line by line.

The hard point: what is not protected cannot be assigned

Protection of a program requires originality: an intellectual creation specific to its author, which requires free and creative choices by a natural person (art. XI.295 CDE; Directive 2009/24/EC of 23 April 2009). Belgian law has no rule allowing a non-human subject to hold copyright.

The consequence, often counter-intuitive: code purely generated by a machine, without human creative input, is in principle protected by no copyright. There is therefore nothing to assign. Your assignment clause, however well drafted, applies to an empty object.

What you lose is not the use. No one can prevent you from using that code: you hold it, it works, it is yours in fact. What you lose is exclusivity. You cannot prohibit anyone from reproducing that code if they gain access to it. Your provider can reuse it at your competitor's, unless your contract prohibits it otherwise.

For a product whose value is the service rendered, that is bearable. For a product whose value is the technology, it is a hole in the balance sheet.

The grey area, honestly

Between "written by a human" and "generated by a machine", the line is not sharp. To my knowledge, no Belgian decision has yet settled the question for code.

What is emerging from the available analyses:

• a prompt, however long and precise, is probably not enough on its own to found the originality of the result;
• on the other hand, the overall architecture, the selection among several proposals, the rewriting, the arrangement of the components are human choices capable of carrying originality;
• the analysis is module by module, not project by project. The same repository may contain protected files and files that are not.

In other words: it is not "all or nothing", but you will not know where the line is without documentation of the process. And it is the party claiming the right who will have to establish its originality.

The five clauses to add

a. Declaration of use. The provider declares the generative AI tools used, on which modules, and to what extent. Not to prohibit, prohibiting is unrealistic and unverifiable, but to know.

b. Traceability. The provider keeps and hands over the elements that establish human involvement: named commit history, log of prompts and iterations for the strategic components, architecture notes. This is the file an investor or an acquirer will ask for. It does not create an originality that does not exist; it makes demonstrable the one that does.

c. Broadened assignment and contractual fallback. The clause covers "the intellectual property rights in the deliverables, to the extent that they exist". For the rest, it organises what copyright does not give: exclusivity of exploitation, prohibition on reusing the delivered code for a third party, confidentiality of the source code. Add a non-disclosure undertaking unlimited in time as long as the code is not public. Trade secrets here become your main protection, provided you actually take confidentiality measures, which is the legal condition for it.

d. Warranty and indemnity extended to AI. Many non-infringement warranties exclude, in small print, what comes from third-party tools. Check that the warranty expressly covers code generated or suggested by an AI, and that the indemnity operates if a third party claims rights.

e. Fate of your inputs. The provider gives your code, your specifications, sometimes your data to an external tool. Require confidentiality of the inputs and the use of tools whose terms exclude the reuse of inputs for training. This is a contractual matter, and also a GDPR matter as soon as personal data circulates.

Contamination

An assistant trained on public code can return fragments that reproduce existing code, sometimes under a copyleft licence. The risk is not theoretical: it is low line by line, real at the scale of a project, and it materialises at the worst moment, when an acquirer has your repository audited.

Two reflexes: run a similarity and licence scan before each major delivery; require that the inventory of dependencies (point 4 above) explicitly mentions components of uncertain origin.

What the AI Act settles, and what it does not

Since 2 August 2026, article 50 of the EU AI Act (Regulation (EU) 2024/1689) is applicable. It requires providers of generative AI systems to mark their outputs in a machine-readable format. Artificially generated content thus becomes detectable. On 10 June 2026, the Commission published a code of practice on the marking and labelling of AI-generated content. Regulation (EU) 2026/1744 grants systems placed on the market before 2 August until 2 December 2026.

Two useful clarifications for a business owner:

1. The marking obligation rests on the provider of the model, not on you or your developer. If you call a hosted model, it is not your obligation.
2. Text, and therefore code, remains the weak point of marking. A fragment that is copied, reformatted or retouched easily loses its trace. Do not count on a watermark to know what, in your repository, was generated.

Above all: article 50 is a transparency rule. It says nothing about title. A fragment marked as AI-generated does not thereby become your property. An unmarked fragment does not thereby become protected. It is your contract, and it alone, that organises what you hold.

And if it is your own employee who prompts

Same logic. The presumption of article XI.296 transfers rights to the employer; it does not create rights that do not exist. If the code produced in-house is not original, it is not protected, and the fact that it was produced by an employee changes nothing.

What protects your product in that case is confidentiality, the internal policy on the use of tools and traceability. The presumption is never enough.

What happens if the clause is missing

Nothing, for a long time. That is what makes the problem dangerous.

Then one day the question arises. A break with the provider. An investor asking for the chain of title. A buyer, in due diligence, seeking to establish that the company is indeed assigning what it claims to assign. The provider's bankruptcy, and a trustee taking an inventory of an intangible asset you thought you owned.

At that point, regularisation is possible: a confirmatory assignment agreement, signed by the developer as a natural person and by their company, covering the past. But you negotiate from a weak position, with someone who knows exactly what they hold. The cost is not legal. It is commercial.

And for the AI-generated part, regularisation settles nothing: you cannot assign what is protected by no right. There, the only possible catch-up is contractual, exclusivity, non-reuse, confidentiality, and it assumes the other party still has a reason to sign.

The ten lines to look for in your contract

1. Express assignment of the author's economic rights, covering the software and the source code.
2. Modes of exploitation listed, duration, territory.
3. Right to adapt, correct and develop, by you or by a third party.
4. Right to sub-license and to assign without prior consent.
5. Participation or warranty of the natural person who wrote the code.
6. Sources, documentation and build scripts actually delivered, or escrow.
7. Inventory of third-party components and their licences.
8. Declaration of use of AI tools and traceability of human involvement.
9. Non-infringement warranty expressly covering AI-generated code, with indemnity.
10. Exclusivity, non-reuse and confidentiality, the safety net when copyright does not apply.

The questions to ask your AI

Before signing a development contract, paste it into your assistant and ask these questions:

1. Does this contract contain an express assignment of the author's economic rights in the software, and does it cover the source code?
2. Does the assignment cover the right to modify and develop the code through a third party, as well as the right to sub-license and to assign?
3. Who signs the assignment, and does the contract warrant that the signatory itself holds the rights it assigns?
4. Does the contract deal with open source components and third-party licences?
5. Does the contract say anything about the use of generative AI tools, the traceability of the code produced and the warranty attached to it?
6. If part of the code were protected by no copyright, what in this contract would prevent me from seeing that code reused at a competitor's?
7. What is missing from this contract compared with a complete development contract under Belgian law?

The seventh is the most useful. It is the only one that asks what is not there.

The sixth is the one almost nobody asks.

Translated from the French original published on 7 September 2026. The analysis concerns Belgian and European Union law. Read the French original.