Software License Infringement - Legal Cases and Risks for Developers

This article is for general informational purposes only and does not constitute legal advice. Nothing in this article creates a client relationship with a legal professional. Laws vary by jurisdiction. Consult a qualified legal professional for advice about your specific situation.

1. Introduction

Software licensing is one of the most widely misunderstood areas in modern development. A common misconception is that making source code publicly available automatically makes the software open source. In reality, a project can be proprietary even when its source code is accessible. This is known as source-available software, and it carries restrictions that are easy to overlook.

1.1 Overview

Open source software has become the backbone of modern development, with the vast majority of applications relying on open source libraries, frameworks, and tools. However, the freedom that open source licenses grant comes with obligations that many developers and companies overlook or misunderstand. When these obligations are violated, the consequences can be severe: from injunctions forcing product recalls and mandatory source code releases, to substantial financial damages reaching hundreds of thousands of euros. This article compiles documented legal cases and settlement agreements where developers and companies found themselves in legal trouble because they used open source software in ways that violated the terms of its license.

The legal landscape has evolved significantly. In the early days, open source licenses were sometimes viewed as unenforceable or merely aspirational. Today, courts in France, Germany, Italy and the United States have all affirmed that open source licenses fit completely within the traditional copyright legislative framework and do not rely on any exceptions from copyright law, and that their violation constitutes copyright infringement.

1.2 Definitions

Before diving into the cases, it is useful to clarify some of the terminology that appears throughout this article.

Why a license is needed at all

Under the Berne Convention, copyright protection is automatic: it attaches to a work the moment it is created, with no registration or copyright notice required. This means that, by default, software source code is "all rights reserved," and no one else has the right to copy, modify, or distribute it. An open source license is the mechanism by which the author affirmatively grants some of those exclusive rights back to the public, subject to conditions. This is why publishing source code without an accompanying license does not make it open source, or even legally usable by others. It simply leaves the code under full copyright protection with no permissions granted.

The organisations

Several organizations appear throughout this article because of their role in promoting, interpreting, or enforcing software licenses:

• Software Freedom Conservancy (SFC): A non-profit organization whose mission is to promote and defend the right to repair, improve, and reinstall software. Conservancy provides non-profit infrastructure and services to its member free and open source software projects and also conducts copyleft compliance activities.

• Free Software Foundation (FSF): A non-profit organization dedicated to promoting computer users' rights to use, study, copy, modify, and redistribute computer programs. The FSF has enforced the GNU GPL and LGPL through compliance efforts and, when necessary, legal action to protect the rights granted by those licenses.

• Open Source Initiative (OSI): A non-profit organization dedicated to promoting and protecting open source software. The OSI maintains the Open Source Definition, reviews and approves licenses as Open Source licenses, and advocates for the adoption and development of open source software.

Although these organizations' opinions are widely respected in the technology community, they are not governmental bodies, and their interpretations are not binding on courts. A court may interpret and enforce a software license based on its own analysis of the license text and applicable law, regardless of how organizations such as the FSF, SFC, or OSI characterize that license. For example, in Neo4j, Inc. v. PureThink, LLC, the court declined to rely on testimony regarding the Free Software Foundation's views of the AGPL and instead focused on the text of the license itself and established principles of contract and copyright law. The case illustrates that courts generally give primary weight to the language of the license and applicable legal rules rather than to external commentary from organizations associated with a license's drafting or promotion.

Open source vs source-available

The Open Source Initiative (OSI) maintains the Open Source Definition (OSD), a set of ten criteria that a software license must satisfy to be considered open source. These criteria include free redistribution, access to source code, and permission to create and distribute derived works.

By contrast, source-available licenses make source code available to users but impose restrictions that prevent the license from satisfying the OSD. Common restrictions include limits on commercial use, offering the software as a service, or creating competing products. As a result, source-available software is not generally regarded as open source by the OSI.

Popular licenses

The most common licensing models discussed in the open source ecosystem are:

• Permissive licenses (e.g., MIT, BSD, Apache 2.0) impose minimal restrictions, generally requiring only attribution and a copy of the license. They allow the software to be incorporated into proprietary products.
• Copyleft licenses (e.g., GPL, LGPL, AGPL) require that modified versions, and in some cases larger works incorporating the licensed software, be distributed under the same license terms when they are conveyed to others. This ensures that downstream recipients retain the same freedoms. The LGPL permits certain forms of linking with proprietary software under conditions specified by the license, while the AGPL extends copyleft obligations to certain software made available for use over a network.
• Proprietary licenses restrict use, modification, and distribution according to terms set by the copyright holder.

1.3 Who Enforces Open Source Licenses?

Not all open source enforcement actions are driven by the same motives. Understanding who is bringing a claim, and why, is essential for assessing the risk and choosing the right response. Enforcement claimants generally fall into three categories:

• Advocacy organizations (such as the Free Software Foundation, Software Freedom Law Center, Software Freedom Conservancy, and gpl-violations.org) pursue compliance as their primary goal. Lawsuits are a last resort. Settlements tend to be quick, public, and focused on bringing the violator into compliance rather than extracting large damages.
• Strategic plaintiffs are typically commercial entities using open source claims as part of a broader legal or competitive strategy. They may seek injunctions, substantial damages, or market disruption, and their settlements tend to be slower and confidential.
• Individual authors may act without organizational backing, sometimes demanding a commercial license fee rather than compliance. As open source becomes more pervasive, some legal commentators have warned that such authors could become "copyright trolls," making submarine copyright claims against companies with inadequate open source compliance controls.

The cases discussed in this article involve all three types of claimants, and the type of claimant often explains why some cases settled quietly with a compliance commitment while others resulted in prolonged litigation and significant damages.

2. Landmark Open Source License Cases

2.1 Welte v. Sitecom Deutschland GmbH (2004, Germany)

This case is widely regarded as the first successful judicial enforcement of the GNU General Public License (GPL). In 2004, Harald Welte, a core developer of the netfilter/iptables project, discovered that Sitecom Deutschland GmbH was distributing a wireless router containing GPL licensed software from the project. Sitecom had failed to comply with key GPL requirements, including providing the corresponding source code and supplying the license information required by the GPL.

