Code and Data Ownership in Custom Software
What the contract should say about source code, data, libraries, access, delivery, and continuation of a custom software project.
By Η ομάδα της Argonstack, TechIns Group
The phrase "the software will belong to us" is not enough. In a custom project, the source code, data, design, documentation, pre-existing libraries, third-party licenses, infrastructure, and the right to continue development with another team must all be clearly separated.
If these are not defined before the project starts, disputes typically surface when the client asks for repository access, changes providers, or requests a data export. The matter is not settled by who paid for the development. It is settled by the contract and the applicable law.
This article is a business guide, not legal advice. The final contract should be reviewed by a lawyer with expertise in intellectual property and technology.
What source code ownership actually means
Source code is the material developers use to build and modify an application. Access to the code does not necessarily equate to the transfer of all rights. A company may hold a copy of the repository but have only a limited right of use. It may also hold an exclusive license to use the software without having acquired every component that was used to build it.
The European Directive 2009/24/EC protects computer programs under copyright law. The contract must specify precisely which rights are transferred, when they are transferred, for which territory, and whether any restriction on use or modification applies.
Four categories of code
The code in a project is usually not a single, uniform thing. It includes new code written specifically for the client, the provider's pre-existing tools, open source libraries, and commercial third-party services.
The new, purpose-built code can be transferred to the client or licensed to them. The provider's pre-existing frameworks usually remain with the provider, with a right of use embedded within the deliverable. Open source libraries follow their own licenses. Third-party services, such as cloud, maps, email, or AI APIs, are governed by the terms of the respective providers.
If a contract simply states that "the client acquires all the code," without these exceptions, it may be promising something that is not technically or legally possible.
The client's data
The contract must state that the client's business data remains under their control. It must define how the data is entered, where it is stored, who has access to it, how backups are created, and how it is exported after the engagement ends.
For personal data, roles must additionally be defined in accordance with the GDPR and, where the provider acts as a data processor, an appropriate Data Processing Agreement is required. "Data ownership" does not replace personal data protection obligations.
What must be delivered
The real ability to continue a project requires more than a zip file with source code. It requires repository access, installation instructions, environment variables (without disclosing non-transferable secrets), the database schema, API documentation, a list of dependencies, the deployment process, the backup process, and an inventory of third-party accounts.
It must also be defined who controls the domain, cloud account, app store accounts, analytics, email services, and signing keys. Wherever feasible, critical accounts should belong to the client, with the provider granted controlled access.
When rights are transferred
A common commercial approach is to transfer the agreed rights upon full payment. This must be stated explicitly. At the same time, the contract must define what happens if the project is discontinued before completion, which deliverables have been paid for, and what usage rights the client acquires over work already delivered. The relevant commercial terms are described in Argonstack's Terms and Conditions.
Vendor lock-in and the right to exit
Dependence on a provider is not always a bad thing. Every complex system requires specialized expertise. It becomes risky, however, when the client cannot obtain their data, documentation, or access to critical accounts.
A serious contract includes an exit plan. It defines the export format, the delivery timeline, the transition period, the cost of any additional support, and the deletion of copies once the legal retention obligations have expired.
Source code escrow
For critical systems, source code escrow may be agreed upon. An up-to-date copy of the code and documentation is held by an independent third party and released only in specific circumstances, such as the provider ceasing operations or a serious inability to provide support.
Escrow does not replace proper documentation and sound architecture. If the material is not kept up to date or cannot be installed, its existence has limited practical value.
What the client should ask before signing
The client should ask for a clear definition of the deliverables, the rights to the custom-built code, the exceptions, third-party licenses, repository access, account ownership, data export, documentation, maintenance, and the exit plan.
Argonstack structures every custom project with a clear scope and technical architecture. The terms of ownership and delivery should be captured in the project's specific contract and reflect the actual working model.
Next step
Define scope, rights, access, and an exit plan before development begins.
Frequently asked questions
If I pay for the development, do I automatically own the code?
Not necessarily. Payment and the transfer of rights are separate matters. The contract must define exactly what the client acquires.
Can open source libraries belong to me?
Not in the sense of exclusive ownership. They are used in accordance with their own licenses. The provider must disclose the critical dependencies and the obligations that come with them.
Should the cloud account be in the client's name?
For critical custom infrastructure, this is often the safer choice, provided access is properly managed. For a SaaS product, this is usually not applicable, since the shared infrastructure belongs to the provider.
What matters more than the phrase "the code belongs to me"?
The actual ability to operate, export data, maintain, and transition the system. Without documentation, accounts, and a deployment process, theoretical ownership may have little practical value.
