Software Development Contracts in Turkey: Source Code and Copyright

At a glance

1. Define the product before deciding who owns it

Identify the deliverables individually: application, website, mobile interface, database structure, documentation, configuration and integration work. A phrase such as complete software solution can hide different assumptions about what will be handed over. State whether the agreement covers a bespoke program, modifications to an existing product or access to a hosted service. Those arrangements can produce very different practical rights when the supplier relationship ends.

Map the customer’s intended uses. Will the software be used internally, offered to customers, installed at several group companies or licensed to third parties? Must the customer alter it, appoint another developer or migrate it to different infrastructure? The rights and deliverables should support the intended business model instead of leaving these questions until an investor or replacement supplier asks for proof.

Identify exclusions explicitly. A contract for an online shop might not include ownership of stock photographs, payment-provider software or a pre-existing reporting tool. That is not inherently defective, but the customer needs to know which elements depend on separate permissions or subscriptions. An accurate component list is more useful than a sweeping ownership statement that the supplier has no legal ability to fulfil.

2. Separate source-code delivery from the economic rights

Source code is the human-readable material used to develop a program. Possessing a copy does not itself settle the legal entitlement to reproduce, adapt, distribute or otherwise exploit it. Conversely, a contractual permission can exist even where practical access to the necessary files remains incomplete. The agreement should address both the legal rights and the material needed to exercise them.

The Ministry of Culture and Tourism’s copyright guidance explains the requirement for written agreements identifying economic rights separately. Do not rely only on an invoice describing software ownership or a vague statement that all rights belong to the client. Identify the program and the specific rights, territory, duration, exclusivity and permitted users within the actual arrangement.

Authorship and moral rights need separate treatment from economic exploitation rights. A commercial clause should not promise that every legal connection between the human creator and the work vanishes. Likewise, an attribution requirement, licence notice and the supplier’s right to use the customer’s name in advertising are different matters. Examine them separately rather than treating a broad marketing clause as part of an unavoidable technical licence.

3. Verify the supplier’s chain of authority

Ask who actually created the code and other deliverables. A company’s ability to grant rights can depend on employee-created work, subcontractor arrangements and licences for incorporated components. Article 18 of Law No. 5846 addresses the exercise of rights in employment and comparable relationships within its conditions. An independent freelancer should not automatically be treated as an employee merely because the supplier managed their tasks.

Request appropriate assurances and supporting documentation for the rights the supplier promises. The review does not necessarily require disclosure of every confidential employment contract. It does require an intelligible basis for believing the supplier can grant the stated rights. A warranty that somebody owns everything is less useful when the component schedule openly identifies material obtained from another business under a limited licence.

Where several developers contributed, distinguish the original program from later additions. Keep records of who supplied each part and on what terms. A subsequent purchase from the company does not automatically cure an earlier missing authorisation. The objective is a defensible chain of rights and use permissions, not a document collection assembled solely to make the transaction appear complete.

4. Inventory pre-existing and third-party components

Separate newly commissioned material from the supplier’s existing framework, third-party libraries, themes, fonts and other licensed assets. For each relevant component, identify the permission relied upon and any obligations attached to the intended use. Do not assume that freely downloadable material is free of licence conditions or that payment for the overall project purchases ownership of every incorporated element.

The supplier should explain which licences remain the customer’s responsibility after handover. A recurring subscription, hosting account and one-time development fee should be recorded separately. The cost model should identify what happens when a subscription ends and whether a replacement is technically and legally feasible. This makes continuity planning possible without requiring an unrealistic promise that all external dependencies will disappear.

Keep the component list current as the project changes. A library added during troubleshooting can affect maintenance, permitted distribution or security responsibilities. The legal review should be based on the delivered version, not only the initial proposal. A technical specialist can identify components and dependencies while the legal review considers the contractual permissions and responsibilities they create.

5. Specify what a usable source-code handover contains

A repository invitation is not necessarily a complete handover. Identify the branch or version, build instructions, configuration requirements, documentation and materials needed to maintain the agreed deliverable. The customer should know which accounts it controls and which belong to the supplier. An archive containing code that cannot be built without undisclosed dependencies can leave practical performance disputed even where files were supplied.

Handle credentials securely. Do not put production passwords, private keys or customer data into a public handover document. Agree the transfer channel, access changes and confirmation that the customer has the necessary operational control. Separately identify which supplier access remains authorised for maintenance. Removing access without preserving the required records can create disruption and evidential uncertainty.

A proposed code-deposit or release arrangement needs actual terms. Define what is deposited, how it is updated, when release occurs and what rights accompany release. Do not describe an informal backup held by a friend as a professional escrow service. The arrangement must be evaluated on its real custody, verification and release obligations rather than its reassuring label.

6. Use acceptance tests that match the agreed functions

List the functions, integrations and performance requirements to be tested. Identify the testing environment, data set, responsible people and method for recording defects. A demonstration of selected screens differs from successful operation under the agreed conditions. At the same time, acceptance should not depend on an undefined promise that the program will satisfy every future business idea the customer develops.

