When a company funds custom software development, the question of source code ownership often comes up late in discussions, sometimes after the contract is signed. Yet this is what determines what you can do with your own system when you change vendors or decide to bring development in-house.
Three different terms get conflated in this question: source code, the data model, and the data itself. Each follows distinct legal rules and requires a specific assignment clause. What complicates things is that standard service contracts often address only one of these three dimensions, because the other two seem obvious. They are not.
This article does not cover what to ask for in an assignment clause in general: it covers what you need to receive, concretely, on exit day. A list of dated deliverables, transmissible to your legal counsel, therefore verifiable before contract closure.
Three different things we confuse: code, data model, data
Source code is the set of files that make up the software: modules, libraries, deployment scripts, configurations. This is what courts call a work of authorship, protected by copyright. Without an explicit assignment, the author remains the owner, even if the client paid for the development.
The data model is the database structure: tables, relationships, constraints, indexes. It is distinct from source code because it can be reused with different software, or migrated to another platform, and because modifying it often creates operational impacts that code-only changes do not produce. A contract that assigns the code but remains silent on the database schema leaves an essential asset outside your scope.
The data itself is the content of your tables: your customers, transactions, business references. You always own it, because you are the data controller under GDPR and Moroccan law 09-08. But legally owning it does not guarantee you can extract it in practice: you need a usable format, model documentation, and export tools that work without vendor assistance.
All three objects must be assigned in the contract. Omitting a single one is enough to block reversibility.
What applies by default when the contract is silent on assignment
Under Moroccan law, service contracts follow articles 723 and following of the DOC (Code of Obligations and Contracts). The contract for work stipulates that the worker or contractor retains ownership of what they produce, unless otherwise agreed. In other words, if the contract says nothing, the code stays with the vendor, even if you funded the entire development.
French law applies the same principle via article L. 131-3 of the Intellectual Property Code: copyright does not transfer automatically, even for commissioned work. An assignment must be written, detailed, and bounded by object (usage, territory, duration). Contract silence equals non-assignment.
In both cases, the vendor retains a personal right to use their own code, unless there is an exclusivity clause. This means a component developed for you can reappear, in a reusable form, in a competing project. The countermeasure is a dedicated work clause, stating that the development is performed exclusively for your business need and cannot be commercialized elsewhere.
Finally, the right of use the client gets by default is an exploitation right limited to the contractual scope. You can use the software for its intended purpose, but not modify it, redistribute it, or evolve it yourself. For all that, you need a complete assignment of economic rights.
The assignment clause: scope, transfer moment, interim deliverables
A properly drafted assignment clause specifies three things: what is assigned, when the transfer occurs, and what is delivered at each stage.
The assignment scope must enumerate the transferred rights: reproduction, modification, adaptation, integration into third-party systems, distribution. It must also cover derivative works, because an assignment covering only the initial code does not authorize you to create an improved version without renegotiating with the author. Finally, it must mention the data model and database schemas explicitly, because their legal status remains unclear in Moroccan case law and contract silence can be interpreted as non-assignment.
The transfer moment is often final acceptance, meaning the process-verbal acknowledging deliverable compliance. But this logic creates a problem: if acceptance occurs three months after production deployment, and you change vendors in between, you do not yet own the code running on your servers. A safer alternative is transfer upon delivery of each batch, conditional on payment of the corresponding installment. This gives you progressive control, batch by batch, and allows the vendor to retain a guarantee on what has not yet been paid.
Interim deliverables must be defined in the contract, documented in a reversibility schedule. A complete deliverable includes versioned source code (with Git history if you requested its preservation), technical documentation (architecture, APIs, deployment procedures), database migration scripts, and test datasets. These elements must be handed over at each milestone, not only at project end, because documentation written six months after code delivery often has less value than documentation contemporary with development.
Reversibility: the exact list of what you receive on exit day
Reversibility is the set of operations that allow transferring the system to another vendor, or bringing it in-house, without service loss or data degradation. It is not limited to a source code copy: it includes everything necessary for the new vendor to understand, run and evolve the system without the exiting team's assistance.
Here is the standard reversibility list, the one legal counsel or a CTO can verify before contract closure:
- Complete and versioned source code: all modules, internal libraries, deployment scripts, configuration files, with Git history if the repository was maintained throughout the project. Delivery format must be specified (zip archive, access to a private Git repository, or GitHub repository ownership transfer).
- Up-to-date technical documentation: architecture diagram (component diagrams, data flows), API documentation (OpenAPI specifications or equivalent), deployment guide (system prerequisites, installation procedure, environment variables), operations guide (backup procedures, restoration, version upgrades).
- Complete data export in usable format: SQL dump for relational databases, JSON or CSV export for NoSQL databases, with a documented schema indicating the role of each table and column. If data contains sensitive information (personal data, trade secrets), the export must be encrypted and accompanied by a decryption procedure.
- Migration and test scripts: SQL scripts or equivalent to rebuild the database schema, anonymized test datasets to validate the system works after transfer, referential integrity verification procedures.
- Access and secrets transfer: API keys, SSL certificates, third-party service credentials (mail servers, payment gateways, cloud services), with a secrets rotation procedure after transfer to prevent the old vendor from retaining residual access.
- Handover training for the takeover team: transition workshops with the new vendor or internal team, documentation of technical choices and business decisions, technical question responses during a transition period (typically 30 days after closure).
Each item on this list must be dated in the reversibility schedule, because incomplete delivery on exit day blocks takeover and leaves you dependent on the old vendor to complete the transfer. If the contract does not specify deadlines, case law applies a reasonable delay, which is often too long for operational needs.
Code escrow: when it really protects, when it is an alibi
Code escrow is a deposit of source code with a trusted third party, who releases it to the client if certain conditions occur: vendor bankruptcy, support cessation, non-compliance with contractual obligations. It is often presented as a continuity guarantee, but it only is if three conditions are met.
First, the deposit must be updated regularly, ideally at each version delivery. An escrow containing initial version code, while the production system is at version 12, protects no one. The contract must therefore specify deposit frequency and penalties for delays.
Second, the escrowed code must be complete: modules, libraries, scripts, documentation, test data. A deposit containing only application code, without dependencies or technical documentation, is insufficient to restart the system on different infrastructure. The escrow clause must therefore reference the complete reversibility list, and the escrow agent must verify, at each deposit, that all elements are present.
Third, escrow release conditions must be verifiable without negotiation. A clause stating the code is released "in case of serious vendor default" leaves room for interpretation, therefore litigation. A clause stating the code is released "if the vendor does not respond to three support requests spaced 15 days apart" is verifiable by any third party, therefore enforceable without court recourse.
In practice, escrow is mainly useful in long-term contracts (three years or more) where vendor bankruptcy risk is real, or in critical projects where system downtime would cause immediate financial losses. For short projects or for well-established medium-sized vendors, the complete assignment clause, with progressive code and documentation delivery, often offers equivalent protection at lower cost.
Why exit cost must be priced in the entry contract
Reversibility has a cost, because it requires the vendor to maintain up-to-date documentation, structure the code so it is readable by an external team, and plan handover workshops at project end. This cost is often invisible in commercial offers, diluted in the global price, but it becomes visible on exit day if the contract specified nothing.
A contract that does not price reversibility leaves the vendor free to bill the handover at the rate they deem reasonable. In practice, this often means a high time-and-materials rate (equivalent to 120-180 EUR per senior day), billed over a duration that depends on existing documentation quality. If documentation was not maintained during the project, the handover can take several weeks.
The countermeasure is to price reversibility in the initial contract, as a handover package included in the global price, or a number of post-delivery support days included in the rate. This package must cover takeover team training, technical question responses, and correction of anomalies discovered after transfer. It must also specify that reversibility deliverables (documentation, scripts, data export) are provided at no extra cost, because they are an integral part of the contractual deliverable.
Finally, the contract must provide a penalty for incomplete delivery of reversibility elements, because a vendor who knows they can bill the handover at the rate they choose has no incentive to maintain usable documentation during the project. The penalty must be proportionate to the damage (typically, the cost of reconstituting missing documentation by the new vendor), so it must be priced in the contract, not left to the judge's assessment.
The one-page checklist for your legal counsel review
Before signing a custom development contract, transmit this checklist to your legal counsel or CTO. It enumerates the points that must appear in the contract for exit to be possible without litigation.
Source code ownership:
- Complete economic rights assignment clause (reproduction, modification, adaptation, distribution, derivative works).
- Explicit mention of data model and database schema assignment.
- Dedicated work clause if you wish to prohibit code reuse in a competing project.
Transfer moment:
- Progressive transfer, batch by batch, conditional on corresponding installment payment.
- Or global transfer at final acceptance, with a guarantee clause maintaining your usage rights between delivery and acceptance.
Reversibility deliverables:
- Complete and versioned source code (delivery format specified).
- Up-to-date technical documentation (architecture, APIs, deployment, operations).
- Complete data export in usable format, with documented schema.
- Migration scripts and test datasets.
- Access and secrets transfer, with rotation procedure.
Exit cost:
- Handover package included in global price, or number of post-delivery support days.
- List of deliverables provided at no extra cost.
- Penalty for incomplete delivery, priced in the contract.
Code escrow (optional):
- Deposit frequency (at each version delivery).
- Deposit scope (code, documentation, test data).
- Release conditions verifiable without negotiation.
This checklist can be annexed to the contract as a reversibility schedule, detailing for each deliverable the delivery date, format, and person responsible for control. It transforms a general assignment obligation into a series of verifiable commitments, therefore enforceable without court recourse.
Want to understand how to structure custom development that stays under your control, or discuss the technical and legal trade-offs that protect your software investment? Contact us for an uncommitted discussion.
FAQ
Does the source code automatically belong to me if I paid for development?
No. Under Moroccan law as under French law, source code remains the property of the author (the vendor) unless there is an explicit assignment clause in the contract. Payment gives you a right of use limited to the contractual scope, but not the right to modify, redistribute or evolve the software without the vendor's agreement. To obtain complete ownership, the contract must include an economic rights assignment clause covering reproduction, modification, adaptation and distribution, including for derivative works.
What is the difference between source code assignment and data model assignment?
Source code is the set of files that make up the software (modules, libraries, scripts). The data model is the database structure (tables, relationships, constraints, indexes). Legally, they are two distinct objects: a contract can assign the code without assigning the database schema, which leaves you owning the software but dependent on the vendor for any data structure modification. A complete assignment clause must explicitly mention both objects.
What should I concretely receive when I change vendors?
Complete reversibility includes six elements: versioned source code with history, up-to-date technical documentation (architecture, APIs, deployment), data export in usable format with documented schema, migration scripts and test datasets, access and secrets transfer (API keys, certificates, credentials), and takeover team training. Each element must be delivered in a format specified by the contract, and delivery must be dated in a reversibility schedule.
Is code escrow mandatory to protect my investment?
No. Code escrow is useful in long-term contracts or for critical projects, as it guarantees you can recover the code in case of vendor bankruptcy. But it does not replace a complete assignment clause: an escrow containing code you do not own does not authorize you to modify or redistribute it. Optimal protection combines progressive code assignment (batch by batch) with an escrow updated at each delivery, and release conditions verifiable without negotiation.
How do I avoid having exit cost billed at the rate the vendor chooses?
By pricing reversibility in the initial contract, as a handover package included in the global price or a number of post-delivery support days. The contract must specify that reversibility deliverables (documentation, scripts, data export) are provided at no extra cost, and it must provide a penalty for incomplete delivery. This penalty must be priced, proportionate to the cost of reconstituting missing documentation by the new vendor, because a penalty left to the judge's assessment often produces no deterrent effect.