Legal Risks Arising from the Misuse of Open Source Software

Open-source software is one of the most powerful building blocks of the modern software development world. Open-source components are used across a wide range of sectors, from startups and large industrial companies to e-commerce platforms, finance, and healthcare technologies. However, the most common mistake in practice is confusing the concept of "open source" with "free, unconditional, and unlimited use." In reality, open source is not an area where copyright is void; on the contrary, it is a licensed area of ​​use granted by the copyright holder under specific conditions. Therefore, misuse of open-source code can lead to risks under Turkish law, including copyright infringement, breach of contract, damages, injunctive relief, corporate liability, and in some cases, criminal law.

The Open Source Initiative's definition of open source clearly demonstrates this fact. According to the definition, open source does not simply mean access to the source code; the license must allow free redistribution, include the source code, permit modification and the creation of derivative works, and not prohibit the use of the software in specific areas, including commercial activities. In other words, open source software may be "free," but it is not "unregulated." The legally safe area of ​​use is limited by the scope of the license's authorization. Exceeding this authorization or violating the license terms narrows the scope of permission provided by open source code, and its use becomes disputed under copyright law.

In Turkish law, computer programs are among the works protected under the Law on Intellectual and Artistic Works (FSEK). Article 2 of the FSEK considers computer programs expressed in any form, and under certain conditions their preparatory designs, as works of science and literature. Although the same article states that the ideas and principles forming the basis of any element of the program are not considered works, the expressed code itself is under copyright protection. Furthermore, according to Article 22 of the FSEK, the right of reproduction belongs to the author, and the installation, viewing, execution, transmission, and storage of the computer program also fall within the scope of the right of reproduction. Therefore, misuse of open-source code often does not remain at the level of "I have only violated the license terms"; depending on the specific case, it may result in interference with the financial rights of the copyright holder.

The fundamental concept here is that an open-source license is permission from the copyright holder to use the content. Therefore, the license text should not be seen merely as an ethical document addressed to the technical community; it should be considered a set of permissions and conditions with legal consequences. Under the Turkish Code of Obligations, in the event of non-performance or improper performance of a debt, the debtor is obligated to compensate the other party for damages unless they prove their innocence. Similarly, under the tort regime, a person who causes harm to another through a culpable and unlawful act is obligated to compensate for that harm. These two fundamental principles allow for discussions of both contractual and tort liability in cases of open-source license infringements.

Why is open-source software not considered "public domain"?

One of the most dangerous misconceptions in practice is the idea that code published on GitHub or similar platforms is automatically open to everyone without restriction. However, even the definition of open source acknowledges that usage is subject to licensing terms; distribution terms are as important as the existence of the source code. Under the Turkish Copyright Law, financial rights generally belong to the author; the right to use the work can only be exercised to the extent permitted by the author. Therefore, the "I found it on the internet, so it must be free" approach is not legally secure. The copyright of the owner of open source code continues; only the right to use it within specific licensing terms is granted.

For example, the MIT license grants broad permission to use, copy, modify, merge, publish, distribute, sublicense, and sell software; however, the fundamental condition is that the copyright notice and permission text must be preserved in copies or essential parts of the software. Therefore, including an MIT-licensed library in a product and completely removing the license and copyright notices cannot be considered legally insignificant by saying, "MIT is very permissive anyway." In such licenses, the risk arises primarily from the preservation of the notice, attribution, and license text.

Apache License 2.0 grants extensive rights; however, it includes explicit conditions such as providing the license text, clearly marking modified files, and protecting copyright, patent, trademark, and attribution notices in the source form. Contributors also grant patent licenses; however, the patent license may be terminated if a party files a patent infringement lawsuit for the licensed work or contribution. Therefore, misuse under Apache 2.0 can put companies at risk not only in terms of copyright but also patent and notification obligations. Especially in enterprise products, neglecting NOTICE files and change notifications is an often underestimated but potentially serious legal infringement.

Why is the misuse of copyleft licenses more dangerous?

Open source licenses do not impose the same level of obligation. The simplest distinction is between "permissive" and "copyleft" licenses. Licenses like MIT and Apache are more flexible, while licenses like GPL, AGPL, LGPL, and MPL impose stricter sharing and disclosure requirements. A common mistake companies make is lumping all open source licenses together. However, a single component added to your product can create obligations, depending on your distribution model, to disclose the source code, distribute under the same license, provide users with access to the source, or offer reconnectivity.

