Intellectual Property in Software: Legal Protection Strategies for Computer Programs

Related guides: Leading Cases on the Legal Protection of Software: A Review of Court of Cassation Rulings · Patentability of Software: European Patent Office (EPO) Case Law

1. Introduction: The Economic and Legal Value of Digital Assets

In today's global economy, software is no longer an add-on to hardware; it has become a strategic intellectual capital item representing the highest value on company balance sheets. Unless they are equipped with a sound legal protection architecture, code bases, which have become businesses' most valuable assets in a digitalised world, are exposed not only to unfair competition but also to the risk of failing intellectual property audits in investment rounds (IP due diligence), a fall in company valuation and, ultimately, loss of capital.

The recognition of software as an economic value independent of hardware is the result of a historical transformation that began in 1968 with IBM's decision to commercialise software and hardware separately (unbundling). This separation led to the birth of an independent software market, but it also brought serious uncertainty about the legal status of software. At the international level, this uncertainty was resolved when Article 10 of the TRIPS Agreement and Article 4 of the WIPO Copyright Treaty expressly provided that computer programs are to be protected as "literary works" within the meaning of the Berne Convention. Turkish law has also transposed this international standard into domestic law through amendments to Law No. 5846 on Intellectual and Artistic Works (FSEK).

Determining the legal status of software and properly structuring the means of protection is therefore not a technical detail; it is a strategic management decision that safeguards the company's commercial future, its competitiveness and its credibility with investors. The foundation of this strategy lies in correctly defining, in legal terms, the asset to be protected.

2. Conceptual Framework: The Critical Distinction Between a "Computer Program" and "Software"

For legal proceedings and licensing strategies to be conducted soundly, the hierarchical difference between the terms "computer program" and "software" must be observed. These two concepts, used interchangeably in everyday language, have different scopes and consequences in legal terminology:

• Computer Program: Under Article 1/B-(g) of the FSEK, this means a set of computer instructions arranged so as to enable a computer system to perform a particular operation or task, together with the preparatory work leading to the creation and development of that set of instructions.
• Software: This is the overarching, comprehensive concept that includes, in addition to the computer program, operating and user manuals, flow charts, database structures and all documentation describing the program. The broad definition of software in Article 3/(l) of Law No. 4691 on Technology Development Zones also confirms this approach.

Strategic Impact: A definition of rights in licence or assignment agreements made solely by reference to the "program" may leave preparatory materials, documentation or database structures outside its scope. This gap may later lead to serious operational and legal disputes over access to source code and authority to maintain and update it, particularly for companies that obtain services from software houses. When drafting the agreement, the asset protected or assigned must be defined with all its components, in the manner of an inventory.

3. Protection Under the Law on Intellectual and Artistic Works (FSEK)

Under FSEK Art. 2/1, computer programs are protected in the category of "scientific and literary works", in whatever form they are expressed; preparatory designs also benefit from the same protection, provided that they result in a program at a later stage. This protection arises automatically upon the creation of the work; no registration, recording or other formal requirement applies. The term of protection is, as a rule, the life of the author and 70 years after their death (FSEK Art. 27). For software to benefit from this protection, two basic conditions must be met together:

• Originality (Hususiyet): The software must reflect the creative effort and characteristic choices of its author. In the case law of the Court of Cassation, originality is given concrete form through the criterion of being the product of an independent intellectual effort that is not commonplace; routine blocks of code dictated by technical necessity may not cross this threshold.
• Embodiment of the Idea: Abstract ideas are not protected; the code or design must have taken a perceptible form (source code, object code, flow chart, etc.).

3.1. Elements Within the Scope of Protection

• Source Code and Object Code: There is no difference in protection between the human-readable form of the program (source code) and the binary form processed by the machine (object code); both are protected as literary works.
• Microcode: Microprograms that control hardware units are protected by copyright as computer programs even if they are embedded in hardware, as also confirmed in American case law in NEC Corp. v. Intel Corp.
• Preparatory Designs: Flow charts, analyses and architectural designs that have not yet been coded but form the roadmap of the software also qualify as works under FSEK Art. 2/1. This means that even the architectural drafts left behind by a developer who leaves the project cannot be used without permission.

3.2. Areas Outside Protection and Managing the Risk

The last paragraph of FSEK Art. 2 expressly provides that the ideas and principles underlying any element of a computer program, including those underlying its interfaces, are not regarded as works. The Court of Justice of the European Union also held in SAS Institute v. World Programming (C-406/10) that the functionality of a program, the programming language and the format of data files do not benefit from copyright protection. The practical consequence is this: a competitor taking the solution logic or algorithm of your software and rewriting it in their own original code does not, by itself, constitute copyright infringement.

