It is a classic scenario. The software has been delivered, the invoices have been paid, and the application is running. But then, as a client, you want to switch to another party, or as an agency, you want to reuse your own developed modules for a new client. Suddenly, you find yourselves diametrically opposed to each other over that one question: “Whose code is it, actually?”
Many entrepreneurs and developers think this is simple: “Whoever pays the bills calls the shots.” Unfortunately, that is not the case. In the world of software development, that is a dangerous misconception. We dissect four pitfalls that can cause your contract to fall apart.
The “copyright paradox”: paying the invoice is not a transfer of ownership
The most persistent myth is that payment of the final invoice automatically means the client becomes the owner of the software.
The law is unequivocal on this point: copyright originates with the creator (the agency or the freelance developer). The fact that a client pays for the development changes nothing. Without a contract explicitly transferring copyright, the intellectual property remains 100% with the developer.
So what does the client actually have? Usually, payment implies only a user license. You may use the software for the purpose for which it was created. But are you allowed to modify the code? Resell it? Or take it to another IT partner? Without that written transfer, the answer is often “no”.
The golden cage: ownership versus possession of the source code
Even if you are the legal owner, your business can still be held hostage. This phenomenon is called vendor lock-in. It might be a buzzword, but in practice, it is a technical stranglehold.
Vendor lock-in means that you are so dependent on a single supplier that switching to a competitor is practically impossible. With custom software, this often arises from a lack of access to the source code.
Often, a developer only provides the object code. This is the compiled sequence of zeros and ones that the computer understands. Your software works with it, but no human can read or modify it. The source code, on the other hand, is the readable blueprint (in PHP, Java, Python, etc.). Don’t have that? Then you have to go back to your original agency for every bug fix or update. They can dictate the price, because another partner can do nothing with just the object code.
The solution lies in an exit-proof contract. You prevent this hostage situation by making clear agreements in advance. A good IT contract contains specific clauses regarding the actual delivery:
- Definition of delivery: you stipulate that delivery means not only that the software works, but also that the complete, readable source code and technical documentation have been handed over.
- The moment of transfer: agree on when you will receive the code. Is that after every sprint? At the end of the project? Or only after payment of the final invoice?
- Accessibility: ensure that you, as a customer, have access to the repository (such as GitHub or GitLab), so that you know for sure that you always have the latest version.
The nuance for agencies: custom work vs. background IP
We frequently act for agencies (and are a legal partner of FeWeb). For them, a client’s demand of “I want all the rights” is often impossible to fulfill. A modern agency almost never writes 100% new code from scratch. They build on their own foundation: libraries, frameworks, and standard modules that they have developed over the years. We call this Background IP or standard software.
If an agency were to transfer ownership of this code to Client A, legally speaking, they would no longer be allowed to use that code for Client B. That would mean the end of their business model. At the same time, Client A does not want to be left empty-handed if they ever wish to leave the agency.
The solution is a hybrid licensing model, which means that your contract makes a strict distinction between two streams of code, each with its own legal regime:
- Foreground IP (custom work): this is the unique code, logic, and “look & feel” developed specifically for the client.
Legal status: Here, as an agency, you transfer full intellectual property to the client. The client becomes the owner and may do with it what they wish.
- Background IP (the toolbox): these are the generic modules of the agency (e.g., a CMS core, an authentication module, API connections).
- Legal status: the agency remains the owner.
- The critical license: the client receives a non-exclusive license for this.
Please note: A “standard license” is not sufficient for the client here. To avoid vendor lock-in, this license must meet very specific conditions. The contract must state that this license:
- Is worldwide, perpetual, and non-cancellable (so that the agency cannot pull the plug).
- Grants the right to use the software *and* have it maintained by third parties (so that another IT partner may view and modify the code for the client).
- Is transferable (so that the license transfers if the client sells their business).
Only with this “enhanced” license is the client safe, without the agency giving away its crown jewels.
The AI revolution: who is the author of the “Prompt code”?
Nowadays, a significant portion of source code is generated by AI tools such as GitHub, Copilot, or ChatGPT. This is causing a legal earthquake.
- No human, no copyright
According to current Belgian and European legislation (Book XI of the Belgian Economic Law Code (WER)), only a human creation can be protected by copyright. If software is 100% generated by AI without substantial human intervention, then it simply has no copyright.
- The danger
If the code is not protected by copyright, anyone (including your competitor) can theoretically copy that code without you being able to do much about it legally.
- The human touch
To become the owner, there must be “creative choices” by the developer. Writing a complex architecture or specifically refining AI output does count. But who proves which part was written by a human and which part by a machine?
Questions about contracts in software development?
Our team is happy to assist you. Book a free introductory meeting via the link on the right, or send an email to info@siriuslegal.be.
Pro tip: Software Escrow as extra security
Sometimes a developer is unwilling or unable to transfer the source code immediately (for example, for ongoing SaaS services). In that case, a software escrow-arrangement is the solution. The source code is deposited with an independent third party. Should the developer go bankrupt or fail to meet their obligations, the customer will still gain access to the code via the escrow agent. It is the ultimate insurance for the continuity of your business.