GPLv3 has particularly strict consequences in cases of distribution and transmission. According to the official GPL text, when transferring modified source versions, the changes must be indicated, the work must be licensed under the GPL, and certain legal notices must be preserved. In the case of distribution in object code format, the corresponding source code must also be provided in accordance with the license terms. The GPL also distinguishes between "aggregate" (simply existing side-by-side in the same environment) and extending the license to the entire work within a larger program; this distinction can be quite technical and prone to conflict in practice. Therefore, embedding GPL code into closed-source commercial products without control is one of the riskiest mistakes for a company.

AGPL risks are particularly high in SaaS and cloud services. The official text of the AGPL aims to provide relevant users with access to the source code in modified versions that are interactive over the network. Even if a company thinks, "we're not distributing the product as a copy to the customer, we're just running it on the server," if the component used is AGPL-compliant, additional liabilities may arise for the modified version offered over the network. One of the most costly mistakes SaaS companies make is failing to understand the difference between GPL and AGPL. This distinction is critical, especially in customer portals, cloud ERP systems, online design tools, or AI-based web services.

LGPL is often misunderstood as being "not as strict as GPL." However, LGPL also creates obligations under certain circumstances based on the combined work and linking model. The official LGPL text defines the concept of "Combined Work" and permits the distribution of applications under different licenses within a library under certain conditions; however, it requires providing the user with specific warnings, providing license documents, and in some cases, preserving structures that allow for relinking or reproduction. Static linking, end-user agreements prohibiting reverse engineering, or designs that effectively eliminate the possibility of relinking can complicate LGPL compliance.

MPL 2.0 offers a more balanced model with a file-level copyleft approach. Mozilla's own FAQ defines MPL as "file-level copyleft"; the license text also mandates that Covered Software distribute its source form under the MPL terms, ensure reasonable accessibility of the source form in executable form distribution, and maintain license/copyright notices. MPL also allows for Larger Work; however, in case of breach of the license terms by Covered Software, rights automatically terminate and can be restored later through certain cure mechanisms. Therefore, it is often possible to incorporate MPL code into closed-source products; however, neglecting file-based obligations can lead to serious incompatibility.

The most common mistakes in the misuse of open source code

The first major mistake is including code in a project without ever reading the license text. Developers, especially under short-term delivery pressure, may add libraries through the package manager without examining the license class, copyright notices, NOTICE files, and source code obligations. This approach may seem minor at first, but it becomes a serious red flag when the product is released commercially, enters an investment round, or undergoes takeover review. License compliance is not a detail that can be fixed with cosmetic changes in the final stages of software architecture; it's an integral part of product design. This observation is a direct result of the distribution, notification, and source access obligations clearly stated in the GPL, LGPL, MPL, and Apache license texts.

The second major mistake is over-reliance on the "we only use it internally" defense. Some licenses do have significant differences between purely internal use and distribution; for example, under the GPL, private use not shared with the public does not have the same consequences as versions conveyed to the outside world. However, companies are often confused about what truly constitutes "internal use" and what counts as actual distribution to customers, resellers, affiliates, suppliers, or cloud users. This boundary is particularly blurred in group companies, franchise structures, and SaaS models. Under the AGPL, remote interaction is already directly relevant. Therefore, the "no distribution" defense cannot be considered reliable without examining the license text and the specific technical architecture.

The third major mistake is modifying open-source components without marking them as such. Apache 2.0 requires modified files to be clearly marked. The GPL mandates change and date notifications in modified versions. The MPL, on the other hand, does not allow removing the essence of license and copyright notices in the source form and imposes responsibility for source access. If companies do not keep track of the changes made by the development team, they cannot later distinguish which files belong to third-party code and which belong to the company code. This creates major problems in terms of both license compliance and the protection of trade secrets.

The fourth major mistake is leaving license compliance solely to the software developers. However, according to the Turkish Commercial Code, board members and third parties responsible for management in joint-stock companies are obliged to perform their duties with the diligence of a prudent manager and to protect the company's interests in accordance with the rules of honesty. The same Code stipulates that board members and managers who cannot prove their innocence in case of breach of duty may be held liable to the company, shareholders, and creditors. A similar duty of care and loyalty is also stipulated for managers of limited liability companies. Open source compliance is therefore not just a matter of the technical team, but also a matter of corporate governance and risk management.

