Imagine That IP Law Blog

Introduction: The Paradox of “Free” Software

Open-source software (OSS) is the paradoxical infrastructure of the modern economy. It is frequently “free” in price, yet indispensable in value. Cloud computing, container orchestration, continuous integration pipelines, and AI development environments are routinely built on OSS stacks such as Kubernetes and Docker. The economic consequence is straightforward. OSS compresses development timelines, reduces vendor lock-in, and enables companies to scale products without recreating foundational tooling. That same ubiquity, however, can obscure a second-order reality. OSS adoption can concentrate legal exposure precisely because the most widely used components are also the most scrutinized.

Practitioners often describe OSS as a “legal minefield.” The metaphor is apt, but incomplete. The risk is not simply that open-source licenses are complicated, though some are. The deeper tension is philosophical and structural. OSS is premised on collaborative sharing and iterative improvement, while patent law is premised on exclusionary rights enforced through infringement remedies. OSS invites broad reuse. Patents police use at the claim level. OSS encourages distribution. Patents attach to making, using, selling, offering for sale, and importing.

This mismatch becomes acute in commercial settings. A company can fully comply with OSS copyright terms and still face third-party patent allegations, because the relevant patent owner may be wholly outside the OSS project and therefore outside any license-based patent grant. The result is an enterprise risk profile that is often underappreciated until a demand letter arrives, at which point the dependency graph, product roadmap, and business model may already be intertwined with a “free” stack that the company cannot easily unwind.

Theoretical Framework: Patents vs. Copyright in OSS

Most OSS compliance programs are optimized for copyright. That focus is rational. Open-source licenses are primarily copyright licenses, and operational compliance, including notice, attribution, source availability, and copyleft triggers, is measurable and repeatable. But copyright compliance does not exhaust the IP analysis in OSS deployments. Patents protect inventions, including methods, systems, and processes, not expression. Patent infringement can occur even where no copying is alleged and no source code is redistributed.

This distinction matters because the act that creates business value, deploying OSS in products or services, often maps more naturally onto patent infringement theories than copyright theories. If an OSS component implements a patented technique, the adopter’s use or sale of a system practicing that technique may create exposure regardless of whether the adopter complied with the applicable copyright license. Put differently, copyright compliance is necessary for lawful OSS use, but it is not sufficient to eliminate patent risk.

This is where the “innocent infringer” myth persists in software organizations. Direct patent infringement is a strict liability offense. A defendant’s knowledge or intent is irrelevant to liability for direct infringement. This has been held and re-affirmed time and time again. In 1964, the Supreme Court first recognized that direct infringement turns on unauthorized practice of the patented invention, not on the defendant’s mental state. Aro Mfg. Co. v. Convertible Top Replacement Co., 377 U.S. 476, 484 (1964). The Court confirmed this again in 2011, explaining that direct infringement does not require knowledge of the patent. Global Tech Appliances, Inc. v. SEB S.A., 563 U.S. 754, 760 n.2 (2011). The Supreme Court reiterated the same strict liability character in Commil USA, LLC v. Cisco Systems, Inc., explaining that, under the patent statute, the mental state of the accused infringer is not an element of direct infringement. (575 U.S. 632, 639 (2015)). This strict-liability posture is precisely why patent assertions can function as leverage events in OSS-heavy environments. The factual predicate can be framed as a claim chart and a deployment story, rather than an inquiry into intent.

None of this is to say OSS is uniquely dangerous. The point is narrower. OSS governance that stops at copyright compliance is structurally incomplete. Patent risk is not eliminated by good-faith adherence to open-source license obligations, and the legal system generally does not reward “we did not know” as a standalone defense to direct infringement.

Deep Dive into Patent License Grants

OSS licenses vary widely in their treatment of patents. That variation is often misunderstood because license discussions are commonly simplified into “permissive licenses versus copyleft,” which are purely copyright concepts. Such distinctions, of course, can leave licensees vulnerable to patent attacks if the practitioner is not careful to parse out a license’s patent terms as well. From a patent perspective, the more useful taxonomy that practitioners need to be aware of is express patent grants, patent-related constraints or anti-discrimination provisions, and “silent” licenses where the patent posture is ambiguous or contested.

A.  Express Contributor Patent Grant (and Its Ceiling): The Apache License 2.0:

