Who owns the code? Usage rights and handover in the contract

What copyright actually protects in software

In Germany, computer programs aren't governed by a separate law but by Sections 69a to 69g of the German Copyright Act (UrhG), a special set of rules within general copyright law. Under Section 69a UrhG, protection covers the program in every form, including the design material, meaning source code as well as object code and preliminary work such as functional specifications containing program logic. The underlying ideas and principles aren't protected, including those behind an interface. Protection requires that the program be the author's own intellectual creation, and the law explicitly sets no qualitative or aesthetic standard. Protection arises automatically upon creation; unlike a patent, there's no registration.

In practice, that means a project's actual code is protected, while rewriting comparable functionality with your own code is generally permitted. Commissioning custom software doesn't buy a patent on an idea, then, but rights to a specific work, whether that's a corporate website built through web development or a complex platform.

Who holds the rights: the agency, its employees, and the client

The most important question for clients is who actually holds the rights once a project is finished. German copyright law follows the creator principle (Schöpferprinzip): the rights holder is initially whoever actually created the work, meaning the individual developer. An important exception is set out in Section 69b UrhG: when a computer program is created by an employee carrying out their duties or following their employer's instructions, all economic rights to the program belong to the employer unless otherwise agreed. This rule applies equally to other employment-like relationships.

This exception covers the relationship between an agency and its own employees, but it doesn't help the client directly. When a company hires an external agency, that doesn't automatically transfer rights to the client. The agency becomes the rights holder through its employees and must first grant those rights to the client contractually. Without such a clause, the agency retains the legal upper hand, even if the project has been paid for in full.

Usage rights, not ownership: the scope is set in the contract

What the client actually receives is, as a rule, not ownership in the property-law sense but a usage right under Section 31 UrhG. The rights holder can grant a non-exclusive usage right, which permits use without excluding others, or an exclusive usage right, which gives the holder a monopoly position and generally allows sublicensing too. If the contract doesn't specifically list the types of use, the purpose-transfer rule (Zweckübertragungsregel) under Section 31(5) UrhG applies: the scope of the granted rights is then determined by the purpose both parties had in mind for the contract.

In practice, that means blanket wording like "the client receives all rights to the software" holds up poorly. In a dispute, a court would ask what the software was recognizably intended for and interpret the rights narrowly on that basis. Whether further development by another agency, resale, or use in a different part of the business is permitted should therefore be spelled out in the contract, based on the forms of use named in Section 69c UrhG, such as reproduction, adaptation, and distribution. One more provision matters here: under Section 69d UrhG, error correction is permitted even without express permission unless the contract states otherwise, while the right to make a backup copy can't be excluded by contract at all.

Contract for work or service contract: why the contract type matters

Whether a project runs as a contract for work (Werkvertrag) or a service contract (Dienstvertrag) affects liability, as well as when and how usage rights typically transfer. Under Section 631 BGB of the German Civil Code (BGB), a contract for work obliges the contractor to produce the promised work, meaning a specific result, while the client owes the agreed fee. A service contract under Section 611 BGB, by contrast, only obliges the provider to perform the promised services, without owing a specific outcome.

Most software projects with a clearly defined deliverable, such as building a specific application from a requirements specification, are contracts for work with formal acceptance and statutory warranty rights. Consulting or staffing arrangements, where the agency works based on time spent and instructions, resemble a service contract more closely. Many real-world contracts mix both, for example, treating concept work as a service and the subsequent build as a contract for work. What matters most for usage rights is whether they're granted upon acceptance, at individual milestones, or only once payment is made in full. The contract should state this link explicitly, or disputes tend to surface at the worst possible moment.

Open-source components in the delivered code

Almost no custom project today gets by without open-source components, from frameworks down to individual libraries. These components carry their own license terms, which apply independently of the contract between client and agency, because nobody can transfer more rights than they hold themselves. Permissive licenses such as MIT or Apache are usually unproblematic in practice, while copyleft licenses such as the GPL, and especially the AGPL, can trigger obligations, for instance requiring source code to be disclosed to users of the software. For an application run as SaaS, that can conflict with the goal of a closed, proprietary product.

Ask for an overview of the components in use along with their licenses, often called a software bill of materials (SBOM), and have any copyleft licenses with a network clause explained before they go into use. This check doesn't replace legal advice, but it heads off the most common bad surprises after launch.

Source code, documentation, and access: put it in the contract

Without an explicit clause, the client often only receives the running software or access to a hosted system, not the source code itself. For any project that isn't meant to stay with the same agency indefinitely, the contract should cover handover of the complete source code, including version history, build and deployment scripts, and technical documentation, as well as when that handover happens, for example upon acceptance or after each milestone payment. Without this clause, you depend on the same agency for even the smallest change, even if its proposal was originally calculated as a fixed-price project. If you're looking for an agency that clearly commits to code ownership and handover, you can ask exactly that in a project request and compare the answers.

Source code escrow as extra protection

For business-critical systems, a contractual promise to hand over the code isn't enough for some companies, for instance if the agency could become insolvent or contact breaks off. There's no statutory framework for source code escrow (Software-Hinterlegung) in Germany; it's purely a contractual arrangement. Under it, the agency deposits a current copy of the source code with a neutral third party, who only releases it to the client on predefined trigger events, such as insolvency or a sustained breach of agreed obligations. The effort pays off mainly for systems the business depends on directly, less so for smaller websites or marketing tools.

Checklist: contract clauses on usage rights and code

Before signing, it's worth checking the contract against the following points:

1. Does the contract explicitly state whether the usage right granted is non-exclusive or exclusive?
2. Are the permitted forms of use specifically named, such as reproduction, adaptation, and further distribution, rather than a blanket reference to "all rights"?
3. Is the usage right unlimited in time, or tied to a condition such as ongoing payments?
4. Is it clear at what point the source code, documentation, and build scripts will be handed over?
5. Are the open-source components in use and their licenses listed in the contract or an attachment?
6. Does the contract address what happens to the code and usage rights if the contract ends early or the agency becomes insolvent?
7. Has source code escrow been considered for business-critical systems?
8. Is it stated clearly whether the transfer of rights is tied to acceptance or to payment in full?

Clarifying these points before signing, whether for a new build or when switching agencies, saves you from negotiating later from a weak position. For how to assess an agency based on case studies and credentials generally, see How to vet an agency; the search also lets you filter providers by contract model. This article explains the legal basics in plain terms; it doesn't replace legal advice for individual cases.