The main legal consequences that may arise under Turkish law

Open source license infringement often initially appears as a private law dispute. According to Article 68 of the Turkish Copyright Law, those who process, reproduce, distribute, perform, or publicly transmit a work without obtaining the legally valid written permission of the rights holder may be liable by the rights holder for up to three times the amount they would have requested if a contract had been made, or for the fair market value. This provision is extremely important in software license disputes because even in cases where the full extent of the damages cannot be calculated, the rights holder can establish a strong basis for claiming compensation based on the license fee or fair market value. In open source license infringement, especially if the distribution model exceeds the license limit, this article can have serious financial consequences in the specific case.

Article 70 of the Turkish Copyright Law is also important. Within the framework of this article, a person whose financial rights have been violated can claim compensation under the provisions relating to torts if there is fault; they can also demand that the profits obtained be given to them. Considering this together with the general tort liability in Article 49 of the Turkish Code of Obligations and the provisions on compensation for damages arising from breach of contract in Article 112 of the Turkish Code of Obligations, multiple legal claims can arise side-by-side in the same case in cases of misuse of open-source code. Especially if the customer agreement contains commitments such as "the product does not infringe the rights of third parties," the problem can escalate not only with the rights holder but also in terms of warranty and compensation obligations towards the customer.

The liability arising from auxiliary personnel and employees should also not be overlooked. According to Article 116 of the Turkish Code of Obligations, even if the debtor has entrusted the performance of the obligation or the exercise of the right arising from the debt relationship to auxiliary personnel, they are still obliged to compensate the other party for any damage caused by these individuals during the execution of the work. Therefore, the addition of inappropriate open-source code to the project by an outsourcing developer, freelancer, subcontractor, or employee team does not automatically absolve the company of liability. Defenses such as "an intern added it," "a former programmer left it like that," or "an agency did it" are not always protective in terms of contractual liability.

Is there a risk of criminal penalties?

The answer to this question depends on the specific case. Article 71 of the Copyright Law stipulates criminal penalties for individuals who, without the written permission of the copyright holder, process, represent, reproduce, modify, distribute, publicly transmit, publish, or offer for sale, sell, rent, disseminate, or possess for purposes other than personal use, illegally reproduced works. According to Article 75 of the same law, the offenses in Articles 71 and 72 are subject to complaint; copyright holders must apply with documents and evidence for the prosecution process. Not every case of open-source license violations turns into a criminal case; however, if the permission granted by the license is exceeded and the act clearly reaches the level of unauthorized reproduction and distribution, the criminal risk may cease to be purely theoretical. Cases such as deliberately removing license notices, completely disregarding the terms in closed-source distribution, or disabling protective programs are evaluated more sensitively.

Article 72 of the Turkish Copyright Law also prescribes penalties for software or technical equipment designed to render ineffective additional programs created to prevent the unlawful reproduction of computer programs. Not every dispute in the context of open source falls under Article 72; however, the use of tools that circumvent protection mechanisms to bypass license restrictions can go beyond classic license incompatibility. Therefore, in hybrid systems where open source code and proprietary components are used together, circumventing license limits through technical means should be examined separately.

Evidence, proof, and the legal process

Open source licensing disputes are technically complex, making proof a crucial factor. According to Article 199 of the Turkish Code of Civil Procedure (HMK), data and similar information carriers in electronic form are considered documents. Therefore, repository records, commit history, CI/CD logs, build outputs, SBOM records, package manager manifest files, license scan reports, email chains, and product distribution files can constitute evidence. However, according to Article 189/2 of the HMK, evidence obtained illegally cannot be considered by the court. Consequently, unlawful interference with employee devices, private accounts, or personal storage during an internal company audit could create a new procedural problem.

Article 76 of the Turkish Copyright Law provides the rights holder with a significant advantage in proving their claim. If the court presents sufficient evidence to establish a strong conviction in the veracity of the plaintiff's claim, it may request the user to submit documents demonstrating that they obtained the permissions and authorizations stipulated in the law, or a list of the works used; failure to provide these constitutes a presumption of unlawful use. In the software world, this means that a company that does not maintain license files, NOTICE records, source code parsing, and component inventory will find it very difficult to technically prove "we were actually compliant" when a lawsuit is filed. Moreover, under Article 77 of the Turkish Copyright Law, a preliminary injunction may be considered in cases of strong probability and substantial damage.

