# Who owns your code, domain and data?

> A domain in the developer’s name, code without a transfer of rights, accounts you can’t access. The usual traps and how to avoid them from the contract on.

Simplix · contracts, security, web-apps

Most ownership problems only surface when you want to change something: a new developer, a new host, a collaboration that has ended. Only then do you find out that the domain is in someone else’s name, that you don’t have the source code or that your App Store app is published from the former supplier’s account.

All of this can be avoided with a few questions asked at the start. Here is what should be yours and how to make sure it is.

## What should be yours

| What | Whose name it should be in | What happens if it isn’t |
| --- | --- | --- |
| **The domain** | your company’s | you can’t move it; if it expires, someone else can take it |
| **Hosting, the server** | yours, or with guaranteed access for you | you depend on a single supplier for everything |
| **The source code** | handed over to you, with the rights set out in the contract | any change of supplier means a rebuild |
| **The data** | yours, exportable at any time | customers, orders and history can stay locked in |
| **Service accounts** | your company’s | payments, email, maps or SMS can stop overnight |
| **Analytics and Search Console** | your company’s | you lose visit history and access to the data |
| **App Store and Google Play accounts** | your company’s, ideally | moving the app needs the former supplier’s cooperation |

## The domain: the first thing to check

A domain’s holder is the person or company registered as its owner, not whoever pays the invoice or bought it “for you”. If the domain is in the developer’s name, legally it’s theirs.

Check whose name it’s registered in, with which registrar and who has access to the management account. If it isn’t in your company’s name, ask for the transfer while the relationship is good. Later, it may become a negotiation.

## The code: who holds the rights

Source code is protected by copyright; in Romania, the rules are in Law no. 8/1996. The law provides that, unless there is a clause to the contrary, the economic rights in programs written by **employees** in the course of their duties belong to the employer[^1].

When you work with a **company or a freelancer**, things are different: they aren’t your employees. Which rights you get depends on what the contract says. That’s why the contract has to state clearly:

- whether you get an **assignment of the economic rights** in the code (it becomes yours) or a **license to use it** (you can use it, but it isn’t yours);
- whether the assignment or license is **exclusive**, for how long and in which territory;
- that you receive the **source code**, not just the installed app;
- which **third-party components** it contains: plugins, themes, open-source libraries. These remain their authors’; you only get the right to use them, under their licenses.

> **Reused components**
>
> Many development companies use their own components, reused across projects. It’s normal and it helps you: work goes faster, and the components are tested. For these you usually get a license to use them, not ownership. What matters is that this is written clearly in the contract.

We aren’t lawyers, and every situation has its specifics. For important projects, it’s worth having a lawyer specialized in intellectual property read the clauses.

## Accounts: small, but critical

Besides the server, a website or app uses many services: the payment processor, transactional email, maps, SMS, invoicing, analytics, Search Console. Each has an account and usually access keys.

Ideally, they are all created in your company’s name, and the developer gets access as a user. If the developer created them, ask for the list and the transfer.

For mobile apps, the **developer account** the app is published from matters too. An app can later be moved to another account, but the transfer has to be started by the holder of the old account and accepted by the new one[^2]. Without the former supplier’s cooperation, it can’t be done.

## The data: you are responsible for it

Your customers’ data is your responsibility. Under the GDPR, you are the **controller**, and the developer or the company hosting the app is the **processor**, handling the data on your behalf. The relationship must be set out in a contract stating what they may do with the data[^3].

Also make sure you can **export the data at any time**, in a format someone else can use, and that you know where the backups are.

## What to check in the contract

1. **Rights in the code:** assignment or license, exclusive or not, with the source code handed over.
2. **Third-party and reused components:** what they are and on what terms you use them.
3. **The domain and accounts:** in your company’s name.
4. **The data:** the data processing agreement and the right to export it at any time.
5. **Documentation:** installation, configuration, accounts and keys, handed over with the project.
6. **Ending the collaboration:** what you receive and how quickly, if you choose another supplier.

A good collaboration isn’t built on the client being unable to leave. It’s built on the client not wanting to.

[Talk to us about your project](https://www.simplix.ro/en/contact/)

[^1]: [Law no. 8/1996 on copyright and related rights](https://legislatie.just.ro/Public/DetaliiDocument/7816) (in Romanian), Article 75.
[^2]: Apple, [Overview of app transfer](https://developer.apple.com/help/app-store-connect/transfer-an-app/overview-of-app-transfer).
[^3]: [Regulation (EU) 2016/679 (GDPR)](https://eur-lex.europa.eu/eli/reg/2016/679/oj), Article 28.