So how is this risk managed? This layer, which copyright does not protect, should be secured with two complementary tools: non-disclosure agreements (NDAs) and the trade secret regime should be brought into play to prevent disclosure of algorithms and business logic; and, if the software provides a technical solution to a technical problem, a computer-implemented invention (CII) patent should be considered (see Sections 5 and 6). The strategic decision is this: if the algorithm is at the heart of the product, is very difficult to reverse-engineer and will remain relevant for many years, Trade Secret should be preferred; if competitors are likely to develop a similar solution independently and the market advantage is worth protecting for 20 years, Patent should be preferred.

3.3. Statutory Exceptions: Back-up and Interoperability

FSEK Art. 38 grants two important freedoms to the lawful user of a program: the making of a back-up copy, to the extent necessary for use, cannot be prohibited even by contract; furthermore, decompilation is possible under strict conditions in order to obtain the information necessary to achieve the interoperability of an independently created program with other programs. Failure to observe these mandatory limits when drafting licence agreements results in the invalidity of the relevant provisions.

4. Authorship of Software and the Employment Relationship

Software development is, as a rule, a collective effort, and this is the area where ownership disputes are most frequent. The balance of rights should be established along the following lines:

• Economic Rights: Under FSEK Art. 18/2, the authority to exercise the economic rights in works created by civil servants, public employees and workers in the course of their duties belongs to those who employ or appoint them, unless otherwise understood from a contract or from the nature of the work. The point to note is that this presumption applies only in a genuine employment relationship and to output falling within the scope of the obligation to perform work.
• Independent Contractors and Outsourcing: Freelance developers and software houses fall outside the presumption in Art. 18/2; rights can only be transferred by a written agreement. Under FSEK Art. 52, it is a condition of validity that assignment agreements are in writing and that the rights being assigned (reproduction, distribution, adaptation, communication to the public) are specified individually. Blanket wording such as "all rights have been assigned" gives rise to serious disputes over validity in practice.
• Moral Rights and Risk Management: Moral rights, such as the right to be identified as the author and the right to prohibit changes to the work, cannot be assigned. However, contractual provisions leaving the authority to exercise these rights to the employer, or consenting to their exercise, are valid and of critical importance. Otherwise, a developer who leaves the company retains the ability to disrupt the release of a strategic project or to claim compensation on the grounds that their name was not stated or that their work was changed without permission.
• Joint Authorship and Co-authorship: In projects with contributions from more than one person, the regime in FSEK Art. 9 or Art. 10 applies depending on whether the contributions are separable; in co-authorship, the exercise of rights is, as a rule, subject to the unanimity of the co-authors. Failing to clarify the transfer of rights from the outset by a written agreement paves the way for third parties to claim rights over the company's most valuable intellectual property asset.

5. Patent Law: Computer-Implemented Inventions (CII)

Under Article 82/2-(c) of Industrial Property Law No. 6769 (SMK), computer programs "as such" (per se) are not regarded as inventions and cannot be patented. However, the third paragraph of the same article provides that exclusion from patentability applies only where the invention relates exclusively to that subject matter. Accordingly, software-based inventions that display technical character, that is, that provide a solution to a technical problem by technical means, may be the subject of patent protection as computer-implemented inventions (CII). The settled practice of the European Patent Office (the COMVIK approach) also takes into account only the features that make a technical contribution when assessing inventive step.

5.1. Technical Character and Concrete Examples

For patentability, it is not sufficient for the program merely to perform a calculation or a business method; it must provide a technical solution to a technical problem. In practice, the following types of invention come close to patentability:

• Hardware Interaction: An embedded control algorithm that controls a vehicle's ABS braking system.
• Resource Efficiency: Technical methods that use a computer's memory or processing power measurably more efficiently than known methods.
• Data Transmission: Solutions that increase data transfer speed, provide compression efficiency or technically optimise network traffic.

5.2. The Strategic Difference Between Copyright and Patent

Where the requirements of novelty, inventive step and industrial applicability are met together, a patent provides a strong monopoly right for 20 years from the filing date (SMK Art. 101). While copyright protects only the concrete expression of the code, a patent also covers the inventive idea implemented by that code and prevents competitors from implementing the same technical solution even with different code. For this reason, a CII patent is the highest-level strategic tool for software companies aiming at market dominance; however, it should not be forgotten that it is obtained in return for disclosing the invention to the public during the application process.

6. Trade Secret Protection: The Invisible but Indispensable Layer

