The short answer: Paying for software development does not automatically give you the source code or an unrestricted right to modify the application and hand it over to another supplier. It depends on who created the software, the capacity in which they worked and what the contract says. In addition to rights to the code, secure the repository, documentation, accounts, data and a verified deployment procedure.
First, distinguish between rights, files and operations
The statement „the customer owns the code" can refer to several different things:
- who exercises the economic rights to the software;
- what licence the customer has obtained and how broad it is;
- who can access the source files and change history;
- whose name the cloud, domain and development accounts are registered under;
- who may modify, deploy and hand the application over to another team;
- who may export operational data and restore the system from a backup.
These questions are not interchangeable. A company may have a broad licence but lack the current source code. It may hold a copy of the repository but lack permission to provide it to a new supplier. And it may have both, yet still be unable to run the application without the database, keys and documentation.
The practical objective is therefore not to „own a ZIP file". It is to have both the legal and technical ability to operate, modify, back up and safely take over the system without depending on a single person.
What the Autorský zákon provides
As of 2 October 2026, e-Sbírka lists the version of zákon č. 121/2000 Sb. effective from 1 July 2025. The provisions particularly relevant to custom software are § 58, § 61 and § 66 autorského zákona, zákona č. 121/2000 Sb..
The author of a software program is the natural person who created it. It is therefore not legally sufficient to state that the customer „becomes the author" or that authorship is transferred to the customer. The contract should specify precisely who exercises the economic rights, the scope of the licence and the obligation to deliver the source code.
The default legal position varies depending on who actually creates the software:
| Who creates the software | Default legal position |
|---|---|
| The customer’s employee | If the employee created the software in fulfilment of duties arising from an employment or service relationship, the customer, as the employer, may exercise the economic rights to the employee work under § 58 odst. 1, unless otherwise agreed. |
| An individual author commissioned directly | Under § 58 odst. 7, a computer program that is not a collective work and was created by an author on commission is treated as an employee work, with the customer treated as the employer; the customer therefore exercises the economic rights unless otherwise agreed. |
| Employees of a software development company | If they created the software in fulfilment of duties arising from an employment or service relationship, their employer—the supplier—may exercise the economic rights to the employee work under § 58 odst. 1, unless otherwise agreed. The customer needs rights agreed with the supplier. |
| Freelancers and other subcontractors | The supplier must have the necessary rights to every incorporated component and be entitled to grant the customer the agreed scope of rights. |
For computer programs created by an author on commission, § 61 autorského zákona does not apply pursuant to § 58 odst. 7. The general rules governing commissioned works therefore cannot be relied upon as a substitute for a precise software contract.
Another specific issue concerns the assignment of the exercise of economic rights. Under § 58 odst. 1, an employer may assign this right to a third party only with the author’s consent, except where the assignment occurs as part of a transfer of a business establishment. If the customer specifically requires the exercise of these rights to be assigned, the supplier must verify that it has obtained the necessary consents. In practice, a precisely drafted licence may be more appropriate; the correct solution depends on the relationship between the authors, supplier and customer.
Under § 66 odst. 1 autorského zákona, an authorised user of a copy of a program does not infringe copyright by modifying the program where this is necessary for its use, including its installation and operation, or by correcting errors. The user may also make a backup copy where this is necessary for the use of the program. However, this provision does not in itself ensure the delivery of readable source code, repository history, documentation or access to the infrastructure.
This is a general overview, not a legal assessment of a specific contract. Before signing, have the document reviewed by a lawyer specialising in copyright and IT law.
What the contract should cover
1. Scope of rights to the software
A statement that „the customer may use the application" is not enough. At a minimum, the contract should answer the following questions:
- May the customer operate the application on its own or rented infrastructure?
- May the customer modify it using its own employees or another supplier?
- May the customer create development, testing, backup and training instances?
- May the customer disclose the source code to an auditor, administrator or purchaser of the business?
- Do the rights also cover modules and updates commissioned later?
- Is the licence exclusive or non-exclusive?
- Does it apply without limits on time, territory or quantity?
- Will the rights remain in effect after the service agreement ends?
The scope must reflect the intended use. An internal record-keeping system for a single company requires different rights from a platform that the customer intends to offer to its clients.
2. A continuously accessible repository
The source code should not be delivered only at the end as an archive with no history. A safer approach is to store it continuously in the customer’s organisation on GitHub, GitLab or Azure DevOps. The customer should have administrator access, while the supplier should have only the permissions required for development.
The repository should contain everything required to build and deploy the agreed part of the system:
- frontend and backend;
- database migrations;
- automated tests;
- dependency declarations and their locked versions;
- build and deployment scripts;
- CI/CD configuration;
- container or infrastructure definitions;
- a configuration template without real passwords or keys.
Repository credentials do not belong in the repository. The contract should specify separately where secrets are stored, who manages them and how they will be securely handed over or rotated.
3. Code provenance and subcontractor rights
The supplier does not necessarily write the entire system from scratch. An application will typically combine:
- code created specifically for the customer;
- the supplier’s pre-existing modules;
- open-source packages;
- paid third-party components and services;
- parts created by freelancers or generative tools.
The contract or technical appendix should distinguish between these categories. For subcontracted work, require confirmation that the supplier has obtained the rights needed to grant the agreed licence. For the supplier’s pre-existing modules, it must be clear whether you may continue to operate and modify them and entrust them to another administrator after the relationship ends.
Automatically generated code is no reason to lower review standards. Responsibility for its integration, security and provenance must remain part of the development process, as explained in AI-generated code: who reviewed it before it reached users?.
4. List of libraries and licences
A package.json, requirements.txt or composer.json file alone is not a sufficient dependency inventory. You also need the versions actually used, including transitive dependencies, and their licences.
MIT, Apache License 2.0, GPL and AGPL impose different conditions. A supplier cannot grant the customer broader rights than it has received from the component’s author. The handover should therefore include an up-to-date inventory of components and licences, or a machine-readable software bill of materials.
Paid templates, fonts, map data, connectors, external APIs and cloud services should be identified separately. Source code alone may not be enough if a key function depends on a non-transferable licence or an account registered solely to the supplier.
5. Documentation verified by deployment
Documentation should not merely describe the application’s screens. At a minimum, a new team will need:
- an overview of the architecture and individual services;
- supported runtime versions;
- build and deployment instructions;
- the database schema and migrations;
- a list of integration interfaces;
- configuration variables without their secret values;
- backup and restoration procedures;
- operational checks, logging and solutions to known issues;
- a disaster recovery procedure.
A clean environment provides the most reliable acceptance test. A developer who has not previously worked on the project receives only the agreed repository, documentation and access credentials. Using these materials, the developer must be able to build the application, run the tests, deploy a test instance and restore a copy of the data.
The restoration should actually be performed rather than merely checking that backup files exist. The same principle is discussed in Backup restoration testing: how to perform and document it.
6. Accounts under the customer’s control
The following should generally be registered to the customer:
- the domain and DNS management;
- the cloud account and billing;
- the repository and container registry;
- production and backup environments;
- the email delivery service;
- monitoring and centralised logs;
- mobile app store accounts;
- certificates, backups and identity administrators.
The supplier should receive a named account with an appropriate role. A shared password with no traceability or multi-factor authentication makes both auditing and access revocation more difficult.
If the supplier operates the application in its own environment, the contract must describe the export, migration and assistance to be provided upon exit. Merely stating that „hosting is provided by the supplier" does not explain how the customer can take over the system.
7. Data and the exit plan
Rights to the source code do not automatically cover operational data. The contract should therefore specify:
- which data will be handed over;
- in what format and structure;
- whether the export includes attachments, metadata and relationships;
- how encryption keys will be handed over;
- how the completeness and readability of the export will be verified;
- who will provide assistance with the migration;
- when the original supplier’s accounts will be revoked;
- how remaining copies of the data will be handled.
The exit plan should be prepared when the relationship begins, not only after a dispute arises. Practical steps for accounts, passwords and documentation are also summarised in Has your IT specialist left? How to take over and hand over company IT.
A weak handover versus a transferable system
| Weak arrangement | Transferable system |
|---|---|
| Only the supplier manages the repository | The customer has administrator access |
| A ZIP file with no history is delivered at the end | Code is continuously committed to a shared repository |
| The contract permits only „use" | The rights expressly cover operation, modification and handover |
| Dependencies are not recorded | The handover includes component versions and their licences |
| Only one developer knows how to deploy the system | The procedure is documented and verified in a clean environment |
| Cloud accounts belong to the supplier | The customer owns the accounts and assigns roles |
| The export is a spreadsheet without attachments | The export includes data, relationships, files and metadata |
| A backup merely exists | Restoration has been performed and documented |
A lower quoted price does not necessarily mean a lower total cost. Reconstructing database migrations, tracing undocumented dependencies or manually converting data can make a later change of supplier significantly more expensive.
Warning signs before signing
Be cautious if the supplier:
- describes the repository as a purely internal matter;
- refuses to disclose the libraries and licences used;
- offers to run the system only in its own account without an export procedure;
- promises documentation only after completion;
- refuses to identify subcontractors or the origin of incorporated modules;
- claims that paying the invoice automatically resolves everything;
- cannot demonstrate deployment from the source code;
- provides data only as a spreadsheet without files or relationships.
A verbal assurance that „the code is obviously yours" is no substitute for specific contractual provisions and technical acceptance testing.
If you need to review the repository, access credentials, backups and deployment options before signing or when changing suppliers, ITHOPE handles this as part of its small-business IT audit. If you commission the application directly from us, the terms described under custom software development apply: we deliver without vendor lock-in, the code and data remain yours, and we can also operate the solution locally in Brno. You can submit your requirements through our no-obligation enquiry form. The outcome should be a specific list of missing rights, files, accounts and steps required for a safe takeover, rather than a general assessment.
What to check during handover
Before paying the final instalment, verify at least the following:
- the customer has administrator access to the repository;
- the repository contains the current production version;
- the contract permits the agreed operation, modifications and involvement of another supplier;
- the supplier has documented its rights to third-party components;
- the versions and licences of all dependencies are known;
- a clean instance can be built and deployed from the source code;
- the tests can be run according to the documentation;
- the database migrations correspond to the production schema;
- a complete export includes data, attachments and metadata;
- the backup can be restored;
- the customer controls the domains, cloud services and key accounts;
- secrets are not stored in the source code;
- a procedure is ready for revoking the original team’s access.
Frequently asked questions
Do we own the source code if we have paid the invoice?
Paying the invoice alone is not enough. The answer depends on how the software was created, the author’s relationship with the supplier, the customer’s contractual rights and the provisions governing delivery of the source files. An invoice confirms payment; it does not automatically determine the scope of the licence or the completeness of the handover.
Is delivering the source code in a ZIP file enough?
No. An archive will usually omit change history, branch settings, deployment automation and a record of the versions used. Without documentation, database migrations, access credentials and a verified build process, such a copy may be practically unusable.
May the supplier use its pre-existing modules?
Yes, provided it has the necessary rights to use them. The contract must distinguish them from components created for the customer and specify whether the customer may continue to operate, modify and disclose them to a new administrator after the relationship ends.
What if the application contains open-source libraries?
Each library is governed by its own licence. Require a list of components, the versions used and their licences. Perform the same review for fonts, templates, maps, paid packages and external services.
How can we tell whether another team can actually take over the system?
Ask an independent developer to build a test environment using only the delivered repository, documentation and access credentials. At the same time, perform a backup restoration, a complete data export and a review of the contractual right to disclose the code to a new supplier.
Where to find us
ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.
Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).