Reversibility and source code ownership: what the clause has to say
"The source code is yours" is the most repeated and least verified sentence in software proposals. The gap between an enforceable assignment of rights and a carefully worded licence only becomes visible when you try to leave — which is to say, too late.
Assignment
of economic rights written into the contract, not a usage licence
Your repository
the code lives from day one in a repository you own
Documented exit
reversibility procedure, operating documentation and data export
Reversibility and source code ownership are not settled by a line in a brochure but by five or six precise clauses. An organisation that wants to be able to take back the source code of its software should verify, before signing, that those clauses exist — and that what they describe is physically executable on the day the supplier is no longer there.
What "you own the code" has to mean to be true
Under French law the developer holds the rights to the software they write unless a contract says otherwise. Paying for the work transfers nothing automatically. The transfer must be written, and a valid assignment of economic rights states which rights are assigned — reproduction, modification, adaptation, distribution — their territorial extent, their duration, and the fact that the assignment is exclusive. Without those details, what you bought is a right of use, not an asset.
| What is often written | What you need instead | |
|---|---|---|
| Nature of the right | "Perpetual, non-exclusive licence to use" | Exclusive assignment of economic rights, itemised, unlimited in time and territory |
| Right to modify | Not mentioned, therefore not granted | Right to modify and adapt granted explicitly, including through a third party of your choosing |
| Where the code lives | A repository owned by the supplier, access revocable | A repository your organisation owns, with your own administrator accounts |
| Handover | An archive sent at the end of the project | A complete commit history, kept up to date throughout the project |
| Infrastructure | "Hosting provided by the supplier" | Infrastructure configuration versioned alongside the code, with a reproducible deployment procedure |
| Data | Export on request, format to be agreed | Full export in a documented format, executable by you, tested during the project |
The six conditions of real reversibility
Assignment, not licence
An exclusive assignment of economic rights, listing the rights transferred and naming the right to modify. Without the latter you own software you are not entitled to change.
A repository you own
The code is pushed from the first sprint to a repository whose owner account belongs to your organisation. You do not wait until the end of the project to check it exists, and you depend on no access a third party can revoke.
Operating documentation
Not marketing material: how to install, configure, back up, restore and upgrade. Environment variables, dependencies, scheduled jobs, service accounts and the disaster-recovery procedure.
Reproducible infrastructure
Server configuration, database and deployment chain are described in files versioned with the code. The test is simple: a competent third party must be able to stand the application up on fresh hosting.
No blocking proprietary component
The technical base rests on open, widely used components. No in-house framework, no module whose sources the supplier keeps, no service you cannot replace.
Exportable, documented data
A full export in a readable format, together with the database schema and the meaning of each table. A database returned without a data dictionary is a file, not an asset.
The classic traps
- A perpetual non-exclusive licence presented as an assignment: you may use the software, the supplier may resell it, and nobody but the supplier may lawfully modify it.
- Code handed over but infrastructure not reproducible: the archive is complete, yet nobody can stand the application back up because the production configuration was never written anywhere but in one administrator's head.
- Dependency on an undocumented in-house component: an internal framework, a rules engine, an authentication library the supplier reuses across every client and never assigns.
- A repository owned by the supplier: you have read access, they own the organisation, and the access disappears the day you disagree.
- Secrets never handed over: certificates, API keys, domain names and hosting accounts registered in the supplier's name. The code is yours; production is not.
- A reversibility clause with no procedure: "the supplier undertakes to facilitate reversibility" commits to nothing. You need a deadline, a defined deliverable and a consequence for failure.
What a buying group should require in its contract
- An exclusive assignment of economic rights, listing reproduction, modification, adaptation and distribution, unlimited in duration and territory.
- An obligation to push the code, continuously and not at project end, to a repository the organisation owns, with the full history.
- A named list of documentation deliverables: installation, operations, data schema, backup and restore procedures.
- A commitment that the software depends on no proprietary component of the supplier — or, failing that, the explicit assignment of that component.
- A reversibility procedure priced in advance: contents, execution deadline and any support fee, fixed in the contract rather than negotiated at the point of separation.
- Named transfer of hosting accounts, domain names, certificates and technical secrets, with an inventory kept up to date.
What the exit procedure looks like
Exit inventory
A list of repositories, environments, third-party accounts, domain names, certificates and data sets. It is maintained during the project, not reconstructed at the point of departure.
Transfer of access and ownership
Owner accounts move into your name: repository, hosting, database, external services. Our access becomes revocable by you, rather than the other way round.
Clean rebuild on a fresh environment
The step that makes reversibility verifiable: the application is reinstalled from the repository and the documentation, on untouched infrastructure, with your team or your new supplier present.
Knowledge transfer and closure
Handover sessions on the architecture, the business rules and the known pitfalls, then delivery of the final pack. The date our access ends is written down.
MEKANO applies these clauses to its own contracts: we work at a fixed price, the code is handed over, operating documentation is part of the deliverables, and reversibility is written in. We build the management applications of small and mid-sized companies and of buying groups — member portals, supplier approval, revenue declarations, year-end rebate engines, document management — on a Go, React and PostgreSQL base, with no in-house proprietary framework. An organisation whose critical process depends on a piece of software cannot afford for that software to be somebody else's asset.
Frequently asked questions
- Is a perpetual licence not enough?
- No, and the distinction is decisive. A perpetual licence lets you use the software indefinitely; it gives you neither the right to modify it, nor exclusivity, nor the ability to hand its evolution to another supplier. The day you want to change partner, the question is not whether you may keep using the tool — it is whether anyone else is allowed to touch it. Only an exclusive assignment of economic rights, naming the right to modify, answers yes.
- When is the code handed over?
- Continuously, from the first sprint. The repository belongs to your organisation and we push our work into it as we go: you do not wait until the end of the project to see what you hold. A single handover at the close of an engagement is a signal worth watching — it prevents any verification while the balance of power is still even, and leaves open the question of whether the archive is complete.
- How can we check that reversibility is real before the project ends?
- By testing it. The only serious check is to stand the application back up from the repository and the documentation, on an untouched environment, with someone who did not take part in the build. That test can be scheduled as early as the second milestone rather than at exit. In a single day it exposes undocumented dependencies, missing secrets and installation steps that only ever lived in the team's memory.
- What happens if you cease trading?
- You keep the repository you own, the operating documentation, the access inventory and your data in a documented format. The application runs on open, widely used components with no in-house framework, so another competent supplier can pick up maintenance. That is precisely the point of not building on a proprietary base — the continuity of your tool does not depend on the continuity of our company.
- Is data migration included?
- Yes, in both directions. On the way in, migration from the existing tool is priced inside the fixed fee, cleaning and reconciliation included. On the way out, a full export in a documented format, with the database schema and the meaning of each table, is a contractual deliverable. A database returned without a data dictionary forces whoever takes over to re-derive the meaning of every column, which costs weeks.
Read next
Fixed-price development: what the model actually puts on each side
A billing model is not an administrative detail: it decides who loses money when a project slips. Fixed price moves that risk to the supplier, time and materials leaves it with the client. Both are defensible — provided you know which situation you are in before signing.
Read moreReplacing an obsolete ERP or an abandoned proprietary application
A management system does not die overnight. It slowly becomes impossible to change: the vendor has stopped answering, the developer who wrote it has left, the language version is out of support. At that point the question is no longer technical — it is which exit costs least.
Read morePhased delivery with formal acceptance: how a project actually runs
A software project is not judged on its opening schedule but on what happens in month four, when a forgotten rule surfaces and the switchover date is closing in. Batch delivery and formal acceptance exist to make that moment manageable rather than adversarial.
Read moreManagement applications for buying groups and member networks
The pillar: supplier approval, revenue declarations, rebate calculation, document management and a member portal, in one platform fitted to your rules.
Read moreLet's talk about your situation
Thirty minutes, no commitment. You leave with a straight answer on feasibility, a budget order of magnitude and the next steps.
Book the call