Whether software, an AI model, a design or a trademark can be used or commercialised by a third party depends entirely on how the licence agreement is structured. In technology law the contract matters more than the code: a mistake in the code produces a bug, a mistake in the contract can hand permanent control of your intellectual property to a competitor.
For SaaS ventures and companies that license out their intellectual property, we set out below the structures that matter most in avoiding disputes and protecting brand value.
1. The Central Distinction: Assignment or Licence?
This is the most common misunderstanding. The customer, having paid a substantial sum, takes the view that "we bought the software, all rights are ours"; the licensor's position is that only a right of use was granted.
An assignment transfers ownership: Under the Intellectual and Artistic Works Act (FSEK), if you execute an assignment you can no longer use the code yourself, including within your own company. You have sold the property and handed over the deed.A licence is closer to a lease: You retain the rights and grant use within boundaries you define.A warning: In agreements with outsourced freelance developers, the rights in the work arise in the individual developer. Where an employee is on the payroll, Article 18/2 of FSEK gives the employer the right to exercise the economic rights unless agreed otherwise; that presumption does not apply to independent contractors. A company that cannot document the assignment cannot tell an investor that the software is its own.2. Defining the Scope
The more open-ended a licence agreement is, the faster it produces litigation. The agreement should draw the following lines precisely.
Exclusive vs non-exclusive: If you grant an exclusive licence and do not expressly reserve your own right of use, you cannot use the mark or the software yourself. Under Article 24/3 of the Industrial Property Law, in an exclusive licence the licensor may not grant a licence to anyone else and, unless the right is expressly reserved, may not use the mark itself either. Ownership does not help you here; you have handed the market to a single party.Sub-licensing: Does the licensee have the right to sub-license to third parties you have never dealt with, or into markets you did not contemplate? This should be addressed expressly.Modification and derivative works: Can the licensee modify the code and launch a new product under its own brand? The agreement should state clearly where rights over versions, derivative works and reverse engineering sit.3. Payment Structures
Four main models are used in practice.
Flat fee: Suitable for small licences. If the licensed software drives significant revenue for the licensee, or the deployment scales to enterprise level, you will have sold the right too cheaply.Royalty: A share of the licensee's revenue. The base should be defined as net sales rather than profit; otherwise the licensee can erode the base by increasing costs. The agreement should list precisely what the base includes and excludes: returns, discounts, taxes, channel commissions. Even so the risk is not eliminated, so the agreement should include a minimum guarantee and an audit right.Subscription (tiered SaaS): The per-user or per-API-call cloud billing model used by most technology companies today.Currency restrictions and the software exception: Under Decree No. 32 on the Protection of the Value of Turkish Currency and the related Communiqué No. 2008-32/34, parties resident in Türkiye are prohibited from denominating many types of contract in, or indexing them to, foreign currency.There is an important exception for licence agreements, and it is the point most often overlooked in practice. Article 8, paragraph 11 of the Communiqué provides: "Persons resident in Türkiye may, in agreements concluded among themselves for the sale of software produced abroad within the scope of information technologies, and in licence and service agreements relating to hardware and software produced abroad, determine the contract price and other payment obligations arising from such agreements in foreign currency or indexed to foreign currency."
The decisive criterion is where the software was produced. A licence for software developed in Türkiye cannot be priced in foreign currency between two Turkish companies; a licence for software developed abroad can be. Paragraph 8 of the same article separately exempts works contracts involving costs denominated in foreign currency, which should be considered where the software development work is structured as a works contract.
The consequence of a breach should also be understood correctly: the sanction is not, as a rule, invalidity of the entire contract, but the currency clause being disapplied and the price converted into Turkish lira, together with the possibility of an administrative fine under Law No. 1567.
4. IP Warranties and Indemnification
Suppose you license software that unknowingly incorporates copied open source code, and the rights holder sues your customer.
This is where an indemnification clause operates. The customer will want a clause under which, if a third party brings an infringement claim arising from the licensed product, the licensor bears the legal costs and damages.From the vendor's side, that exposure needs a ceiling: liability caps limiting recovery to a proportion of the contract value, with carve-outs negotiated deliberately rather than by accident.This analysis maps the principal structures in technology and IP licensing. Specific agreements should be drafted by qualified counsel.
Last updated: 10 August 2026.