Welte sought a preliminary injunction from the District Court of Munich (Landgericht München I) to prevent Sitecom from continuing to distribute the routers until it complied with the GPL. The court granted the injunction in April 2004, and Sitecom appealed the decision.

Preliminary injunction is a temporary court order issued at the beginning of a lawsuit to prevent a party from taking a specific action until the court can make a final determination.

In its written opinion, the Munich court upheld the injunction and treated the GPL as a legally effective copyright license. The court reasoned that the rights to copy, modify, and distribute the software were granted only if the license conditions were satisfied. Because Sitecom had distributed the software without complying with those conditions, it could not rely on the GPL's permissions.

Although the court did not issue a final ruling on every provision of the GPL, the decision provided strong judicial support for the view that key GPL obligations, such as making source code available and preserving required license notices, are legally enforceable under copyright law. The ruling was widely interpreted as confirming that the GPL is a binding and enforceable license under German law.

The case was later settled. Sitecom agreed to comply with the GPL by making the license text available and providing information about access to the corresponding source code. The case became a watershed moment for free and open source software enforcement. It demonstrated that the GPL could be successfully enforced in a European court and helped pave the way for numerous later enforcement actions in Germany and elsewhere in Europe.

2.2 Jacobsen v. Katzer (2008, US Federal Circuit)

This is widely regarded as the most important landmark case in open source licensing law in the US. Robert Jacobsen maintained an open source model train software project called JMRI, licensed under the Artistic License. Matthew Katzer and his company KAM Industries incorporated Jacobsen's code into a commercial product without complying with the license conditions, which included requirements to identify the source of the code, to make the original author's name visible, and to indicate how the modified files differed from the original. The district court initially ruled that the Artistic License was a non-exclusive license and that violations could only be addressed as breach of contract, not copyright infringement. This meant Jacobsen could not seek injunctive relief, only monetary damages, which were minimal.

Injunctive relief is a court-ordered remedy that requires a party to stop doing something or to take specific actions to prevent harm.

On appeal, the Federal Circuit reversed this decision in a landmark 2008 ruling, holding that open source license conditions are indeed enforceable copyright conditions, not mere covenants. The court ruled that when a licensee fails to comply with the conditions of an open source license, they lose the right to use, copy, or distribute the software, and their continued use constitutes copyright infringement. This established the fundamental principle that open source licenses are legally enforceable under copyright law, giving licensors the right to seek injunctive relief, which is far more powerful than monetary damages alone. This case fundamentally changed how companies view open source license compliance risk.

2.3 BusyBox GPL Enforcement Lawsuits (2007-2010, USA)

The BusyBox cases were filed by The Software Freedom Law Center (SFLC) in U.S. District Courts and generally settled before judgment.

These cases represent the first GPL enforcement lawsuits filed in the United States. BusyBox is a collection of Unix utilities commonly used in embedded systems, licensed under GPLv2. The SFLC, acting on behalf of BusyBox developers Erik Andersen and Rob Landley, filed the first lawsuit in September 2007 against Monsoon Multimedia. Monsoon had distributed BusyBox code in the firmware of its Hava digital TV product without providing the source code as required by the GPL. The case was settled in October 2007, with Monsoon agreeing to comply with the GPL, appoint an open source compliance officer, and pay an undisclosed sum to the plaintiffs.

This case was followed by additional lawsuits against other companies including Xterasys, High-Gain Antennas, and ultimately fourteen defendants in 2009. In 2010, the Software Freedom Conservancy obtained the first default judgment in a GPL case in the United States, when the court granted an injunction permanently ordering a GPL violator to cease distribution of BusyBox. These cases established that the GPL is enforceable in US courts and that companies cannot simply ignore copyleft obligations in embedded systems. The BusyBox enforcement campaign significantly raised awareness of GPL compliance requirements in the embedded systems industry.

2.4 Free Software Foundation v. Cisco Systems (2008-2009, USA)

In December 2008, the Software Freedom Law Center (SFLC) filed a copyright infringement lawsuit on behalf of the Free Software Foundation (FSF) against Cisco Systems for GPL and LGPL violations in the U.S. District Court for the Southern District of New York. The violations were centered around Cisco's Linksys division, which was distributing products containing GPL-licensed software without providing the corresponding source code. The issue had been known since at least 2003, when hobbyists discovered that the Linksys WRT54G wireless router contained GPL-licensed code, including the Linux kernel and BusyBox. Despite years of discussions, Cisco had failed to achieve full compliance across its product lines.

The case was settled in May 2009, with Cisco agreeing to appoint a director to ensure Linksys products comply with free software licenses, publish source code for all Linksys products that contain GPL-licensed software, and make a monetary payment to the FSF. This case was particularly significant because it involved a major technology company (Cisco had acquired Linksys for $500 million) and demonstrated that even the largest corporations are not immune to GPL enforcement. The settlement also established a compliance model where companies appoint dedicated open source compliance officers, a practice that has since become standard at major technology companies.

2.5 Artifex Software v. Hancom (2016-2017, USA)

Artifex Software, the developer of Ghostscript (a widely-used PostScript and PDF interpreter), sued South Korean company Hancom for using Ghostscript in its Thinkfree Office suite without complying with the GPL or purchasing a commercial license. Ghostscript is dual-licensed: users can either purchase a commercial license or use it under the GPL, which requires that any derivative work also be distributed under the GPL. Hancom distributed Ghostscript as part of its proprietary product without purchasing a commercial license and without complying with the GPL requirements, including failing to include required notices and failing to distribute corresponding source code.

In a significant 2017 ruling, the US District Court for the Northern District of California denied Hancom's motion to dismiss, holding that the GPL is both a license and an enforceable contract. The court found that breach of the GPL can give rise to both copyright infringement claims and breach of contract claims. This dual-enforcement theory means that GPL violators face potential liability under two separate legal theories, significantly increasing the legal risk. The case was eventually settled, but the ruling on the dual nature of the GPL continues to be cited in open source licensing cases.