Personal Data Protection Law (KVKK) and data security aspect

Misuse of open-source software sometimes creates risks not directly related to copyright, but through data security. Especially when using external packages, telemetry modules, analytical libraries, cloud-dependent components, and open-source tools that send data to remote servers, companies may simultaneously face risks under the Turkish Personal Data Protection Law (KVKK). Article 10 of the KVKK imposes an obligation on the data controller to inform the data; Article 12 regulates the data controller's obligation to take necessary technical and administrative measures and conduct necessary audits to prevent the unlawful processing and access of personal data and to ensure the preservation of data. Articles 8 and 9 are also particularly important in the context of data transfer abroad. Misinterpreting the data flow, rather than the license, of an open-source component can expose a company to both copyright and KVKK violations.

How should companies mitigate these risks?

The most appropriate approach is not to ban open source code, but to use it in a controlled and documented manner. Every company should have at least an open source usage policy, component inventory, license classification, approval mechanism, and pre-distribution compliance check. Separate risk matrices should be created for licenses such as GPL, AGPL, LGPL, MPL, Apache, MIT, and others; and the technical and legal teams should work together, especially regarding source code disclosure, notice, patent, relink, network disclosure, and cure mechanisms. This approach not only reduces risks under the Turkish Copyright Law and the Turkish Code of Obligations, but also provides a strong defense against the duty of care and director's liability under the Turkish Commercial Code.

In practice, one of the most useful tools is the SBOM, or software component inventory. However, simply keeping a list is not enough; each component's license type, which files it touches, whether it is statically or dynamically linked, whether it is distributed in the product, how it reaches the customer, and what changes the company has made must also be recorded. Otherwise, the technical inventory does not become a legal compliance inventory. Especially in investment, merger and acquisition, or large corporate sales processes, a lack of open source compliance can lead not only to legal compensation risks but also to valuation reductions and transaction delays. The basis for this outcome is that licenses contain different conditions and are subject to the duty of care of company management.

Conclusion

Open-source software provides cost advantages, speed, and innovation for companies; however, the idea that "it doesn't carry legal risks because it's free" is incorrect. Open-source software is not an area where copyright is abandoned, but rather governed by licensing. In Turkish law, computer programs are protected as works; reproduction, distribution, operation, and commercialization processes that violate license terms can have multifaceted consequences under the Turkish Copyright Law, Turkish Code of Obligations, Turkish Code of Civil Procedure, Turkish Personal Data Protection Law, and corporate law. In particular, misinterpretation of licenses such as GPL, AGPL, LGPL, and MPL; neglect of notice and source code obligations; uncontrolled integration by employees and external teams; and company management's perception of this area as solely an IT matter can lead to costly disputes.

The correct legal approach is not to avoid using open source, but to make the licensing architecture a part of the product architecture. Risk can be managed if the company knows which code it is using under which license, what it is changing in which file, what it is distributing to the customer, and which liability arises from which component. If it doesn't know, the advantage of open source can quickly turn into copyright, compensation, distribution restrictions, and corporate reputation problems. In the open source world, real security doesn't begin with downloading the code; it begins with correctly reading the license.

Frequently Asked Questions

Is using open source code always free?
No. The freedom of open source code is limited by the boundaries set by the relevant license. The OSI definition states that open source licenses must be based on criteria such as redistribution, source code, derivative works, and usage; this does not mean "unconditional freedom."

Can the use of open-source code lead to copyright infringement?
Yes, it can. Because computer programs are considered works under Turkish law, and Article 22 of the Law on Intellectual and Artistic Works includes the installation, execution, and storage of the program within the scope of financial rights. If the limits permitted by the license are exceeded, a copyright infringement dispute may arise.

What is the fundamental difference in risk between GPL and MIT?
The MIT license allows for broader and more flexible use; the primary obligation is the protection of copyright and permission notices. GPL, on the other hand, imposes stricter obligations, such as the transmission of modified versions under the same license and the provision of corresponding source code in object code distribution.

Why is the AGPL riskier for SaaS companies?
Because the AGPL establishes a specific framework that aims to provide access to the source code of the modified version for users interacting over the network. Therefore, simply running it on the server doesn't always absolve you of responsibility.

What is the most critical step for achieving consistency within the company?
It's merging the component inventory with the license inventory. This means not only recording which libraries are used, but also the license type, changes made, distribution method, and notice/source obligations.