While express patent grants can vary, Apache License 2.0 provides a good example for understanding this type of license and is frequently cited for its express patent license in Section 3. Apache’s formulation is conceptually elegant. Each “Contributor” grants downstream recipients a royalty-free patent license covering patent claims “licensable by such Contributor” that are “necessarily infringed” by the Contributor’s contribution alone, or by the contribution combined with the work to which it was submitted. (Apache License, Version 2.0 §3 (Apache Software Found. Jan. 2004). The key limiting phrase, “necessarily infringed by their Contribution(s) alone,” does real work as it is commonly read to narrow the grant to patent claims that are unavoidably practiced when implementing the contribution as submitted, or as integrated with the relevant work. The grant is therefore not a general covenant covering all patents the contributor owns, nor a blanket license for every conceivable downstream configuration. Rather, it is a targeted assurance against a specific scenario. With this type of license, therefore, a contributor cannot inject code and later assert its own patents against adopters for practicing that same contribution.

On the other hand, the Apache patent grant is contributor-bounded. It does not immunize adopters from non-contributor patent holders, meaning the world at large. That limitation is often the dispositive point for enterprise risk. Many meaningful threats come from parties that never touched the repository.

Another important risk consideration in the Apache license is its patent termination mechanism tied to patent litigation alleging that the work or a contribution infringes. (Apache License §3) Patent termination mechanisms, such as in the illustrative Apache license, can constrain a company’s offensive patent posture while remaining dependent on the licensed infrastructure.

B. The Silent Licenses (MIT and BSD): Implied Patent Licenses and Litigation Gray Areas

Permissive licenses, such as the so-called MIT license, are popular precisely because they are short and operationally frictionless. The MIT License, for example, grants broad permission to “use, copy, modify, merge, publish, distribute, sublicense, and or sell copies” of the software, but it does not use the word “patent.” (The MIT License, Open Source Initiative. Whether that broad permission functionally carries an implied patent license is a long-running debate in licensing practice and litigation risk assessment. This issue has not been formally explored by the courts. However, some commentators argue the permission is naturally read to encompass whatever IP rights are necessary to exercise the granted permissions. Others emphasize that the absence of an express patent grant creates uncertainty and therefore bargaining leverage for a patent claimant.

For risk management, the point is not that MIT or BSD licenses are necessarily “bad,” but that silence can translate into gray area, particularly when a contributor later asserts patents, or when a third party asserts patents against widespread adopters. In enterprise counseling, that ambiguity can matter. For due diligence, for example, counsel must advise whether a component’s license posture supplies any meaningful patent comfort. In dispute resolution, for another example, a putative implied-license argument may exist but may not provide the certainty needed to avoid settlement pressure.

The Threat Landscape: PAEs and Competitors

Patent assertions in OSS ecosystems tend to come from two sources: competitors and patent assertion entities (PAEs). Competitors generally assert patents opportunistically when they perceive a strategic advantage or when OSS-based products pressure incumbents. PAEs, by contrast, are economically optimized to monetize patents through licensing demands and litigation.

OSS can be a “soft target” for PAEs for reasons that are less about doctrine and more about mechanics. First, OSS code is public, and claim charting is inherently evidentiary. The ready availability of OSS code, therefore, simplifies the front-end work of mapping claim limitations to an accused implementation. Second, OSS is often deeply embedded. If a foundational OSS component is implicated, the accused party may face substantial switching costs and operational disruption, which increases settlement pressure. Third, “innocent infringement” narratives carry limited weight for liability purposes in direct infringement cases, because intent is not an element of direct infringement.  

Defensive Ecosystems and Strategic Mitigation

Because OSS patent risk is ecosystemic, mitigation is increasingly ecosystemic as well. Three mechanisms are particularly relevant and commonly used to mitigate patent infringement risk associated with OSS licenses: defensive patent pools and non-aggression communities and license-on-transfer (LOT) structures.

A. Patent Pools: The Role of OIN and the “Linux System”

The Open Invention Network (OIN) is an example of a patent non-aggression community through which members agree to cross-license their patents royalty-free to other members. Member commitment is bounded by OIN’s “Linux System” definition. The Linux System is not static. OIN maintains and updates the definition and associated component lists, effectively drawing a perimeter around the OSS stack that members agree not to attack. (Open Invention Network, Linux System Definition & Components (effective Aug. 26, 2024). Membership in patent pools, such as OIN, can have substantial practical value. First, it inherently reduces intra-ecosystem assertion risk among participants for covered components. Second, it has the practical effect of changing the strategic calculus for would-be plaintiffs who are also members, as asserting patents within the defined perimeter can trigger contractual consequences and reputational costs.

B. The LOT Network and Conditional Licenses Triggered by PAE Transfer

LOT is another tool companies can use, alongside patent pools, to reduce infringement risk associated with OSS. While patent pools directly limit risk of patent assertion by other members, the LOT Network is designed to limit risk to operating companies stemming from transfer of operating company patents to PAEs. LOT’s model is that members grant each other a license that springs into effect when a patent is transferred to an “assertion entity.” (LOT Network Inc., LOT Agreement, Version 2.2 (Nov. 17, 2025). LOT membership, thus, can be framed as a targeted hedge against downstream assignment risk. It narrows a category of uncertainty that can arise long after a patent’s original owner exits a market or sells assets.

Commercial Realities: Procurement and Indemnification

OSS risk becomes most acute when it travels down the supply chain. Integrating OSS into proprietary products and services can create downstream liability and customer friction. Customers may demand assurances, including indemnities, that are difficult to provide when the stack includes numerous OSS components maintained by diffuse communities. Even when the company is confident in its engineering and compliance posture, customers often view OSS as an “unknown unknown” unless the company can show inventory, governance process, and contractual allocation of risk.

Procurement can meaningfully shift the risk profile, but only if counsel negotiates with specificity. Commercial distributions and vendors may offer indemnification structures. However, “standard” indemnities frequently carve out claims arising from OSS components, modifications, nonstandard configurations, or combinations with third-party software. The result is a false sense of security. The contract appears to provide comfort, but the carve-outs may exclude the very OSS-driven exposure at issue.

Conclusion: Towards a Proactive IP Strategy

OSS delivers flexibility, scalability, and speed that few proprietary stacks can match. But the benefits outweigh the risks only if the risks are actively managed. The core lesson is structural. OSS copyright compliance is indispensable but incomplete. Patent exposure can attach even where distribution is lawful and good faith is undisputed, and contributor-based patent grants, even when well drafted, do not eliminate third-party assertion risk.

A proactive approach is therefore warranted, one that treats OSS as both a technical, and an IP asset. “Compliance by design” means more than license scanning. It includes patent-aware intake for high-risk components, disciplined component inventories, and escalation paths when critical features implicate crowded patent landscapes. It should also consider ecosystem participation, including OIN and LOT, where appropriate, and realistic procurement strategies that allocate risk through indemnification, support, and contractual remedies.

Reprinted with permission from the February 20, 2026 issue of The Legal Intelligencer ©2026 ALM Media Properties, LLC. Further duplication without permission is prohibited. All rights reserved.