Who Owns the Source Code When You Hire a Software Company in Turkey? What the Contract Must Say (2026)

If the contract does not say otherwise in writing, the developer owns the economic rights to the source code, not the client who paid for it. Turkish Law No. 5846 on Intellectual and Artistic Works, known as FSEK, treats computer programs as protected works, gives the economic rights to whoever wrote them, and lets a client acquire those rights only through a written contract that lists each right separately. Paying the invoice, receiving the files and even holding the server password do not change that. This guide covers the articles that decide ownership, the 2020 Court of Cassation ruling that shows what a silent contract actually gives you, and the clauses we recommend writing in before a single line of code is commissioned, as of October 2026.

Software is a protected work, and the source code is the work itself. Article 2(1) of Law No. 5846 lists computer programs 'expressed in any form' among works of science and literature, together with their preparatory designs where those lead to a program. Article 1/B defines a computer program as the set of instructions plus the preparatory work for developing it. The international baseline is identical: Article 10(1) of the WTO TRIPS Agreement protects computer programs, whether in source or object code, as literary works under the Berne Convention. One limit matters for founders: Article 2 also states that the ideas and principles underlying any element of a program, including its interfaces, are not works. Copyright will not let you own a business idea. It lets you own the code that expresses it.

The automatic employer rule only covers employees. Article 18 gives the exercise of economic rights exclusively to the author. Its second paragraph creates the exception: unless a special contract or the nature of the work indicates otherwise, the rights in works that civil servants, employees and workers create while doing their jobs are exercised by those who employ them, and the same applies to the organs of legal persons. That is why a company with in-house developers controls their code. The rule names employees. It does not name the freelancer, agency or software company you hire. Some commentators argue for a broader reading that reaches commissioned work, but the 2020 ruling below is reason enough not to bet on it. Turkish law also has no general 'work made for hire' doctrine for outside contractors, so foreign clients should not rely on that label in an English-language contract either. With an outside developer, ownership runs through a written assignment.

A silent contract gives you use, not ownership. In its decision of 16 January 2020 (E. 2019/11-474, K. 2020/26), the Court of Cassation General Assembly of Civil Chambers looked at a computer program that a company's purchasing manager had prepared at the company's request, with no payment and no transfer contract. The court treated it as a commissioned work and held that the company owned the program and could use it within the scope of the order, but that the economic and moral rights had not passed to the company and remained with the person who wrote it. Any use beyond what was agreed requires a separate written transfer. For a client, that means a silent contract lets you run the software for the purpose you ordered it. Modifying it with another team, selling it, licensing it to a group company or building a new product on top of it all become contestable. Article 57 points the same way: transferring ownership of the original or of copies does not transfer the intellectual property rights unless agreed. A zip file of source code is a copy, not a title deed.

Article 52 sets the form: in writing, right by right. Contracts and dispositions concerning economic rights must be in writing and must list the rights they cover separately. The rights to list are in Articles 21-25: adaptation (Article 21), reproduction (Article 22, which for software expressly includes loading, displaying, running, transmitting and storing the program), distribution (Article 23), performance (Article 24) and communication to the public, including making the work available online (Article 25). Article 20 adds that these rights are independent of each other, so disposing of one does not affect the others. A sentence such as 'all rights belong to the client' is therefore weaker than a clause that names all five. Two interpretation rules finish the picture. Under Article 55, a transfer does not extend to translations or other adaptations unless agreed, and for software, adaptation is how code gets maintained and extended, so it is the right you cannot afford to miss. Under Article 56, every licence is presumed simple (non-exclusive) unless the law or the contract says otherwise.

Timing: commit first, transfer as the code is created. Article 48 allows economic rights to be transferred limited or unlimited in time, territory and content, with or without payment, but its final paragraph declares void any disposition over a work that has not yet been created. Article 50 closes the gap: commitments to make such a transfer are valid even when given before the work exists. Because you sign before any code is written, the contract should be drafted as a commitment that the rights pass to you as each part is created or delivered, backed by a short written confirmation of the transfer at each milestone acceptance. Article 50 also lets either party terminate commitments that cover all future works, or a defined type of future works, with effect one year after notice. If you sign an open-ended development and maintenance retainer, know that this exit exists on both sides.

