Basics
Who owns the source code of custom software? Rights in Switzerland and Liechtenstein
By Dominik Natter · Last updated on 3 November 2026 · 9 min read
In short
Unless the contract clearly says so, the source code does not automatically belong to the client. In Switzerland and Liechtenstein, copyright arises with the developer. Where developers are employed, the exploitation rights lie with the employer, which is usually the software vendor, and you often only receive a right of use limited to the purpose of the contract. That is why you should set out the transfer of rights, source code delivery and repository access explicitly in the contract.
Who owns the source code under Swiss copyright law?
At first, the source code belongs not to you but to the developer or their employer. The Swiss Copyright Act protects computer programs as works, as stated in Art. 2(3) URG. Protection arises when the software is written. No application or registration is needed.
Under Art. 6 URG, the author is the natural person who created the work. A company therefore cannot be an author itself. If the developer is employed by the software vendor, Art. 17 URG applies: where a program is created in the course of employment duties, the employer alone is entitled to exercise the exclusive rights of use. In your project, that is the vendor, not you.
Commissioning and paying for the software does not automatically make you the rights holder. Whether the contract counts as a contract for work under Art. 363 of the Swiss Code of Obligations or as a mandate under Art. 394 makes little difference here. What matters is what was agreed about the rights.
If there is no clear rule, the contract has to be interpreted. The question then is which rights the purpose of the contract requires. Lawyers call this the purpose-of-transfer principle. In case of doubt, the contract is read narrowly. That is usually enough for your own use, but not reliably enough for further development by another team.
In Switzerland, protection for computer programs expires 50 years after the author's death, under Art. 29(2)(a) URG. The question of who owns the rights therefore stays with your software for its entire life.
- Protection in Switzerland after the author's death, Art. 29 URG
- 50 years
- Protection in Liechtenstein after the author's death, Art. 32 URG
- 70 years
- belong in every contract for custom software
- 9 points
What applies in Liechtenstein?
Liechtenstein reaches the same result but spells out more in the statute. The relevant law is the Liechtenstein Copyright Act, LGBl. 1999 No. 160.
Here too, computer programs count as works under Art. 2(3) URG. The author is the natural person who created the work, Art. 6 URG.
For employees, Art. 19(1) URG applies. If an employee creates a work in the course of their duties, the rights pass to the employer unless otherwise agreed. This rule covers all works, not just software.
The key provision for clients is Art. 19(2) URG. In other contractual relationships, the scope of the rights transferred is determined by the purpose of the contract unless otherwise agreed. What is a rule of interpretation in Switzerland is written into the statute in Liechtenstein.
In Liechtenstein, protection lasts 70 years after the author's death, Art. 32 URG. If a Swiss company works with a Liechtenstein vendor or the other way round, specify the governing law and place of jurisdiction in the contract.
Right of use or transfer of rights: what is the difference?
A right of use lets you use the software. A transfer of rights makes you the rights holder. You will notice the difference at the latest when you want to change vendors.
With a simple right of use, you may run the software. Anything beyond that depends on whether rights have been transferred to you.
Right of use and transfer compared
Simple right of use
- Whether you may modify the software, have another team develop it further or pass it on to a subsidiary depends on the wording.
- In some cases the vendor may even sell the same code to other clients.
Transfer of rights
- You decide on changes, distribution and further development yourself.
- Copyright is transferable under Art. 16(1) of the Swiss URG and Art. 18(1) of the Liechtenstein URG.
- The right to be recognised as the author stays with the developer. For running your software, this hardly matters.
Which option you need depends on how you use the software:
- A right of use is enough for standard software, cloud services and minor customisations you will not develop further yourself.
- A transfer, or an exclusive and comprehensive right of use, makes sense for software that supports your core process and that you plan to run and extend for years.
Software contract checklist: what it should cover
These nine points belong in every contract for custom software. Review the quote, the contract and the general terms together, because the rights clause is often hidden in the general terms.
- Transfer of rights: which rights pass to you, from when, and whether they are exclusive. This should include the right to modify the software and have third parties develop it further.
- Source code delivery: complete, buildable source code including build scripts, configuration and database schema, not just individual program files.
- Repository access: the code is kept continuously in a repository you can access, ideally in an account owned by your company.
- Documentation: architecture description, operations manual and installation and deployment instructions, as part of acceptance.
- Credentials and infrastructure: domain, hosting, cloud accounts and licences are registered to your company. Administrator access is deposited with you.
- Third-party components and open source licences: a list of all libraries with their licences and an assurance that no licence restricts your intended use.
- Vendor building blocks: for reused modules, you need a perpetual, irrevocable and transferable right of use that also permits modifications.
- Employees and subcontractors: the vendor warrants that it has acquired the rights of everyone involved, including freelancers.
- Exit arrangements: handover at the end of the contract, transition support at fixed rates, data export in an open format and clear deadlines. Read more in our guide "Software maintenance costs: what do maintenance and operations cost per year?".
Software contract clauses: what to watch for
| Clause | What to agree | Note |
|---|---|---|
| Transfer of rights | Rights of use including modification and further development | Set the timing, for example on full payment |
| Source code delivery | Complete and buildable, with build scripts | Ongoing, not only at the end of the contract |
| Repository access | Access for your company, ideally in your own account | Including the full change history |
| Documentation | Architecture description and operations manual | Agree it as part of acceptance |
| Credentials and infrastructure | Domain, hosting and cloud accounts in your company's name | Administrator access deposited with you |
| Open source and third-party components | List of all components with their licences | Disclose copyleft such as GPL or AGPL up front |
| Vendor building blocks | Perpetual, irrevocable and transferable right of use | Including the right to have third parties modify them |
| Employees and subcontractors | Warranty that all rights have been acquired | Especially relevant for freelancers |
| Exit arrangements | Handover and transition support | Agree deadlines and rates in advance |
| Governing law | Specify governing law and jurisdiction | Important for contracts between Switzerland and Liechtenstein |
At Natter Solutions, you have access to the repository from the start. The rights of use to the source code pass to you once the project is paid in full. The repository, architecture description, operations manual and access credentials are in your hands, so that another team can take over. Ask every vendor to confirm this in writing.
Open source licences and vendor building blocks: what to watch for
Almost every modern application contains open source components. That is normal and usually unproblematic. But you should know which licences are involved. For many software products on the EU market, the Cyber Resilience Act requires a list of these components from December 2027, known as a software bill of materials or SBOM. Read more in our guide "Cyber Resilience Act: what applies to software from SMEs in Switzerland and Liechtenstein?".
Permissive licences such as MIT, BSD or Apache 2.0 largely allow free use in your own software. Their main requirement is that licence and copyright notices are retained.
Copyleft licences such as the GPL require that derivative software is passed on under the same licence and with its source code when it is distributed. The AGPL goes further. Anyone offering a modified version over a network must make the source code available to its users. That can matter for a customer portal.
For internal tools that are not distributed, this is rarely an issue. It becomes sensitive when you sell the software, ship it to customers or run it publicly. Clarify this before the project starts.
Many vendors use their own building blocks, for example for sign-in, permissions or interfaces. This saves you development costs. A vendor will rarely transfer such a component to you exclusively, since it also uses it for other clients. Ask for a perpetual, irrevocable and transferable right of use that permits modifications and operation by third parties.
Software escrow: when is depositing the source code worth it?
With software escrow, the vendor deposits the source code with a neutral agent. You only receive it in agreed cases, for example if the vendor goes bankrupt or stops maintaining the software.
Escrow is worth it if you would not otherwise receive the source code and the software is critical to your business. Typical cases are industry solutions or customised standard software where the vendor does not release the code.
What you do not need: if you already hold the source code and the rights and have ongoing access to the repository, escrow is redundant. You would be paying for a copy you already have.
Escrow without verification is of little value. Outdated or incomplete code will not help in an emergency. Look out for these points:
- The deposit is updated with every release, not just once when the contract is signed.
- The escrow agent checks that the deposited code is complete and that the software can be built from it.
- The release conditions are clearly defined, as is your right of use after release.
- Documentation and build instructions are part of the deposit.
Vendor lock-in: warning signs to take seriously
Dependence on a vendor rarely comes from bad intentions. Usually a rule is simply missing. If any of these points apply, negotiate before you sign:
- The contract only mentions a licence or a right of use, without scope, duration or the right to develop the software further.
- The vendor will only release the source code for an extra fee, only at the end of the contract, or not at all.
- The domain, hosting or cloud account is registered in the vendor's name.
- The software is built on the vendor's own framework that no other team knows.
- Documentation is missing or keeps being postponed.
- The vendor cannot tell you which open source licences the software contains.
- Termination and handover are not covered, or transition support has no agreed price.
Existing software with no agreement: what can you do?
If your contract says nothing about rights, there is no need to panic. As long as the working relationship is good, this can usually be settled after the fact.
You do have some rights even without a contract clause. Anyone entitled to use a program may make a backup copy, under Art. 24(2) of the Swiss URG and Art. 26(2) of the Liechtenstein URG. To connect other programs, Art. 21 of the Swiss URG allows interface information to be obtained by decompiling the code, under narrow conditions. In Liechtenstein, Art. 24 URG covers this. Neither gives you a right to develop the software further.
Proceed in this order:
01
Gather documents
Quote, contract, general terms, invoices and emails that mention rights or source code.
02
Take inventory
Where does the software run, and who owns the domain, servers, cloud accounts and database?
03
Secure your data
Request a complete export of your business data in an open format.
04
Agree after the fact
Ask the vendor to confirm the transfer of rights and source code delivery in writing, against compensation if necessary.
05
Get an independent review
Another team assesses the code, documentation and operations before you switch. Natter Solutions does this in a few days for a fixed price.
06
Bring in a lawyer
If the vendor refuses or a lot is at stake.
Where this information comes from
Swiss law
The Swiss legal basis is the Federal Act on Copyright and Related Rights, SR 231.1, as of 1 July 2025, published on Fedlex, in particular Art. 2, 6, 16, 17, 21, 24 and 29 URG. The contract types come from the Swiss Code of Obligations, SR 220, Art. 363 and 394.
Liechtenstein law
For Liechtenstein, the relevant law is the Act on Copyright and Related Rights, LGBl. 1999 No. 160, version of 1 July 2026, published on gesetze.li, in particular Art. 2, 6, 18, 19, 24, 26 and 32 URG.
Open source licences
The information on the AGPL comes from the licence text of the GNU Affero General Public License version 3 published by the Free Software Foundation, section 13.
As of: November 2026.
| Transfer of rights | Rights of use including modification and further development | Set the timing, for example on full payment |
|---|---|---|
| Source code delivery | Complete and buildable, with build scripts | Ongoing, not only at the end of the contract |
| Repository access | Access for your company, ideally in your own account | Including the full change history |
| Documentation | Architecture description and operations manual | Agree it as part of acceptance |
| Credentials and infrastructure | Domain, hosting and cloud accounts in your company's name | Administrator access deposited with you |
| Open source and third-party components | List of all components with their licences | Disclose copyleft such as GPL or AGPL up front |
| Vendor building blocks | Perpetual, irrevocable and transferable right of use | Including the right to have third parties modify them |
| Employees and subcontractors | Warranty that all rights have been acquired | Especially relevant for freelancers |
| Exit arrangements | Handover and transition support | Agree deadlines and rates in advance |
| Governing law | Specify governing law and jurisdiction | Important for contracts between Switzerland and Liechtenstein |
Frequently asked questions
Does the software vendor have to hand over the source code?
Only if this was agreed or clearly follows from the contract. Neither the Swiss nor the Liechtenstein Copyright Act gives the client a general right to the source code. Set out source code delivery and repository access explicitly in the contract, ideally on an ongoing basis rather than only when the contract ends.
Who owns the rights when a freelancer develops the software?
Initially, the freelancer. The employer rule in Art. 17 of the Swiss Copyright Act only applies to employment relationships. Without a written assignment, you will in case of doubt only receive the rights the purpose of the contract requires. If your vendor works with freelancers, have it confirm in writing that it has acquired their rights.
What is software escrow and do we need it?
With software escrow, the vendor deposits the source code with a neutral agent, which releases it in agreed cases such as the vendor's bankruptcy. It is worth it for business-critical software whose code you would not otherwise receive. If you already hold the source code and the rights and have access to the repository, you do not need escrow.
Who holds the rights to the code and the data?
The data is yours. The source code is kept in a repository you have access to, and the usage rights to it pass to you once the work is paid in full. We rely on widely used technologies such as Next.js, C# and PostgreSQL, so that another team can take the software forward if needed.
How dependent do we become on Natter Solutions?
As little as possible, and we make sure of that from day one. Every project is documented and handed over so that it can be operated and developed without us: the repository, architecture description, operations manual and access credentials are in your hands.
Matching services:Custom software
Matching solutions
«Our business depends on an Excel or FileMaker solution that only one person still understands.»
Replacing Excel and FileMaker
CHF 40'000 to 150'000
3 to 8 months
«Our customers call about every order status, and we look up the answer in the ERP.»
Customer portal with ERP integration
CHF 25'000 to 80'000
10 to 24 weeks
Let us talk about your case.
20 minutes are enough to find out whether a custom solution is worth it for you.