A technology product may have legal obligations that the company’s sales team is unaware of. Such obligations may arise from a simple decision made during software development: a developer adds a free library to a project to save a week of work. The library is released under a license such as the GNU General Public License, version 2 (GPL-2.0). The product is released to the market. Years later, during technical due diligence, a dispute with a customer, or a letter from a copyright holder, the company discovers that the benefits of this decision came with license terms that have been violated since the product was first released.
This article discusses the content of these terms, the reasons why the Cisco and Linksys cases remain the most famous cautionary tale on this issue, the courts' assessment of these licenses in recent practice, and the actions required of a company that creates or acquires a software product.
What is open source:
A program consists of two parts: the source code (what the developer writes) and the finished program (what the user uses). In the case of open source, the author shares the source code with everyone and allows them to use, modify, and distribute it. This permission is written in a license and always comes with conditions .
Three mistakes that often occur:
“Open source = anyone can do whatever they want.” No. The program is protected by copyright, and the permission also expires if the terms of the license are violated.
“It is free, that is, unconditional.” There is no obligation to pay a fee for it, but it has specific conditions of use.
“All open source is the same.” No. Licenses vary greatly, and it is this difference that determines how risky a component is.
2. "Free" does not mean "unconditional"
Open source software is usually free of charge, although its use requires compliance with legal conditions. Such a program is still protected by copyright, and the license is the only basis that grants a third party the right to copy, modify or distribute it. If the terms of the license are not respected, the permission no longer exists and the use of the program becomes an infringement of copyright. Georgian law is based on the same approach: according to subparagraph “a” of paragraph 1 of Article 6 of the Law of Georgia “On Copyright and Related Rights”, a computer program is considered a literary work, and according to Article 19, the author has the exclusive right to grant permission or prohibit its reproduction and adaptation. There is no provision in the law according to which a program would lose protection solely because the author has published it openly.
The GPL is a "copyleft" license. Its main rule is set out in Section 2(b) of GPL-2.0: Any work that is distributed and contains, in whole or in part, the program or is derived from it must be distributed to third parties in its entirety, free of charge, and under the same license. Section 3 sets out an additional practical obligation: when distributing the program in executable form, it must be accompanied by the complete corresponding source code or a written offer to provide it, valid for at least three years.
Simply put, if a company's product includes GPL-licensed code and distributes the product, it may be obligated to provide users with not only the component used, but also the source code of its own product.
Two things are often misunderstood. First: the obligation arises upon distribution, not upon use. The text of the license explicitly states that running the program is not restricted. Second: the penalty is severe. According to Section 4, any attempt to copy, modify, sublicense, or distribute the program beyond the scope permitted by the license is void and automatically terminates the rights granted under the license. Thus, the infringing company is not only violating the terms of the agreement, but is also distributing a program that it no longer has a license to distribute.
3. The case of Cisco and Linksys
In March 2003, Cisco agreed to acquire Linksys, a market leader in home networking equipment, for $500 million in stock. Linksys's best-selling router, the WRT54G, ran Linux-based software. Within months, a Linux kernel developers mailing list reported that Linksys was not providing the source code required by the GPL. The Free Software Foundation (FSF) also got involved. Linksys released the source code for the software in the summer of 2003. This incident is now seen as an example of why due diligence should include the code itself: the flaw was discovered after the deal was finalized.
It would be wrong to dismiss this case as mere negligence. A leading expert on open source law, Heather Meeker, noted at the time that Cisco “should have conducted due diligence at three levels of product integration”: Linksys purchased chipsets from Broadcom, and Broadcom outsourced software development to a foreign developer. The problem originated in the supply chain, which is why it is difficult to detect.
The case did not end in 2003. In December 2008, the FSF sued Cisco over Linksys products that contained FSF-owned software, and in May 2009, the dispute was settled. Under the terms of the settlement, Cisco appointed a free software director at Linksys to oversee compliance with the license terms. The company also agreed to inform previous recipients of the product of the rights granted by the GPL, to make the source code available, and to pay the FSF an unspecified amount of money. It is noteworthy for lawyers that the settlement was primarily about restoring the violated state and reputation, rather than a one-time, large amount of compensation for damages. In addition, the settlement provided for perpetual obligations and required the acquirer to implement a consistent program to comply with the terms of the license.
When signing an agreement with a developer or outsourcing company, the rules for using open source should be clearly defined in advance, because the problem usually arises at the development stage: the developer chooses a library, and the company's lawyer often learns about this choice only after the product is released. It is important to formulate the issue precisely: using open source does not in itself make the code public. GPL obligations arise when distributing the program, not when using it.
Liberal licenses, such as MIT, do not require the open source of their code at all. However, when distributing a product that incorporates a copyleft-type license component, a company may be required to transfer the source code of its product to the recipient, and the recipient has the right to further distribute this code. Therefore, the agreement should apply not to “open source” in general, but specifically to those licenses that pose a threat to your product distribution model.
In practice, the agreement should include three main conditions. First, the developer should be prohibited from using code distributed under GPL, LGPL, AGPL, or similar copyleft licenses without the customer's written consent. The requirement for prior consent should also apply to the use of code distributed under any unknown or non-standard licenses.
Second, the developer must provide the customer with a complete list of all open source components used, indicating the version and license of each. This list should be part of the product acceptance document. This requirement is especially important because open source components that the developer adds automatically or due to dependencies on other components often go unnoticed during traditional verification. According to a 2026 Black Duck report, 17% of open source components end up in the code base without the use of standard package managers, including in the form of copied fragments and code generated by artificial intelligence.
Third, the contract should also define the legal regime of code created using artificial intelligence: the developer must disclose the use of such tools and verify the results obtained in the same manner, as information about the origin of the code and the relevant license may be missing.
Appropriate contractual mechanisms are also necessary to enforce these terms. The developer must confirm and guarantee that the delivered product does not contain undisclosed open source components and does not infringe the rights of third parties. In case of violation, he must be liable to compensate the customer for damages. The customer must also have the right to audit and scan the source code, both upon receipt of the product and for a certain period after its delivery.
This approach stems directly from Linksys' experience: problems can also arise in the third and fourth links of the supply chain. Therefore, contractual terms and guarantees should not be limited to the direct contractor and should also extend to subcontractors hired by the developer. Without this protection, the consequences of a license violation fall on the customer, even when the violation occurs without his consent.