Moral rights stay with the developer, and part of them cannot be signed away. Articles 14-17 give the author control over making the work public, over attribution and over changes. Articles 14 and 16 state that a contractual waiver of the right to prohibit publication or changes that damage the author's honour or reputation, or distort the nature of the work, is void. For business software this rarely becomes a dispute, and Article 16 itself allows changes that the technique of adaptation or reproduction makes necessary. Still, the contract should record the developer's consent to modification, publication and use without attribution to the extent the law allows, so that routine maintenance by a different team never has to rely on implied permission.

Check the chain of title, not just your own contract. Article 49 says that someone who acquired an economic right from the author can transfer it onward only with the author's written consent. If your agency staffed the project with freelancers or subcontractors, their rights reach you only if their contracts with the agency allow that onward transfer. Article 54 is the uncomfortable part: whoever acquires a right from a party not authorised to transfer it is not protected, even in good faith. Article 53 makes the transferor answerable for the existence of the right it transfers. In practice, ask for a written warranty that every contributor, whether employee, freelancer or subcontractor, has assigned their rights to the vendor with consent to onward transfer, and an indemnity if that turns out to be false.

Full ownership stops at open source and at the vendor's own pre-existing code. A modern web or mobile product contains hundreds of open-source packages owned by other people, and you use them under their licences. The MIT licence permits use, copying, modification, merging, publishing, distribution, sublicensing and sale on condition that its copyright and permission notice stays in copies. The GNU GPL is different in kind: according to the GNU licensing FAQ you may modify GPL code and use it privately or inside your organisation without releasing anything, but if you distribute a modified version, the whole combined program must be released under the GPL with its source. The AGPL extends that duty to users who interact with the software over a network. An app shipped through the App Store or Google Play is distribution. Separately, most vendors reuse their own libraries and tooling across clients and cannot assign those to you. The fix for both is contractual: a dependency list with licences, no GPL or AGPL in shipped or network-served code without your written approval, and a perpetual, irrevocable, royalty-free, transferable licence to any pre-existing vendor components that remain inside your product.

The rights clauses to write in before kickoff. First, an assignment of the economic rights in Articles 21-25, each named, exclusive, unlimited in time, territory and content, expressly including adaptations and derivative versions, with the right to sublicense and transfer onward. Second, the Article 50 structure: a commitment now, with the transfer taking effect as each part is created or delivered and confirmed in writing at each milestone acceptance. Third, the chain-of-title warranty and indemnity from the previous section. Fourth, the open-source and third-party inventory with your approval required for copyleft licences. Fifth, the background licence for the vendor's pre-existing components. Sixth, the developer's consent to modification, publication and use without attribution as far as the law allows. Payment-conditional transfer is fair to the vendor and normal; what protects you is that the code already sits in your repository while it is being paid for.

The operational clauses matter as much as the legal ones. The Git repository should live in your organisation's account from day one, with full commit history, build scripts and infrastructure configuration, and with secrets kept out of the repository and documented separately. The domain, DNS, hosting or cloud account, App Store and Google Play developer accounts, analytics, payment provider and email sending account should be registered to your company, with the vendor given role-based access that you can revoke. Where the vendor keeps hosting the product or runs it on its own platform, add a source code escrow: the current source deposited with a neutral third party and released to you on defined triggers such as insolvency or the end of support. Close with a handover clause covering architecture documentation, deployment instructions, environment variable documentation, design files and a defined handover period with the team that built it.

Red flags in a vendor proposal, and how we work. Source code delivery that costs extra or is not mentioned at all. The words 'licence' or 'usage right' where you expected 'assignment'. Your app published under the vendor's developer account, or your domain registered in the vendor's name. A proprietary CMS or platform with no export path and no escrow. A monthly fee that bundles hosting with no clause on what happens when you leave. Silence on open source. 'All rights belong to the client' with no rights listed. Our own default answers the same checklist: the repository, domain, DNS, hosting and analytics are in the client's name from day one, and the handover package (the full Git repository, design files, written architecture documentation, deployment instructions and environment variable documentation) is part of the scope, not an upsell. This guide summarises the text of Law No. 5846 and published legal commentary as of October 2026. It is not legal advice; have a lawyer review your specific contract before you sign.