For elements that fall outside or in the shadow of copyright and patent protection, such as algorithms, data processing logic, training data sets and know-how, the third layer of protection is the trade secret regime. In Turkish law, trade secrets are protected through the unfair competition provisions of Turkish Commercial Code No. 6102 (TTK) (Art. 54 et seq.), contractual confidentiality obligations and Article 239 of the Turkish Criminal Code (TCK), which penalises the disclosure of production and business secrets. Trade secret protection differs from a patent in that it can be unlimited in time; its weakness is that protection ends if the information is uncovered through independent development or lawful reverse engineering. For this reason, secret management should be designed as a corporate policy in which NDAs, access authorisation protocols, confidentiality and non-competition clauses in employee contracts and technical security measures operate together.

While an NDA ensures that information remains secret, a non-competition clause directly prevents an employee from working for a competitor for a certain period after leaving the company. The latter is regulated in Article 444 et seq. of the Turkish Code of Obligations (TBK), and its validity is subject to certain conditions (reasonableness, limitation as to place, time and subject matter).

7. Business Models, Open Source Strategies and the Exhaustion Principle

In the commercialisation of software, ownership and licence management directly determine the company's revenue model. While closed-source models provide maximum control, open-source models offer development speed and community support; however, each model carries a different legal risk:

Open Source Compliance (OSS Compliance): A significant part of modern software is built on open-source components. A GPL component incorporated into a project without control may, because of the copyleft effect, trigger an obligation to open the source code of the entire product. In investment and merger and acquisition processes, auditing the software bill of materials (SBOM) and licence compliance is now a standard due diligence item.

7.1. The Digital Exhaustion Principle

Under the exhaustion principle laid down in FSEK Art. 23/2, the distribution right in copies offered for sale with the author's permission is exhausted upon the first sale. Whether this principle applies where software is acquired by digital download rather than on a physical carrier is debated. The Court of Justice of the European Union held in UsedSoft v. Oracle (C-128/11) that software copies downloaded for a fee with a right of use for an unlimited period constitute a "sale" and that the distribution right is exhausted, so that the resale of second-hand licences is possible under certain conditions. This case law points to a serious revenue-model risk for software producers working with a perpetual licence model. The UsedSoft decision is limited to perpetual licences; the exhaustion principle does not apply to fixed-term licences or to rental and lending rights (FSEK Art. 23/2).

The Strategic Advantage of the SaaS Model: In the Software as a Service model, no permanent copy is transferred to the user; the legal relationship is not a "sale" but a fixed-term service subscription. For this reason, the exhaustion principle does not apply, no second-hand market risk arises, and the producer maintains uninterrupted control over the software. This is also the main legal motive behind the sector's shift towards subscription models.

8. Proof and Security of Evidence: Proving the Right Is as Important as Its Existence

Since copyright protection arises without registration, in the event of a dispute, proof of who created the work and when becomes decisive. A proactive evidence strategy should include the following tools:

• Voluntary Registration: Voluntary registration with the Ministry of Culture and Tourism under FSEK Art. 13/3, although not constitutive of rights, provides a strong presumption of proof.
• Time Stamp: With a qualified time stamp under Electronic Signature Law No. 5070, the existence of the source code on a certain date can be technically documented; version control system (Git) records also serve as supporting evidence.
• Source Code Escrow: In licence agreements with corporate customers, escrow arrangements securing access to the source code in cases such as the producer's bankruptcy or breach of its support obligations are a balanced risk management tool for both parties.

9. Conclusion: A Legal Roadmap for Software Companies

In the software world, competitive advantage is gained not only by producing high-quality code but by fortifying the rights in that code with a layered and comprehensive architecture. A proactive protection plan should be implemented at every step, from the analysis stage (preparatory designs) to the product reaching the end user (licensing). The approach we recommend for sustainable success is a four-layer hybrid protection strategy:

• Copyright: Support the automatically arising protection of code and preparatory materials as literary works with means of proof such as voluntary registration and time stamps.
• Patent (CII): If your software provides a technical solution to a technical problem, start the registration process without compromising the novelty of the invention (before public disclosure).
• Contract Management: In employee and outsourcing contracts, secure the transfer of economic rights by listing the rights individually in accordance with FSEK Art. 52, and secure the authority to exercise moral rights through consent clauses.
• Trade Secret and Open Source Compliance: Protect the algorithm and know-how layer with a corporate confidentiality policy and NDAs; eliminate the risk of forced disclosure arising from copyleft by regularly auditing the inventory of open-source components.

Intellectual property strategy is not a formality left to the end of the software development life cycle; it is a foundational process that must be carried out together with legal advice from the product's design stage onwards. A properly structured protection architecture not only deters infringements but also directly increases the company's bargaining power in investment, partnership and transfer processes. For Court of Cassation and EPO case law on the subject, you can also read our articles Leading Cases on the Legal Protection of Software and Patentability of Software: EPO Case Law.