Who owns your software's source code? Contracts, rights transfer and escrow

Under Turkish law the source code of a piece of software belongs to whoever wrote it, unless the rights have been transferred in writing. Law No. 5846 on Intellectual and Artistic Works (FSEK) lists computer programs among literary and scientific works in Article 2, so code is protected by copyright from the moment it is written. If one of your own employees wrote it, Article 18 works in your favour: rights over works created by staff in the course of their duties are exercised by the employer, unless the employment contract or the nature of the work says otherwise. If an outside agency or a freelancer wrote it, the position flips. They are the author, even though you paid the invoice. Getting the rights requires a written assignment, and how that assignment is drafted matters as much as whether it exists.

A clause in the contract does not mean the code is in your hands

The pattern we run into most often looks like this. The contract says all intellectual property belongs to the client, so everyone relaxes. Then the repository turns out to live in the developer's personal GitHub account, the application runs on a cloud subscription opened in their name, the domain renews on their credit card, and the build script only works cleanly on their laptop. Legally you are right. Practically you have a running system and exactly one person who knows how to stand it back up. These are two separate problems and they need two separate fixes: contract language for one, handover and access discipline for the other.

What the law asks for in an assignment

Article 48 governs the transfer of economic rights. An author may assign them with or without limits on duration, territory and scope, for payment or free of charge. Article 49 closes the next link in the chain: anyone who has acquired a right or a licence and wants to pass it on to someone else needs the author's written consent. Agencies that use subcontractors often skip this step, and if one link in the chain is broken, the assignment at the end of it is not solid either.

Article 52 carries the most weight in practice. Contracts and dispositions concerning economic rights must be in writing, and the rights they cover must be listed separately. The second half of that sentence is the part that gets ignored. A sweeping line such as "all economic rights arising under FSEK are hereby transferred" is open to challenge precisely because it does not itemise anything. The rights need to be named: adaptation, reproduction, distribution, performance, and communication to the public. Moral rights (disclosure, attribution, the right to prevent modification of the work) cannot be assigned at all. You can only be authorised to exercise them, and that authorisation also has to be written.

What belongs in the contract

Every one of these deserves its own clause in a development agreement:

• The economic rights being assigned, named one by one, with an explicit statement that the assignment is unlimited in time and territory.
• Delivery of the source code together with its version history, and the events that trigger delivery (acceptance, payment, termination).
• The scope of adaptation rights, meaning your ability to hand the code to a different supplier and keep developing it.
• Evidence of written assignments obtained from any subcontractors or freelancers who worked on the project.
• The licence status of any of the developer's own reusable libraries included in the deliverable.
• The exit process when the contract ends: how many days of transition support, which documents, which accounts.

The handover list: code alone is not enough

Receiving source code is not the same as taking over a system. A real handover package includes a copy of the repository with its full history, build and deployment scripts, dependency files with pinned versions, the database schema and migration scripts, infrastructure definitions, a list of environment variables (the names and what they do, not the values), an inventory of third-party services and accounts, and a setup document that starts from zero.

There is one test worth running: on a clean machine, without asking the developer a single question, can you build it and run it? If the answer is no, the handover is not finished. Do not sign the acceptance document before that test passes.

Whose name is on the accounts

Domain, DNS, TLS certificates, cloud subscription, app store accounts, payment provider, email infrastructure, error tracking, analytics. Each of these should either sit under your own corporate account or have its transfer written into the contract. Sites that quietly go offline because the domain stayed on a former developer's personal account and nobody renewed it are a recurring story in this industry, not an edge case.

How credentials are stored is a related question. API keys committed into the repository are both a security problem and a handover problem, because nobody can tell which key is used where. We covered that in detail in our guide to secrets management.

Open source components and licence exposure

Most of what you receive as custom software is, in reality, assembled from open source libraries. Permissive licences such as MIT, BSD and Apache 2.0 rarely cause trouble in commercial use. GPL and especially AGPL behave differently. AGPL can trigger source disclosure obligations for derivative works even when users only reach the software over a network, which means a hosted product can fall within scope without you distributing anything at all.

Ask for a list of third-party components (a software bill of materials, or SBOM) and a licence compliance representation in the contract. That list is one of the first documents technical due diligence requests during an acquisition or funding round, and undisclosed copyleft dependencies have derailed deals before. For the broader risk that dependencies create, see our post on software supply chain security.

When source code escrow makes sense

Sometimes a vendor will not hand over source code, and that can be a reasonable position. If you are buying from a software company that sells the same product to many customers, the code is their commercial asset. This is where escrow comes in. The code is deposited with an independent third party and released to you only if one of the events named in the agreement occurs. The standard triggers are bankruptcy, insolvency, ceasing to trade, and failure to provide the maintenance and support promised in the contract.

Escrow usually fails for administrative reasons rather than technical ones. The vendor deposits once at signing, never refreshes it, and nobody ever verifies it. Years later the release trigger fires and the package turns out to hold a stale version, missing dependencies and no working build script. Two clauses prevent this: a deposit schedule tied to how often the product actually changes, and a verification right that spells out whether the deposit can be compiled and run, how many verifications you may request per year, and who pays for them.

For SaaS, escrow alone does not solve it

With a hosted service, getting the source code helps less than you would think, because what you actually need is your data and a place to run it. The clause to read here is the exit clause: when the service ends, in what format can you export your data (a processable export, not an opaque backup), how quickly, and how many times. Retention and deletion timelines belong in the same place, and they double as the technical annex of your data processor agreement. How responsibility splits depending on the hosting model is something we walked through in our post on the shared responsibility model.

Without source code, the law leaves you a narrow corridor

Article 38 gives someone who lawfully acquired a program a few rights: making the backup copy needed for the program to function (a right that cannot be restricted by contract), loading it, running it, and correcting errors. There is also a limited allowance to reproduce code in order to obtain the interface information required for interoperability with other programs. That exception is confined to interoperability, though. Using what you learn for another purpose, or passing it to third parties, counts as infringement. These provisions leave you some room to manoeuvre in a bad situation. They are not a substitute for a proper assignment.

A one-day exercise

While the relationship with your software supplier is still healthy, answer three questions. First: is there a signed document assigning the economic rights in this project, and are those rights itemised in it? Second: if I asked for a complete copy of the source code today, could I build and run it on a clean machine? Third: whose name is on the domain, the cloud account and the payment provider? If you cannot answer all three clearly, the problem is not your supplier's intentions. It is that nobody has asked yet. These are also worth putting on the table before you decide between off-the-shelf and custom software.