2.6 Software Freedom Conservancy v. Vizio (2021-present, USA)

In October 2021, the Software Freedom Conservancy (SFC) filed a lawsuit against Vizio Inc., a television manufacturer, for GPL and LGPL violations. Vizio's SmartCast TV products contain software licensed under GPLv2 and LGPLv2.1, including the Linux kernel and other components. Vizio had refused multiple requests to provide the corresponding source code as required by these licenses. What made this case unique is that SFC filed not as a copyright holder but as a third-party beneficiary of the GPL, arguing that anyone who receives GPL-licensed software should have the right to enforce the license's terms. This was a novel legal theory that had not been tested in US courts before.

Vizio attempted to move the case to federal court, arguing it was a copyright matter, but the case was remanded to California state court after the court held that the Copyright Act does not preempt the breach-of-contract claim. In December 2023, the Superior Court of California denied Vizio's motion for summary judgment on the third-party beneficiary issue, finding a triable question on whether SFC is an intended beneficiary of the GPL. The court reasoned that allowing recipients to enforce their right to receive source code is "essential and necessary" to the GPL's objectives, since copyright holders would have no economic incentive to enforce that provision themselves.

In December 2025, the same court granted Vizio's motion for summary adjudication on a narrower sub-issue, ruling that GPLv2 and LGPLv2.1 do not require manufacturers to let users reinstall modified software on their devices while keeping them functional. The obligation is merely to provide the source code in a form users can obtain and modify for other applications. Notably, this clarification applies only to the version 2 licenses: GPLv3 and LGPLv3 explicitly require distributors to provide installation information for certain user products. The central question, whether SFC can enforce the GPL as a third-party beneficiary, remained unresolved, with the case headed to trial (initially scheduled for January 2026). If SFC prevails on that issue, it would open the door for downstream users and consumers, not just copyright holders, to enforce open source license terms. This would considerably broaden the scope of their enforcement.

2.7 IT Development SAS v. Free Mobile SAS (2019, CJEU)

While not an open source case, this judgment of the Court of Justice of the European Union (CJEU) settled a question central: does breaching a software license expose you merely to contractual remedies, or to the stronger remedies for copyright infringement? IT Development SAS, copyright holder of the ClickOnSite software, alleged that its licensee Free Mobile SAS had modified the source code without authorization. Free Mobile argued this was purely a contractual matter under French law, and the Paris Court of Appeal referred the question to the CJEU, asking whether such unauthorized modification falls under the IP Enforcement Directive (2004/48/EC) and the Software Directive (2009/24/EC), or whether it is merely a matter of contractual liability.

In its December 2019 judgment (Case C-666/18), the CJEU held that unauthorised modification of software by a licensee constitutes an infringement of intellectual property rights, not merely a breach of contract. Since the Software Directive (2009/24/EC) reserves the right to authorize modifications exclusively to the copyright holder, a single act can be both a breach of contract and an IP infringement, allowing the rights holder to invoke the stronger enforcement mechanisms of Directive 2004/48/EC (injunctions, damages, evidence-gathering). This mirrors Jacobsen v. Katzer (Section 2.2) and set the stage for Entr'Ouvert v. Orange (Section 2.8): under EU law, violating license conditions is a copyright matter, not just a contractual one.

2.8 Entr'Ouvert v. Orange S.A. (2011-2024, France)

