Who Owns the Website Once You've Paid For It?

"I paid for the website, so I own it." It sounds obvious, and it still does not quite describe what happened legally.

That is not cause for alarm. In practice, client and developer usually get along fine without perfect contracts. The question only becomes sharp at three moments: when you want to change providers, when you sell the business along with the site, and when things turn adversarial.

That is when it emerges that "the website" is not a single object at all, but a bundle of things with different legal characters.

This article covers German law, which applies when you commission a developer based in Germany or when your contract specifies it. If you are used to US or UK practice, the difference matters more than you might expect.

A caveat first: I am a developer, not a lawyer. What follows is a practitioner's view of a legal framework I had to understand for my own work. For a contract you actually rely on, have a solicitor who handles IT law look at it once.

Authorship cannot be bought

The starting point surprises almost everyone: under §29 of the German Copyright Act, copyright itself is not transferable. Whoever writes the text, designs the logo or programs the code remains its author, permanently, regardless of what was paid.

This is a deliberate departure from the Anglo-American model. Under US law, a commissioned work can qualify as work made for hire, with the commissioning party treated as the author from the outset. German law has no such construction. The author is always the natural person who created the work.

The practical consequence: a clause reading "copyright transfers to the client" simply has no effect under German law. If you see it in a proposal, it usually means the text was copied from somewhere it did not belong.

This trips up international clients regularly. You commission a site from a German developer, apply the assumption you brought from home — paid for equals owned — and only discover the mismatch when you try to do something the contract never covered.

What you actually acquire: rights of use

What can be transferred is not the copyright but the right to use the work, governed by §31. This is the real subject of every web development contract, and it is where what you may do with your website is decided.

The law distinguishes two forms, and the difference is substantial:

A simple right of use lets you use the work in the agreed way. The author may also grant the same right to others. For websites this means: you run your site, and the developer may use the same components — a form, a table component, the underlying structure — in other projects.

An exclusive right of use means only you may use the work in the agreed way. Not even the developer.

For an ordinary company website, a simple right of use is the normal and sensible arrangement. No developer builds every project from zero; everyone works from a foundation of reusable pieces built up over years. That is also in your interest — it is why a project takes weeks rather than months, and why it is priced accordingly.

An exclusive right makes sense when something genuinely singular is created that competitors should not also receive: a distinctive feature, a custom logo. But that is a different product at a different price, because the developer gives up reuse.

With no clause: the purpose-of-transfer rule

For exactly this situation there is §31(5), the Zweckübertragungsregel — the purpose-of-transfer rule.

It provides that if the types of use are not expressly listed individually, the scope of the rights granted follows from the purpose of the contract. In case of doubt, the author grants rights only to the extent the contractual purpose strictly requires.

German legal writing has a memorable image for this: rights of use tend to stick to the author. Every grant is construed as narrowly as possible.

For you as the client this means: with nothing written down, you get the right to operate your website — and, in case of doubt, nothing beyond that. Whether you may have it rebuilt by someone else, hand it over, or sell it with the business becomes a question of interpretation.

The misconception runs in the other direction too. Many contracts contain phrases like "all rights of use" or a "buy-out". It sounds comprehensive, and that is precisely why it does not help: because the individual types of use are not enumerated, the purpose-of-transfer rule applies anyway. A blanket formula does not substitute for a list.

Software gets special treatment: §§69d and 69e contain provisions that work in the client's favour, including the right to reproduce and adapt a program as far as necessary for its intended use.

A website is not one object

The second misconception is treating "the website" as a single thing. It is several components, each governed differently.

The source code. Protected as a computer program. Everything said above about rights of use applies here.

Design and layout. Protected where a certain threshold of originality is met. A standard arrangement of header, columns and footer usually is not; a distinctive visual identity is.

The text. If you wrote it, you are its author. If a copywriter wrote it, the same rules apply to them as to the developer.

Images and graphics. The most common point of failure. Stock photos are licensed, not bought, and the licence often runs in the name of whoever purchased it. If your developer licensed the images through their account, your right to use them may end when the engagement does. Ask before it matters.

Fonts. Also licensed, and web licences are frequently tied to domains or pageview volumes. That becomes relevant when you move to a new domain.

