Software Development Contracts and Source Code: Who Owns the Code and What the Contract Must Say

In a software development contract, the source code normally stays with the company that wrote it unless the contract expressly transfers it in writing; payment usually buys only the right to use the software. The contract should therefore state who owns the code, when and how it is delivered, which rights are assigned and what happens if the developer disappears.

This guide explains why each point matters and how to word it.

What usually gets missed at signing

Negotiations on custom software tend to centre on three things: price, delivery date and the feature list. Source code is either not discussed at all or covered by a single vague sentence. The problem rarely shows up at go-live. It shows up years later, when:

• the developer closes down, is acquired, or the people who built the system leave;
• you want another firm to make a small change, and without the code they tell you it has to be rebuilt (the options for systems in this state are in legacy software modernisation);
• an integration, e-invoicing requirement or regulatory change forces an update, and your only option is the original vendor, who now holds all the negotiating power;
• you sell the business or raise investment, and the buyer asks who owns the intellectual property behind the system your operations run on — and there is no paperwork.

All of these have the same root cause: the right to use the software was confused with owning it.

What happens if you do not hold the source code?

Source code is the human-readable, editable form of a program. The compiled files running on a server, or a login to a web application, only let you use the software. They do not let you extend it, have another team fix a defect, or move it to a different host. A business without the source code depends on a single supplier for the future of that system.

For most companies operating in Türkiye this is a real exposure, because there is rarely anyone in-house who could take the system over:

According to TurkStat, only 15.2% of Turkish enterprises employed ICT specialists in 2026, falling to 10.8% among firms with 10–49 employees; 31.7% of those trying to recruit ICT specialists reported difficulties. (TurkStat ICT Usage Survey in Enterprises 2026)

In other words, "we will carry it on internally if needed" is not a realistic fallback for most SMEs. The only safeguard is a handover package another team can actually pick up.

The second risk is confidentiality. Source code is not just an ownership question; it embeds your business rules, pricing logic and integration credentials. In the Verizon 2026 Data Breach Investigations Report, source code was the most common type of data submitted to unauthorised generative AI tools. A good contract also sets out which tools the contractor may use to process your code and with whom it may not be shared. We cover the wider risk in ChatGPT and company data security.

The third risk is the project itself. BCG's 2020 research found that 70% of digital transformations fall short of their objectives. If a project stalls, whether you own the code and documentation written so far decides whether you can continue with another team. To keep a project from stalling in the first place, see supervising software contractors.

Who owns the source code under a software development contract? (Turkish law)

In Türkiye, computer programs are protected as literary and scientific works under Law No. 5846 on Intellectual and Artistic Works (known by its Turkish acronym, FSEK). Three principles matter in practice:

1. The author is whoever creates the work. If your own employee writes the software under their employment contract, the economic rights generally pass to the employer. That does not happen automatically when you commission an independent software house or a freelancer.
2. Assignment of economic rights must be in writing and itemised. The contract should list separately which rights are transferred — reproduction, adaptation (modification), distribution and so on. A blanket "all rights are transferred" clause can invite dispute.
3. Assignment and licence are different. With an assignment the right passes to you; with a licence the developer remains the owner and grants you a defined permission to use it, which may be exclusive or non-exclusive.

This is not legal advice, and the final wording should always be reviewed by a lawyer. But the technical side needs to understand these principles so that the right questions reach the lawyer. Foreign companies operating in Türkiye should also check whether a group-wide template drafted under another jurisdiction actually satisfies the written, itemised assignment requirement.

Assignment, licence or escrow: which model fits?

Not every project needs a full transfer of the code. The right model depends on how critical the software is and whether the developer is building something bespoke or customising its own product.

For the broader build-or-buy decision, see our guide to custom versus off-the-shelf software. We compare the contract and data differences between subscription and installed software in SaaS vs on-premise software.

Ten clauses your contract should contain

1. Ownership. State whether the economic rights in the source code, database schema, interface designs and documentation are assigned and, if so, list each right (reproduction, adaptation, distribution and so on).
2. Pre-existing components. List the developer's existing libraries and any open-source components, grant you a perpetual, transferable right to use them, and record the obligations of the open-source licences involved.
3. Form of delivery. Require the code as a version-controlled repository (for example Git) with its full history, plus build and deployment instructions — not just a zip file.
4. Timing of delivery. Tie delivery of the current code to every milestone payment rather than the end of the project, so that if the work stops you hold everything done to date.
5. Documentation. Include the architecture overview, database schema, API documentation, configuration list and administrator guide in scope. Undocumented code is worth far less to the next team.
6. Access credentials. Domains, servers, cloud accounts, third-party service accounts and certificates should be registered to your organisation, with administrator access held by you. For mobile apps this includes the App Store and Google Play developer accounts; we cover these items in what drives mobile app cost.
7. Acceptance criteria. Define which tests mark the work as accepted, how defects are classified and how quickly they are fixed. The steps in our software requirements analysis guide can be attached as a schedule. For writing measurable acceptance criteria, see our guide to writing technical specifications.
8. Maintenance and support. Put post-delivery maintenance, response times and the charging model in a separate schedule; not renewing maintenance must not affect your right to use the code. How maintenance feeds into total cost is covered in software development cost.
9. Confidentiality and data. Where personal data is involved, set out the contractor's role under KVKK (Türkiye's Personal Data Protection Law, broadly comparable to GDPR) — usually a data processor — where data is hosted, which subcontractors are allowed, and which tools, including AI tools, may be used on your code. You can also add that an independent penetration test will be carried out before go-live and that critical findings will be fixed before acceptance.
10. Exit. Describe how and within how many days code, data and access pass to you when the contract ends or the developer ceases trading, and the release conditions if escrow is used.

A client who raises these points at the proposal stage also learns a great deal about how transparent the developer is. For other questions to ask, read our guide on choosing a software company. Guides to every step of the buying process are collected in our Software Development articles.

The contract, handover records and documentation are as valuable as the code itself, so keep them in a centrally managed workspace rather than in personal inboxes. SmartFiles, part of the Smart360 suite, lets you manage company files from a single panel with a single sign-in, and a departing employee's access is removed in one step.

How we handle this at Digital Bridge

Digital Bridge does not sell off-the-shelf packages. Every project starts with a needs analysis and moves forward on a written proposal setting out scope, phases and cost. We discuss source code and intellectual property inside that proposal, not as an afterthought:

• We define scope and ownership together. For software solutions projects, the proposal separates what is built specifically for you from any pre-existing components, and shows when each handover takes place.
• Custom SCADA code is yours. In our SCADA/HMI projects, the source code of software developed specifically for the client belongs to the client, with no additional licence fee. We compare this model with licensed commercial SCADA in commercial vs custom SCADA.
• We aim for a handover another team could pick up. For custom web software and mobile app development, we agree up front how deployment, configuration and integration knowledge will be included in the delivery.
• We review your existing contract through a technical lens. If you work with another supplier, our consultancy team can identify the technical gaps in your current contract and handover package and give you a concrete list to take to your legal adviser.

Next step

Run a quick check on the custom software you use today: do you hold the source code, when was it last updated, whose name are the server and domain accounts in, and does the contract state which rights were assigned? If any answer is "not sure", get in touch. We can map your current position together, or set up the contract and handover plan for your next project correctly from the start.