This French case pits Entr'Ouvert, a small company that develops Lasso, a free SAML authentication library dual-licensed under either the GNU GPL or a commercial licence, against Orange S.A. (formerly France Telecom). After a State tender, Orange integrated Lasso into its Identity Management Platform and sold the solution to the French State under its own terms, without complying with the GPL. Entr'Ouvert sued for both copyright infringement and parasitism (unfair free-riding on another company's investments). The dispute ran for over a decade around one central question: does violating the GPL amount, under French law, to copyright infringement or to breach of contract? The available remedies differed sharply depending on the answer.

After a first-instance judgment in June 2019, the Paris Court of Appeal held in March 2021 that the infringement claim was inadmissible: under the French principle of non-cumulation of liabilities, breaching licence terms could only be pursued as contractual liability, not as infringement, which is tortious in nature. It nonetheless ordered Orange to pay €150,000 for parasitism, since the company had exploited Entr'Ouvert's know-how and investments to win a major contract without any compensation.

In its judgment of 5 October 2022, the Cour de cassation partially reversed that decision. It upheld the parasitism award, quantifying the loss being a matter for the trial judges' discretion, but quashed the ruling that the infringement claim was inadmissible. Relying on IT Development SAS v. Free Mobile SAS (Section 2.7) and on Directives 2004/48/EC and 2009/24/EC, it held that breaching a licence clause constitutes an infringement of intellectual property rights. The rights holder must therefore have access to the guarantees of EU law, such as the saisie-contrefaçon seizure procedure and the specific rules for assessing damages, which a contractual claim does not offer. Non-cumulation is thus no bar to an infringement action, and the case was remanded to the Court of Appeal.

Ruling on remand after cassation, the Court of Appeal issued a landmark decision in February 2024 finding that Orange had infringed Entr'Ouvert's copyright in Lasso and violated the GPL. It awarded roughly €860,000: €500,000 in compensatory damages, €150,000 in moral damages, €150,000 in disgorgement of Orange's profits, and €60,000 for legal costs. This is one of the largest awards ever in an open source license enforcement case, and it shows that GPL violations can be very expensive.

2.9 Sebastian Steck (and SFC) v. AVM (2023-2025, Germany)

In 2023, German software developer Sebastian Steck, with funding and support from the Software Freedom Conservancy, sued AVM, a Berlin-based manufacturer of networking equipment (primarily the popular FritzBox routers). Steck's complaint was that AVM failed to provide complete corresponding source code for LGPL-licensed components used in its products, as required by the LGPL. Specifically, the scripts and details for cross-compilation and installation onto the device were missing. Steck argued that the right to modify and reinstall modified software on devices you own is a fundamental right granted by the LGPL, and AVM's incomplete source code distribution effectively prevented users from exercising this right.

The lawsuit concluded in January 2025 with AVM delivering the necessary information to reinstall modified software on their devices. While the financial penalty was nominal, the case is significant for several reasons: it is one of the first LGPL enforcement cases to focus specifically on the right to reinstall modified software (the 'installation information' requirement of the LGPL), it was brought by an individual user rather than a copyright holder, and it resulted in a practical outcome that benefits all users of AVM devices. The case was celebrated by the SFC as a victory for the 'right to repair' in the context of open source software, and it reinforces that companies must provide not just source code, but also the build scripts, toolchain information, and installation procedures necessary for users to actually use the modified software.

2.10 GlobaLeaks AGPL Enforcement (Italy, 2020)

GlobaLeaks is an AGPLv3+ whistleblowing platform developed by the Hermes Center for Transparency and Digital Human Rights. After receiving a prototype, ANAC (the Italian National Anti-Corruption Authority) re-published a modified version of the software under the name "OpenWhistleblowing" and re-licensed it from AGPLv3 to the EUPL, modifying attribution and copyright statements, removing reasonable notices from the GUI, and failing to fully comply with source code availability obligations. The AGPL's copyleft provisions require that derivative works be distributed under the same license, making this re-licensing to the incompatible EUPL a violation of the AGPL's terms.

The case was settled in an Italian court by mutual agreement, establishing what is believed to be the first AGPL compliance precedent in any court. This is significant because the AGPL is considered one of the most restrictive open source licenses and is the license that most directly addresses the 'SaaS loophole' in the GPL. While the GPL requires source code distribution only when binaries are distributed, the AGPL requires it even when the software is merely used to provide a network service. This case confirms that the AGPL's network use provisions are enforceable and that companies offering SaaS products built on AGPL-licensed code must comply with its terms or face legal consequences.

3. License Changes Triggered by Corporate Exploitation

It's possible that software creators change a project's license from version to version. Such changes can reshape the legal landscape, affecting how code may be used, distributed, and combined with other software. The following cases demonstrate that it's crucial for developers to watch for potential license updates to libraries and tools already integrated into their software.

3.1 Elastic v. Amazon (AWS) - Elasticsearch Trademark and License Dispute (2021-2022)

While not strictly a license infringement case in the traditional sense, the Elastic v. Amazon dispute is one of the most significant cases illustrating how large companies can exploit permissive open source licenses, and how the original developers respond. Elasticsearch and Kibana were originally licensed under the Apache 2.0 license (open source). Amazon Web Services (AWS) took the open source Elasticsearch and Kibana code and began offering it as a managed service (Amazon Elasticsearch Service) without contributing back to the project or sharing revenue with Elastic. AWS also used the "Elasticsearch" trademark in their service name, leading to trademark infringement claims.

In response, Elastic changed the license of Elasticsearch and Kibana from Apache 2.0 to a dual-license model using the Server Side Public License (SSPL) and the Elastic License, neither of which is considered open source by the Open Source Initiative (OSI). This triggered a massive community fork, with AWS and other companies creating OpenSearch, a fork of Elasticsearch under the Apache 2.0 license. Elastic also filed a trademark infringement lawsuit against AWS for using the Elasticsearch name. In February 2022, the parties reached an agreement, with AWS agreeing to stop using the Elasticsearch trademark and renaming its service. This case illustrates the broader trend of open source projects changing their licenses to protect against exploitation by cloud providers, and the complex legal issues that arise when commercial interests collide with open source principles.

3.2 Redis Labs and the Commons Clause (2018-2019)

Redis Labs, the company behind the popular in-memory data store Redis, faced a situation similar to Elastic's. While Redis core remained under the BSD license, Redis Labs had developed additional modules under the AGPL. AWS and other cloud providers began offering these modules as managed services, essentially competing with Redis Labs' own cloud offering without contributing back. In 2018, Redis Labs added the Commons Clause to its modules, a license modifier that prohibits selling the software as a service without a commercial license. This effectively made these modules source-available rather than open source.

The Commons Clause was highly controversial in the open source community. The Open Source Initiative (OSI) explicitly stated that software under the Commons Clause does not qualify as open source. In 2019, Redis Labs replaced the Commons Clause with the Redis Source Available License (RSAL), and later the SSPL was also used. In March 2024, Redis Ltd. (the successor company) changed the license of Redis itself from BSD to dual-license under RSALv2 and SSPLv1, causing major disruption in the ecosystem, with several major Linux distributions and cloud providers creating forks. This case demonstrates how license disputes between original developers and cloud providers can escalate from module-level changes to fundamental changes in the core project's license.

4. Python Package License Issues

While there are fewer court cases specifically involving Python packages (compared to embedded systems where GPL enforcement is more common), the Python ecosystem faces significant license compliance risks. Research by Snyk found that over 13% of Python packages on the official public repository PyPI, are distributed without any license at all, which under copyright law means they cannot legally be used, modified, or distributed without explicit permission from the author. The risk is particularly acute because Python's package management system (pip) makes it trivially easy to install and redistribute packages without ever examining their license terms. The following cases and incidents illustrate the legal risks in the Python ecosystem.

4.1 Tencent Accused of GPL Violation via Python Package (2024)

In a notable case reported by Socket.dev, a developer accused Tencent, one of the world's largest technology companies, of violating the GPL by modifying a Python utility and changing its license from GPLv3 to BSD 3-Clause. The GPL explicitly prohibits relicensing: you may modify and distribute GPL-licensed software, but you must distribute your modifications under the same GPL license and you must preserve the original copyright notices. Tencent's QT4A (Quality Test Framework for Android) project on GitHub was found to contain code from a GPLv3-licensed Python utility, but the project had changed the license to BSD 3-Clause and removed the original copyright notices.

The issue was raised on GitHub (Tencent/QT4A issue #132), where the original developer pointed out that "The GPLv3 does not permit you to change the license to BSD 3-Clause. And requires you to keep my original copyright notices -- which have been removed." This case highlights a common misunderstanding: that you can simply relicense GPL code if you modify it. In fact, the GPL's copyleft provisions specifically prevent this, and doing so constitutes both copyright infringement and a breach of the GPL. While this particular case was resolved through community pressure rather than litigation, it demonstrates that even major technology companies can make serious license compliance errors with Python packages, and that individual developers can and do enforce their GPL rights.

4.2 GPL Python Packages in Commercial Products - The Hidden Risk

Python's vibrant package ecosystem offers developers a wealth of ready-made tools, yet it also conceals a frequently underestimated legal hazard: the inadvertent inclusion of GPL-licensed dependencies in proprietary products. Install a package via pip or list it in requirements.txt, and you may unknowingly bind your entire codebase to the GNU General Public License's strict copyleft terms. Under the GPL, incorporating GPL-licensed code generally requires that the entire "combined work" be released under the same license, potentially forcing you to publish your proprietary source code.

The legal uncertainty around Python deepens the danger. While the Free Software Foundation maintains that dynamic linking creates a derivative work, others argue that Python's interpreted, import-based architecture blurs the line, because modules remain distinct files loaded at runtime rather than being statically fused into a single binary. Nevertheless, ambiguity is cold comfort when a legal team identifies a violation. In one widely cited incident, a company using an AGPL-licensed dependency faced an ultimatum: open-source its proprietary recommendation engine or remove the library. The engineering team opted to rewrite the feature from scratch, an expensive, time-consuming retreat driven by legal exposure rather than technical failure.

The financial impact can be severe. According to a Medium report, one SaaS company discovered it had been using an AGPL-licensed library incorrectly and was forced to redo six months of development. The rewrite cost approximately $300,000 in engineering hours and delayed the product launch by three months. Beyond direct costs, these episodes erode trust with customers and investors who expect predictable release schedules.

Because the risk often materializes long after the original dependency decision, proactive auditing is essential. Tools such as pip-licenses, pip-license-checker, and similar scanners allow developers to surface license obligations before they metastasize into legal crises. Treating dependency licensing as a first-class concern, rather than an afterthought, can spare teams from the painful choice between surrendering intellectual property and rebuilding functionality they already thought was finished.

5. Node.js / npm Package License Issues

The npm ecosystem is the largest software registry in the world, with over 2 million packages. This vast ecosystem presents unique license compliance challenges: the deep dependency trees mean that a single npm install can pull in hundreds of packages, many with different and sometimes incompatible licenses.

Research on npm dependency license violations has increased recently, with studies showing that while very few npm packages have direct dependency-related license violations, these violations can propagate widely through the dependency graph.

5.1 npm Dependency License Violations - The Systemic Risk

A study published in the Journal of Information Processing titled Empirical Study on Dependency-related License Violation in the JavaScript Package Ecosystem found that while only 0.644% of npm packages have direct dependency-related license violations, the propagation effect means that a significant number of packages are indirectly affected. The most common violation patterns include: permissively-licensed packages that depend on GPL-licensed packages (creating a license incompatibility), packages with no license that depend on copyleft packages, and proprietary packages that include open source dependencies without complying with their license terms. The study noted that including the packages that depend on those with violations, the percentage of affected packages increases significantly.

A particularly dangerous pattern in the npm ecosystem involves packages that are dual-licensed under both a permissive license (like BSD-3-Clause) and a copyleft license (like GPL-2.0). For example, the extremely popular npm package node-forge that provides a pure‑JavaScript cryptography toolkit is dual-licensed under BSD-3-Clause and GPL-2.0. While the permissive license allows proprietary use, the GPL option also exists, and if a downstream user is not careful about which license they are operating under, they could inadvertently trigger GPL obligations. Additionally, the npm default of using 'ISC' as the license in package.json when none is specified has been criticized as dangerous, as it may lead developers to believe their code is under a permissive license when the author intended no license at all. Tools that help developers audit their npm dependency trees for license compliance have become essential for avoiding these pitfalls.

5.2 The brepjs-opencascade Case in 2026 - The Hidden License in the Dependency Tree

The brepjs-opencascade incident illustrates a silent compliance trap that lurks throughout modern software development. The package advertised MIT in its package.json, yet the precompiled WASM binaries it shipped were built from OpenCascade.js, licensed under LGPL-2.1, with no LICENSE file, no NOTICE, and no disclosure anywhere in the package. The timeline makes the danger concrete: the package launched claiming MIT, developers installed it in good faith, and it was only when an external contributor filed Issue #238 in February 2026 that the mismatch came to light.

The maintainer responded by merging PR #257, correcting the sub-package license from MIT to LGPL-2.1-only and adding proper LICENSE and NOTICE files, while the root brepjs library, which does not bundle the WASM directly, remained Apache 2.0 throughout. Every developer who had installed the package in the window between release and that fix was unknowingly distributing LGPL code and incurring obligations they had no idea existed. This is exactly why trusting the top-level label of a package is not enough: a dependency's package.json can claim MIT while its compiled artifacts carry copyleft obligations two or three layers deep. Before adopting any library, especially one that ships precompiled binaries, developers must audit the full transitive dependency tree and verify that what a package claims matches what it actually distributes.

6. Docker License Issues

Docker is a platform that packages apps and their dependencies into portable containers. It's widely adopted for faster deployments, easier scaling, and improved resource efficiency. Docker presents a unique category of license compliance risk because it involves both open source software (the Docker Engine/Moby is open source) and proprietary software (Docker Desktop), as well as the licensing of container images themselves. The most significant legal development has been Docker Inc.'s decision to change the licensing terms for Docker Desktop, which has created compliance challenges for enterprises.

6.1 Docker Desktop License Change (August 2021)

On August 31, 2021, Docker Inc. announced a fundamental change to its subscription terms: Docker Desktop would no longer be free for enterprise users. Specifically, organizations with more than 250 employees OR more than $10 million in annual revenue would require a paid Docker Desktop subscription to continue using the software. The change came with a grace period until January 31, 2022. This was not a change to the open source components of Docker. The Docker Engine (now Moby) remains open source. Rather, Docker Desktop, which includes the proprietary Docker Desktop application that wraps the open source engine with a GUI and integrations for macOS and Windows, became a paid product for enterprise use.

The license change created immediate compliance concerns for many companies. As reported by ServeTheHome, Docker "abruptly starts charging many users by making them non-compliant with license terms effective immediately." Many organizations had been using Docker Desktop without a paid subscription and suddenly found themselves in violation of the updated terms. While no public lawsuits have been filed over Docker Desktop license violations, the risk is real: Docker's Subscription Service Agreement includes audit rights to "audit usage patterns and to determine whether any use under the Personal Service Subscriptions is allowed and to require migration to an appropriate paid Subscription upon notice." The situation has led many enterprises to migrate to alternatives like Podman, Rancher Desktop, and Colima, or to use the Docker Engine directly on Linux (where Docker Desktop is not required).

It is important to understand the distinction: the Docker Engine on Linux remains free and open source. Docker Desktop is the proprietary application for macOS and Windows that provides a convenient GUI and integration with the host operating system. The license change only applies to Docker Desktop, not to the Docker Engine itself. However, because Docker Desktop is the primary way most developers interact with Docker on macOS and Windows, the change affected a large number of organizations. Companies that continue to use Docker Desktop without a proper subscription are in violation of Docker's terms of service, which could expose them to legal action including breach of contract claims and copyright infringement.

6.2 Docker Image License Compliance - A Hidden Risk

Beyond Docker Desktop licensing, there is a separate and often overlooked compliance risk in the software contained inside Docker images. When you build and distribute an image, you create a composite work incorporating every package installed in it: base OS, dependencies, and their transitive dependencies. The effective license of an image is governed by the strongest license among all included software, and the most dangerous combination is GPL software bundled alongside proprietary code. The obligation is triggered by distribution: anything pushed to Docker Hub is legally being distributed and must comply with all respective license requirements, yet Docker Hub itself explicitly places the compliance burden on the image user, not the registry.

The scale of non-compliance is alarming. A research paper that studied 776 Docker images found that:

• Package-level prevalence: Among the 2,167 software packages identified across all images, 71.3% were GPL-compatible, but a significant 28.7% (621 packages) were GPL-incompatible. The most common incompatible license was Apache v2, followed by BSD4 and MPL v1.1.

• Image-level problems: A striking 58.9% (457 out of 776) of all Docker images contained at least one GPL-incompatibility issue. Even more concerning, 76.3% (119 out of 156) of the official Docker images (widely reused as base layers) had such problems. The most frequently occurring incompatible combination was GPL v2+ alongside BSD4.

Dirk Hohndel, a prominent figure in the open source community, highlighted how container images often include far more software than developers expect. For example, he found 650 packages in an uncomplicated three‑tier application image, and he warned that this hidden complexity creates significant license‑compliance challenges.

A real-world flashpoint came in 2015, when Matthew Garrett, a free software activist and programmer and a major contributor to a series of free software projects including Linux kernel and a variety of Linux distributions, argued that distributing any modified Ubuntu-based Docker image without Canonical's explicit permission violated their IP policy. Canonical, the creator of Ubuntu, responded informally but issued no binding clarification, leaving thousands of Docker Hub images in legal grey territory. While no Docker-specific case law exists yet, a reported 2011 Berlin court ruling found that router firmware triggers GPL copyleft as a collective work is the closest precedent.

Docker Hub's terms of service also impose additional requirements. In 2022, Docker introduced rate limits on image pulls and began enforcing its terms more strictly, including requiring that organizations with large-scale usage obtain a Docker Business subscription. Docker Hub also includes images under various licenses, and using these images without complying with their license terms can create legal liability. The combination of Docker's own licensing terms and the licenses of the software within images creates a layered compliance challenge that many organizations fail to address comprehensively.

7. N8N License Issues

N8N is a workflow automation tool that has gained a lot of popularity after it integrated AI capabilities. It presents a particularly interesting license compliance case. N8N is licensed under the Sustainable Use License (SUL), a "fair-code" license that is not considered an open-source license. The SUL's text restricts use to "internal business purposes" or non-commercial/personal use, and only permits free distribution for non-commercial purposes. In its own FAQ on the license, N8N clarifies that in practice this means all use is allowed unless you are selling a product, service, or module whose value derives entirely or substantially from N8N functionality, for example, white-labeling N8N or hosting it as a paid service to customers. This means that if you were to self-host N8N and offer it as a managed workflow automation service to your customers, you would be in violation of the Sustainable Use License.

7.1 N8N's License Evolution and Compliance Concerns

N8N was originally released under the Apache 2.0 license with the Commons Clause, which restricted commercial use and also inadvertently restricted consulting and support services. On 17 March 2022, N8N switched to the SUL, a custom license created by N8N and based on the Elastic License 2.0 with Elastic's permission. The "fair-code" model was conceived by N8N's own founder, Jan Oberhauser, who runs faircode.io. The key restriction in the SUL is that it prohibits use where "the value derives entirely or substantially from N8N functionality", which is broader than simply prohibiting direct competition. The license also distinguishes between the core N8N software (covered by the SUL) and ee (enterprise edition) files, which are covered by a separate proprietary license.

The compliance challenge with N8N's license is that the boundary between "internal business purposes" and restricted commercial use is not always clear. For example, if a company uses N8N internally to automate workflows but also sells workflow automation consulting services, does that constitute a violation? What about a company that hosts N8N for its clients but does not charge specifically for the N8N service? The N8N community forums contain numerous threads from developers and companies seeking clarification on these boundary cases, indicating that the license terms create significant uncertainty for commercial users.

While there have been no publicly reported lawsuits involving N8N's SUL, the risk is real. Software license terms are legally enforceable: as the case law discussed in this article, courts in different countries have upheld software license terms and imposed real consequences on violators. The fair-code movement, which includes N8N and other "source available" projects, represents a growing category of license compliance risk for developers who may assume that all software on GitHub is open source and freely usable. Developers and companies using N8N should carefully review the SUL and, if they are offering any kind of workflow automation as a service, consider whether their use might fall under the restricted commercial uses.

What I personally found particularly concerning on the N8N community forums is that the N8N founder is routinely answering users' questions about what they can or cannot do with N8N under the SUL. From a legal point of view, those responses cannot constitute an official interpretation of the license even if they come from its original drafter. If a person's use of N8N later turns out to violate the SUL, they cannot rely on those forum replies for legal protection, since the license text itself, as a court might interpret it, remains the only source of truth.

8. Key Takeaways for Companies and Developers

8.1 Open Source Does Not Mean License-Free

The most fundamental lesson from these cases is that open source licenses are legally binding and enforceable. Courts in France, Germany, Italy and the United States have all confirmed that violating the terms of an open source license constitutes copyright infringement and/or breach of contract. Developers and companies who treat open source software as free for any use without reading the license are exposing themselves to significant legal risk, including injunctions, substantial damages, and forced source code releases.

8.2 Copyleft Licenses Require Active Compliance

The GPL, LGPL, and AGPL all impose specific obligations on those who distribute software that incorporates GPL-licensed code. These obligations include providing the corresponding source code, preserving copyright notices, and (for the AGPL) making source code available to users who interact with the software over a network. Compliance is not passive. It requires active steps such as maintaining a written offer for source code, including appropriate license notices, and ensuring that build scripts and installation information are provided. The Steck v. AVM case demonstrates that providing source code alone is insufficient if users cannot actually build and install the software.

8.3 Package Ecosystems Create Hidden Risks

The Python (pip) and Node.js (npm) ecosystems make it extremely easy to pull in hundreds of dependencies with a single command, but each dependency carries its own license. Studies have shown that a significant percentage of packages have no license at all (over 13% on PyPI), and that dependency-related license violations exist in both ecosystems. Developers should use license auditing tools (pip-licenses, Snyk, Socket.dev) to regularly scan their dependency trees, and organizations should implement license compliance policies that review all new dependencies before they are added to a project.

8.4 Source-Available and Fair-Code Licenses Are Not Open Source

Docker Desktop's subscription terms, N8N's Sustainable Use License, and similar "fair-code" or "source-available" licenses are not approved by the Open Source Initiative and contain restrictions that go beyond what open source licenses permit. Using software under these licenses in ways that violate their restrictions (such as using Docker Desktop in a large enterprise without a subscription, or offering N8N as a competing service) can expose you to legal liability just as violating an open source license can. Developers must read and understand the actual license terms of every piece of software they use, rather than assuming that anything available on GitHub is freely usable.

8.5 Enforcement Is Becoming More Common and More Effective

The trend in open-source licence enforcement is clearly towards more frequent and effective enforcement. The early cases, such as BusyBox, were groundbreaking because they established the enforceability of the GPL. The list of companies found to have violated the GPL extends well beyond the cases detailed in this article. Rishab Aiyer Ghosh reported in his article published in the The WIPO Journal, that Fujitsu-Siemens, Asus, Belkin, Samsung, Best Buy, Verizon Communications, and Dell, among hundreds of others were found to be in violation of these licences. The enforcement project gpl-violations.org founded by Harald Welte after his Sitecom case, has pursued or documented violations by companies including tech giants. More recent cases, such as Entr'Ouvert v. Orange, which resulted in an €860,000 award, and SFC v. Vizio, which expanded the scope of GPL enforcement, demonstrate that the consequences of violations are becoming more severe, and that the pool of potential enforcers is growing. Additionally, the GlobaLeaks case in Italy demonstrates that the AGPL, which many companies consider too risky to use and too difficult to enforce, can in fact be enforced in court. These trends suggest that licence compliance will only become more important over time and that developers and companies who ignore their open-source licence obligations do so at increasing legal peril.

---

Sources

1. The GPL prevails: An analysis of the first-ever Court decision on the validity and effectivity of the GPL, SCRIPT-ed, Volume 1, Issue 4,December 2004 https://journals.ed.ac.uk/script-ed/article/view/11054

2. Open Source and the Age of Enforcement, UC Law Science and Technology Journal, Volume 4, Number 2 Summer 2012 https://repository.uclawsf.edu/hastings_science_technology_law_journal/vol4/iss2/5/

3. Open Source Software: Economics, Innovation, Law and Policy, The WIPO Journal, Volume 2 Issue 1 2010 https://tind.wipo.int/record/28665/files/wipo_journal_2_1.pdf

4. Berne Convention for the Protection of Literary and Artistic Works https://www.wipo.int/en/web/treaties/ip/berne/index

5. Neo4j, Inc. v. PureThink, LLC: Court ruling https://law.justia.com/cases/federal/district-courts/california/candce/5

   /335295/216/

6. The Open Source Definition by the OSI https://opensource.org/osd

7. Welte v. Sitecom: District Court of Munich judgment (GPL) https://www.ifross.org/Fremdartikel/judgment_dc_munich_gpl.pdf

8. Jacobsen v. Katzer: Federal Circuit ruling (2008) https://www.cafc.uscourts.gov/opinions-orders/08-1001.pdf

9. BusyBox v. Monsoon Multimedia: SFLC announcement (2007) https://softwarefreedom.org/news/2007/oct/30/busybox-monsoon-settlement/

10. BusyBox additional lawsuits: SFLC announcement (2007) https://softwarefreedom.org/news/2007/nov/20/busybox/

11. BusyBox first default judgment in a GPL case: SFC (2010) https://sfconservancy.org/news/2010/aug/03/busybox-gpl/

12. Software Freedom Law Center (SFLC) https://softwarefreedom.org/

13. FSF v. Cisco Systems: SFLC lawsuit announcement (2008) https://softwarefreedom.org/news/2008/dec/11/cisco-lawsuit/

14. Free Software Foundation (FSF) https://www.fsf.org/

15. FSF v. Cisco Systems: Settlement announcement (2009) https://softwarefreedom.org/news/2009/may/20/fsf-cisco-settlement/

16. Artifex Software v. Hancom: Court ruling (2017) https://dockets.justia.com/docket/california/candce/3

    /305835

17. Artifex and Hancom reach settlement: Artifex blog https://artifex.com/blog/artifex-and-hancom-reach-settlement-over-ghostscript-open-source-dispute

18. Software Freedom Conservancy: Past lawsuits https://sfconservancy.org/copyleft-compliance/past-lawsuits.html

19. SFC v. Vizio: Lawsuit page https://sfconservancy.org/copyleft-compliance/vizio.html

20. Entr'Ouvert v. Orange S.A.: Paris Court of Appeal ruling (2024) https://www.courdecassation.fr/decision/65cdbcdf2425a70008258563

21. Sebastian Steck v. AVM: SFC lawsuit page https://sfconservancy.org/copyleft-compliance/avm.html

22. SFC celebrates AVM copyleft lawsuit resolution (2025) https://sfconservancy.org/news/2025/jan/09/avm-copyleft-lawsuit-resolved-with-install/

23. GlobaLeaks AGPL Enforcement: Joint Statement ANAC-Hermes Center (in Italian) https://pre.anticorruzione.it/documents/90592/96571/comunicato+congiunto+ANAC-HERMES+CENTER.pdf/015de9f3-fdc3-f35e-95e6-456cbbe63989

24. First AGPL compliance precedent: Calendify session https://calendify.com/session/EQVO23WBMkZ?theme=dark

25. Elastic and Amazon reach agreement on trademark infringement lawsuit: BusinessWire (2022) https://www.businesswire.com/news/home/20220216006113/en/Elastic-and-Amazon-Reach-Agreement-on-Trademark-Infringement-Lawsuit

26. Redis Labs modules license changes: Redis blog https://redis.io/blog/redis-labs-modules-license-changes/

27. Over 10% of Python packages on PyPI are distributed without any license: Snyk https://snyk.io/blog/over-10-of-python-packages-on-pypi-are-distributed-without-any-license/

28. PyPI: Python Package Index https://pypi.org/

29. Developer accuses Tencent of copyright violation: Socket.dev https://socket.dev/blog/developer-accuses-tencent-of-copyright-violation

30. Tencent/QT4A issue #132: GitHub https://github.com/Tencent/QT4A/issues/132

31. The Open Source License That's Quietly Bankrupting Companies: Medium https://medium.com/@sohail_saifi/the-open-source-license-thats-quietly-bankrupting-companies-1ab583f853be

32. Empirical Study on Dependency-related License Violations in the JavaScript Package Ecosystem: Journal of Information Processing https://www.jstage.jst.go.jp/article/ipsjjip/29/0/29_296/_article/-char/en

33. node-forge: npm package https://www.npmjs.com/package/node-forge

34. brepjs Issue #238: GitHub https://github.com/andymai/brepjs/issues/238

35. brepjs PR #257: GitHub https://github.com/andymai/brepjs/pull/257

36. Docker updates product subscriptions: Press release (2021) https://www.docker.com/press-release/docker-updates-product-subscriptions/

37. Docker abruptly starts charging many users for Docker Desktop: ServeTheHome https://www.servethehome.com/docker-abruptly-starts-charging-many-users-for-docker-desktop/

38. Docker Subscription Service Agreement https://www.docker.com/legal/docker-subscription-service-agreement/

39. TL;DR: Docker and legal compliance: Alfresco blog https://hub.alfresco.com/t5/alfresco-content-services-blog/tldr-docker-and-legal-compliance/ba-p/315453

40. Containers and open source license compliance: FOSSA blog https://fossa.com/blog/containers-open-source-license-compliance/

41. Ubuntu: Docker Hub official image https://hub.docker.com/_/ubuntu

42. Research paper on Docker image license compliance: IEEE https://ieeexplore.ieee.org/document/9825809

43. Container images often include far more software than developers expect: LWN.net https://lwn.net/Articles/752982/

44. Matthew Garrett says Ubuntu container images are breaking copyright: Softpedia https://news.softpedia.com/news/gnome-s-matthew-garrett-says-ubuntu-container-images-are-breaking-copyright-probably-487418.shtml

45. Canonical says Ubuntu-based Docker images are not a copyright violation: Softpedia https://news.softpedia.com/news/canonical-says-ubuntu-based-docker-images-is-not-a-copyright-violation-488038.shtml

46. AVM GPL violation: FSFE https://fsfe.org/activities/avm-gpl-violation/avm-gpl-violation.en.html

47. Docker Terms of Service https://www.docker.com/legal/docker-terms-service/

48. N8N Sustainable Use License: FAQ

    https://docs.n8n.io/sustainable-use-license/

49. Announcing the new Sustainable Use License: N8N blog https://blog.n8n.io/announcing-new-sustainable-use-license/

50. FairCode https://faircode.io/

51. N8N enterprise edition license: GitHub https://github.com/n8n-io/n8n/blob/master/LICENSE.md

52. N8N community forums: A new license for n8n

    https://community.n8n.io/t/a-new-license-for-n8n/11873

53. N8N community forums: Founder's response on license usage https://community.n8n.io/t/a-new-license-for-n8n/11873/4

54. gpl-violations.org https://gpl-violations.org/

55. SFC v. Vizio survives motion for summary judgment on third-party beneficiary issue: DLA Piper https://www.dlapiper.com/en-fr/insights/publications/2024/01/sfc-v-vizio-survives-motion-for-summary-judgment-on-third-party-beneficiary-issue

56. SFC v. Vizio ruling on General Public License compliance: Key takeaways: DLA Piper https://www.dlapiper.com/en-fr/insights/publications/2026/01/sfc-v-vizio-ruling-on-general-public-license-compliance-key-takeaways

57. IT Development SAS v. Free Mobile SAS (Case C-666/18): CJEU judgment, EUR-Lex (2019) https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX

58. Entr'Ouvert v. Orange S.A.: Cour de cassation, First Civil Chamber, judgment of 5 October 2022 (appeal no. 21-15.386), Légifrance (in French) https://www.legifrance.gouv.fr/juri/id/JURITEXT000046389115