Who owns the source code when you commission software?
Unless the contract transfers it to you in writing, source code ownership generally stays with whoever wrote the software. Paying for a project and receiving a working program does not by itself move the economic rights in the code to you, and many businesses only learn this during their first dispute.
In Türkiye, computer programs are protected as literary and scientific works under Law No. 5846 on Intellectual and Artistic Works (FSEK). The law says the author of a work is the person who created it (Article 8). The author's rights fall into two groups: moral rights stay with the author, while economic rights, such as reproduction, distribution and adaptation, can be transferred. So to say "the software is ours", you need to separate two things: the right to use the program, and ownership of the economic rights in the code.
The law sets a formal requirement for transfers. Under Article 52, contracts and dispositions concerning economic rights must be in writing, and the rights they cover must be listed individually. A one-line clause such as "all rights in the software belong to the customer" can therefore cause arguments. It is safer to state which rights pass, for how long, where and to what extent; Article 48 says economic rights may be transferred with or without limits as to duration, territory and content.
In practice, contracts follow one of two routes. The first is a full transfer: the economic rights pass to you and the supplier cannot give the same code to another customer. The second is a licence: the code stays with the supplier and you receive a broad right of use without a time limit. A licence is often cheaper, but it can restrict how far you may modify the code, sell it or hand it to another team. Write down which route you chose; an unclear phrase that is neither a full transfer nor a licence is the most expensive option.
This article gives a general framework. Whether a particular right has been transferred under your contract depends on the wording used and the facts, and should be assessed on that basis.
How does ownership change depending on who wrote the code?
The table below summarises five common situations. Each row assumes the contract says nothing different.
| Who wrote the code? | General position | What the contract needs |
|---|---|---|
| Your own employee | Employer exercises the rights (Art. 18) | IP clause in employment contract |
| Software company | Rights stay with the company absent a transfer | Written transfer listing the rights |
| Freelancer | The freelancer is the author | Assignment, tied to payment |
| Open-source component | The licence sets the terms | Component list and licences |
| Subcontractor | The company's transfer may not be enough | Assignment papers along the chain |
For the employee row, FSEK Article 18 says that, unless the parties' own agreement or the nature of the work indicates otherwise, the rights in works that civil servants, staff and employees create while doing their jobs are exercised by the person who employs or appoints them. Because of that "unless" wording, it is still useful to put an express clause in the employment contract.
Which clauses should a contract include to settle ownership?
A handful of concrete clauses answer the ownership question. Compare the list below with your draft contract.
- List the rights transferred: write out reproduction, adaptation, distribution and use one by one, because FSEK Article 52 requires the rights to be shown individually.
- Duration, territory and scope: a clear phrase such as "unlimited in time, worldwide, for any use" reduces ambiguity.
- When the transfer takes effect: state the moment, for example when the final payment is made or acceptance is complete. A supplier may be unwilling to transfer before it is paid.
- Source code delivery: say that you will receive the source code, build instructions, the dependency list and the database schema, not only the compiled application.
- The supplier's existing components: if the company uses its own libraries or code from earlier projects, state the type of right you receive in them, whether a transfer or a usage licence.
- Open-source and third-party components: attach a list of components and their licences to the contract.
- Subcontractor chain: the supplier should warrant that everyone who worked on the project has assigned their rights to it.
Do you really hold the code? Delivery and access control
Even if the rights are yours on paper, they are worth little in practice if you cannot reach the code. Check these points at delivery:
- Repository ownership: have the code repository (on GitHub or GitLab, for example) created in your own organisation account and give the supplier write access. A repository kept in the supplier's account can be cut off in a dispute.
- Accounts and keys: the domain name, cloud subscription, app-store developer account, API keys and certificates should be opened in your name.
- Documentation: installation, environment variables and deployment steps should be written down. At handover, test whether another team could get the software running.
- Source code escrow: if the supplier will keep the code, the contract can require it to be held by a third party and released to you in defined cases, such as insolvency or withdrawal of the service. How this works depends on the contract and the escrow agent's terms.
How should you accept the source code at delivery?
Receiving source code is more than getting a file by email. Define acceptance as a step in the contract and tie the final payment to it. This order works in practice:
- Import the delivered code, with its full commit history, into the repository in your own account.
- On a clean machine, build and run the software using only the documentation.
- Compare the component and licence list with the code, and look for libraries that are not on the list.
- Confirm that accounts, domain names and keys have been handed over, and close the supplier's old access.
- Sign the transfer document and make the final payment.
You can ask your internal team or an independent developer to run this test. If nobody can run the code, delivery is not complete in practice, even if ownership is written down.
How do open-source components affect ownership?
Most modern software is largely built from open-source components. The supplier does not own these; each component's licence sets the terms of use. The Open Source Definition lists criteria a licence must meet to count as open source, including access to source code, free redistribution and permission for derived works. Licences that meet these criteria still differ in their conditions, and some may require code combined with theirs to be released on the same terms.
So ask for a list at delivery showing which component is used under which licence. The SPDX licence list gives standard identifiers that everyone can use. Having the list from the start prepares you for the review questions that come when you later sell the software, raise investment or bid for a public contract.
For example: what happens when a TRY 400,000 project has no proper transfer?
For example, a logistics company agrees a fleet-tracking application with a software firm and pays in stages. The contract says only "the delivered software belongs to the customer". The figures are hypothetical. Two years later the company wants to continue development with a different team.
It runs into three problems. First, because the contract does not list which rights are transferred, the scope of the transfer is open to dispute (FSEK Article 52). Second, the code sits only in the supplier's repository, and the company holds a compiled build. Third, part of the application relies on a shared library the supplier also uses for other customers, and the contract gives no separate licence for it.
Had the contract included a transfer clause listing the rights, repository access, a component list and an unlimited usage licence for the shared library, the company could have started with the new team in the first week. Writing these clauses takes a few hours at contract stage. Fixing the gaps afterwards can turn into months of negotiation.
What are the most common mistakes?
- Writing only "the software belongs to the customer" without listing the rights one by one.
- Leaving the code repository in the supplier's account and taking delivery of just the compiled application.
- Registering the domain name, store account and cloud subscription in the supplier's name.
- Saying nothing in the contract about the supplier's own libraries and open-source components.
- Working with a freelancer or subcontractor without documenting their assignment to the supplier.
- Not tying the transfer to the final payment, or forgetting to have the transfer document signed after it.
How Hatson Tech helps
The first meeting and discovery with Hatson Tech are free. On custom software development projects we can settle repository, account and delivery questions together during discovery. Hatson does not publish fixed prices; we agree the scope in discovery. For drafting the transfer clauses, we recommend working with your legal adviser; for legal teams, Hatson's Caseon product can also be used for due diligence and contract review.
For supplier evaluation, see our guide to choosing an AI supplier, and for the decision between building and buying, read buy or build AI.