Separate a defect from a requested improvement. A function promised in the specification but not working is different from a newly proposed feature. Keep a change register showing the request, price, timetable and approval. This helps avoid a dispute in which the developer calls every repair extra work while the customer describes every enhancement as part of the original fixed price.

The legal effect of acceptance, continued use and reservations must be assessed under the contract and applicable law. Record unresolved items accurately. Do not sign a statement of unconditional completion merely to obtain an account password if material work remains disputed. Equally, do not deny all delivery when the customer has accepted and commercially used identifiable completed modules.

7. Connect payment milestones to the right obligations

A payment schedule should identify what triggers each instalment: commencement, delivery of a defined module, testing, final handover or a specified rights arrangement. Avoid one ambiguous milestone called launch if the parties disagree about whether it includes source code, documentation and operational accounts. The trigger should be something both parties can verify from the project record.

Rights becoming effective on payment require careful drafting. Identify which payment, whether partial rights apply to completed modules and what happens during an outstanding dispute. The customer needs to understand the position before relying on the program commercially. The developer likewise needs a clear payment mechanism rather than an assumption that the copyright position substitutes for ordinary debt collection.

An invoice dispute remains a separate evidential issue. Keep the agreed scope, delivery records, approvals and payments together. A final invoice does not by itself establish every promised right or deliverable. If charges are disputed, state whether the disagreement concerns unfinished work, unapproved changes, incorrect rates or another specific issue, rather than using a general refusal that obscures the real problem.

8. Plan maintenance, data access and exit before a disagreement

Identify the period and scope of support, response arrangements, security work and responsibility for third-party updates. A development contract does not automatically establish indefinite maintenance. Conversely, a maintenance fee should have an intelligible service scope rather than operate as an unexplained condition for access to the customer’s own operational records.

Data needs its own arrangement. Identify the data controller and processor roles where applicable, access permissions, export format and return or deletion obligations. A dispute about software ownership does not authorise unrestricted use of personal data. The KVKK guide explains why personal-data rights and contractual payment remedies must not be treated as the same procedure.

An exit plan should identify migration assistance, document handover and lawful access by a replacement developer. Do not attempt to regain control through unauthorised entry into the supplier’s infrastructure. Preserve the contract, current access position and urgency, then assess the appropriate contractual or judicial route. A business continuity problem calls for precise facts, not a promise that legal ownership alone instantly restores every technical service.

9. Preserve the project history without altering the disputed version

Keep the signed contract, specification, change requests, acceptance records, invoices and correspondence. Preserve the versions actually delivered and the date of each handover. A later repaired version can help operations but should not silently replace the evidence of the version originally disputed. The comparison should remain reproducible for a technical expert or court.

Record defects with a description of the input, expected behaviour, observed result and relevant environment. A screenshot of an error is useful but might not establish its cause. Ask an appropriate specialist to distinguish programming faults from configuration, infrastructure or unauthorised changes. Legal conclusions about breach should follow the agreed obligations and technical evidence, not an assumption that every outage was caused by the original developer.

Where confidentiality restricts sharing, agree a secure expert-review process. Do not publish the disputed code or customer data to attract public support. Preserve access logs and relevant communications lawfully. The aim is reliable evidence and a workable remedy, not a new dispute about disclosure or interference with a system during the original contract disagreement.

10. A hypothetical customer changing its developer

Assume a business pays a Turkish supplier for a booking application and later wants another developer to maintain it. It has an executable program and administrator access, but the contract is unclear about source code and modification rights. This example is invented; payment alone is not treated as proving either party’s complete legal position.

The review identifies the commissioned functions, actual creators, rights wording, component licences and promised handover. The technical reviewer explains which materials are necessary for maintenance. The parties can then assess a documented transfer or licence clarification and a practical handover, rather than argue only about who paid the invoice. Any settlement should identify continuing third-party permissions and the supplier’s remaining access.

If litigation is necessary, the claim must specify the obligation to be performed or the right alleged to have been infringed. A demand for all software rights without defining the work and contractual basis is less useful than a precise account. The example shows why performance, intellectual property and operational continuity should be addressed together but not confused.

11. Coordinate a cross-border software matter from Mersin

An overseas customer should provide the contract, delivered version, specification, rights provisions and a concise account of the problem. Identify any urgent loss of access, threatened disclosure or deadline. Governing law, jurisdiction and the nature of the relief require assessment; the parties’ location or the language of the contract does not alone answer every procedural question.

The international contract guide provides the wider context. Bakırcı & Keskin Law Office has physical offices in Istanbul and Mersin and coordinates Turkish-law work elsewhere in Turkey within the agreed mandate. English communication supports informed instructions, while technical inspections and formal proceedings follow their own requirements. No outcome, access-restoration date or recovery amount is guaranteed before the evidence is examined.

Related English guides

International contract disputes · Personal-data requests · Shareholder and company disputes · Disputed invoices and unapproved orders

Frequently asked questions

Official sources

• Law No. 5846: Intellectual and Artistic Works, including Articles 2, 18 and 52
• Ministry of Culture and Tourism: copyright and transfers
• Ministry of Culture and Tourism: voluntary registration questions
• Turkish Code of Obligations: contractual performance

Turkish legislation and any applicable treaty control. This is general English-language information, not an official translation or an opinion on an individual file.