The domain. Legally a different category entirely. It is not a protected work but a contractual relationship with the registry. Whoever is registered as holder has the domain, regardless of who built the site. Why that is the single most important item is covered in a separate article.

Your data. Customer records, orders, contact form submissions. This is unambiguously yours, and you are entitled to receive it in a usable format. The obligations attached to holding it are covered in the article on Impressum and GDPR.

Source code: the question nobody asks

Between "the website is mine" and "I have the source code" lies a gap that usually goes unnoticed until it is too late.

A finished website sits on the server as a built result. The source code — the files it is built from — normally lives in a repository on the developer's side. So you can own the domain, run the site, and still have no source code.

Whether you need it depends on how you intend to work. Both models are legitimate, provided they are stated:

No code handover — the developer runs and maintains the site and you get a working product. For many clients that is the more practical arrangement, because they would do nothing with the code anyway.

With code handover — you receive the files at project completion or when the engagement ends. That gives you independence and makes switching possible at any point.

I handle this by agreement. Some clients want the code; others explicitly do not and are glad someone else is looking after it. Both are fine — what matters is that it is settled up front, not at the moment someone walks away.

What belongs in your proposal

You do not need ten pages. One paragraph answering four questions is enough:

Which right of use? Simple or exclusive, and for what precisely.

From when? The usual and sensible answer is: on full payment. Until then the rights stay with the developer, which is their only real security.

What about the source code? Handover at completion, at the end of the engagement, or not at all.

What may the developer reuse? General components and approaches — or nothing.

Here is how I word it, in German, since that is the governing language of my contracts:

Mit vollständiger Bezahlung erhält der Auftraggeber ein einfaches, zeitlich und räumlich unbeschränktes Nutzungsrecht an der erstellten Website. Der Auftragnehmer bleibt berechtigt, allgemeine Komponenten und Lösungsansätze in anderen Projekten zu verwenden. Die Übergabe des Quellcodes erfolgt nach gesonderter Vereinbarung.

In substance: on full payment the client receives a simple, unlimited right of use; the developer may reuse general components in other projects; source code handover is arranged separately.

If your provider has nothing like this in their proposal, that is not a red flag — most do not. Just ask. A good developer welcomes the question, because that paragraph protects them exactly as much as it protects you.

If you are commissioning from abroad

Two points worth settling explicitly when the developer and the client sit in different countries.

Which law applies. Do not assume. If the contract does not specify governing law and jurisdiction, you may find yourself arguing about that before you get to argue about anything else. One line resolves it.

Which language governs. If a contract exists in two language versions, say which one prevails in case of discrepancy. Translations drift, especially around legal terms that have no clean equivalent — Nutzungsrecht is not quite "licence" and not quite "right of use".

Frequently asked questions

I paid for everything. Doesn't the code become mine automatically? Not automatically. Copyright stays with the developer because German law does not permit its transfer. What you acquire are rights of use, and their scope follows the contract. With no clause, you receive in case of doubt only what the contractual purpose requires.

Can the developer use the same code for other clients? With a simple right of use, yes, and that is the normal case. Nobody builds from zero; everyone works with reusable components. Only an expressly agreed exclusive right prevents it, and it costs accordingly more.

Do I get the source code when the engagement ends? Only if it was agreed. The finished site on the server and the source code in a repository are two different things. Settle it in the proposal, not at the farewell.

My contract says "all rights of use". Is that enough? Probably not. Because the individual types of use are not listed, the purpose-of-transfer rule applies anyway and the grant is construed narrowly. An enumeration beats a blanket phrase.

What about the images on my site? Check whose name the licences are in. Stock photos are licensed rather than bought, and if the licence sits with the developer, your right may end with the engagement. The same applies to paid fonts.

And the domain? Different rules entirely. It is not a protected work but a contract with the registry. All that matters is who is registered as holder.

Is this different from US work for hire? Fundamentally. Under US law a commissioned work can vest authorship in the commissioning party from the start. German law does not allow that: the author is always the person who created the work, and only rights of use move.

In short

Paid for means you may use your website. Anything beyond that — rebuilding it elsewhere, transferring it, selling it with the business — is either in the contract or, in case of doubt, not included.

Authorship stays with the developer and cannot be moved. Everything else fits in four sentences.

What a project costs and what drives that is broken down separately.