28.5: Patent Risks in Dependencies¶

Disclaimer: This section provides general educational information about patent considerations in software development. It does not constitute legal advice. Organizations should consult qualified intellectual property counsel for guidance on specific patent matters.

When you incorporate an open source dependency into your software, you inherit not only its code but potentially its patent exposure. A dependency implementing a patented algorithm, using a patented technique, or practicing a patented method creates infringement risk that transfers to every downstream user. Unlike copyright—where open source licenses explicitly grant necessary rights—patent rights operate independently, and a license to use code does not automatically include a license to practice any patents that code might infringe.

The scale of modern dependency trees amplifies this risk. A typical application with hundreds of dependencies could theoretically infringe hundreds of patents, held by patent owners who have no relationship to the open source projects involved. While catastrophic patent litigation against open source users has been relatively rare, the risk is real—and the potential consequences of infringement include injunctions, damages, and costly litigation. Understanding patent risks in dependencies, and the protections available, enables organizations to manage this exposure appropriately.

Patent Infringement Through Dependency Usage¶

Patent infringement occurs when someone makes, uses, sells, or imports a patented invention without authorization from the patent holder. Software patents cover methods, processes, and systems—abstract concepts implemented in code. When you use a dependency that implements a patented method, you may be infringing that patent regardless of whether you knew about it or intended to infringe.

How dependency usage creates exposure:

• Direct infringement: Your software practices the patented method through dependency code
• Induced infringement: You distribute software that causes end users to infringe
• Contributory infringement: You provide components knowing they will be used to infringe

The dependency author's infringement does not shield downstream users. If a library implements a patented compression algorithm, every application using that library potentially infringes the patent. The patent holder can pursue any party in the chain—the dependency author, the application developer, or the end user.

Scale of potential exposure:

Modern applications incorporate extensive dependency trees:

• A typical Node.js application may have 500+ dependencies
• Java enterprise applications commonly include 200+ libraries
• Python data science projects routinely incorporate 100+ packages

Each dependency potentially implements techniques covered by patents. The sheer number of dependencies makes comprehensive patent analysis impractical, creating irreducible uncertainty about patent exposure.

Practical limiting factors:

Despite theoretical exposure, several factors limit practical patent risk:

• Detection difficulty: Patent holders must identify infringing implementations
• Enforcement costs: Patent litigation is expensive, limiting pursuit of small targets
• Defensive considerations: Patent holders may face counterclaims
• Public relations: Aggressive enforcement against open source generates backlash

These factors have historically limited, but not eliminated, patent assertions against open source users.

Patent Provisions in Open Source Licenses¶

Many open source licenses include provisions addressing patent rights, though the scope and effectiveness of these provisions vary significantly.

Apache License 2.0 Patent Grant:

The Apache License 2.0 includes an explicit patent grant:

"Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable... patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work."

This grant covers patents that contributors necessarily infringed by their contributions—patents on functionality they added to the code. However, it does not cover:

• Patents held by third parties unrelated to the project
• Patents on functionality implemented before their contribution
• Patents acquired after contribution

GPL v3 Patent Provisions:

The GNU General Public License version 3 includes comprehensive patent provisions:

• Section 11 grants an automatic patent license from each contributor
• The license extends to "essential patent claims"—patents necessarily infringed by the covered work
• The grant is non-exclusive, royalty-free, and worldwide

GPLv3 also addresses patent-related restrictions on redistribution, preventing distributors from imposing patent license fees that would contradict GPL freedoms.

Patent Retaliation Clauses:

Many licenses include patent retaliation provisions that terminate license grants if the licensee initiates patent litigation. Examples:

Apache 2.0: "If You institute patent litigation... alleging that the Work or a Contribution incorporated within the Work constitutes... patent infringement, then any patent licenses granted to You under this License for that Work shall terminate."

GPL v3: Includes provisions addressing patent assertions and defensive termination.

Eclipse Public License: Terminates rights if the licensee asserts patents against the contributor.

These provisions create deterrence—asserting patents against a project may result in losing your license to use that project's software.

MIT and BSD License Limitations:

Permissive licenses like MIT and BSD do not include explicit patent grants. The absence of patent provisions creates uncertainty:

• Some argue an implied patent license exists based on the grant to "use" the software
• Others contend that explicit copyright license without patent mention provides no patent rights
• Case law on implied patent licenses in open source contexts remains limited

Using MIT or BSD-licensed code carries greater patent uncertainty than using code under licenses with explicit patent grants.

Defensive Patent Pools¶

Defensive patent pools aggregate patents held by multiple parties, making them available to members for defensive purposes while pledging not to assert them offensively. The largest such pool in the open source context is the Open Invention Network (OIN).

Open Invention Network:

Founded in 2005 by IBM, Sony, Philips, Red Hat, and Novell (now SUSE), OIN has grown to include over 4,000 members (as of early 2025) and covers patents related to the "Linux System"—a defined set of core open source packages.

OIN membership provides:

• Cross-license: Members receive royalty-free licenses to all OIN community patents for use with the Linux System
• Defensive protection: Members agree not to assert patents against the Linux System
• Community commitment: Demonstrates commitment to open source patent freedom

Membership is free and available to any organization. Members retain their patents and can assert them outside the Linux System definition, but commit to non-assertion within that scope.

OIN Linux System Definition:

OIN protection applies to a defined list of packages constituting the "Linux System." This definition is updated regularly to include additional packages. Core components include:

• Linux kernel
• Major distributions (RHEL, Ubuntu, SUSE, etc.)
• Common utilities and libraries
• Development tools
• Database software

Check the current definition at OIN's website to determine whether specific dependencies receive OIN protection.

Other Defensive Initiatives:

• Unified Patents: Focuses on challenging low-quality patents
• LOT Network: Members commit to license patents defensively if they're transferred to assertion entities
• Google's Open Patent Non-Assertion Pledge: Covers specific Google patents
• Red Hat's Patent Promise: Commits not to assert patents against open source software

These initiatives provide varying degrees of protection for open source users.

Due Diligence for Patent Risk¶

Comprehensive patent due diligence for all dependencies is impractical for most organizations. However, risk-proportionate due diligence can identify and address the highest-risk situations.

Risk factors warranting attention:

• High-value patent areas: Cryptography, video codecs, compression algorithms, certain AI/ML techniques
• Known patent assertions: Technologies with history of patent enforcement
• Standards-essential patents: Technologies implementing standards with FRAND-encumbered patents
• Competitive contexts: Technologies where competitors hold relevant patents

Due diligence approaches:

For critical dependencies:

1. Identify the core technology area (compression, encryption, etc.)
2. Research known patents and patent assertions in that area
3. Evaluate license patent provisions (Apache 2.0, GPL v3, etc.)
4. Check OIN or other defensive pool coverage
5. Consider vendor indemnification availability

For general dependencies:

1. Prefer dependencies with explicit patent grants (Apache 2.0, GPL v3)
2. Note dependencies in high-risk technology areas for closer review
3. Monitor patent litigation news affecting your technology stack
4. Maintain awareness of patent retaliation clauses in your licenses

Technology-specific considerations:

Patent-unencumbered alternatives:

For high-risk technology areas, consider royalty-free alternatives:

• AV1: Royalty-free video codec alternative to H.264/H.265
• Opus: Royalty-free audio codec
• Zstandard: Royalty-free compression with patent grant
• WebM: Royalty-free video format

Selecting unencumbered implementations reduces patent exposure even if you cannot comprehensively analyze all dependencies.

Indemnification and Insurance¶

Vendor indemnification:

Commercial vendors often provide indemnification against intellectual property claims, including patent infringement. When acquiring commercial software (including commercial open source support), evaluate:

• Scope of indemnification: Does it cover patent claims?
• Geographic coverage: Does it apply in relevant jurisdictions?
• Caps and limitations: What monetary limits apply?
• Conditions: What obligations must you fulfill (notification, cooperation)?
• Carve-outs: What situations are excluded?

Commercial open source vendors—Red Hat, Canonical, SUSE, and others—typically include IP indemnification in enterprise subscriptions. This indemnification may extend to the broader open source stack, not just the vendor's specific contributions.

Patent litigation insurance:

Intellectual property insurance can cover patent litigation costs and damages. Types include:

• Defensive coverage: Covers costs of defending against patent claims
• Abatement coverage: Covers costs of design-arounds if infringement is found
• Damages coverage: Covers damages awarded in patent litigation

Insurance considerations:

• Coverage limits should reflect realistic exposure
• Deductibles may be substantial for IP coverage
• Exclusions may limit practical protection
• Premiums depend on technology area and company profile

For organizations with significant software products, IP insurance may provide meaningful protection against patent risk in the dependency chain.

Self-insurance and reserves:

Large technology companies often self-insure patent risk, maintaining reserves and defensive patent portfolios. This approach:

• Requires scale to absorb potential losses
• Benefits from defensive patent holdings enabling counterclaims
• Depends on risk tolerance and financial capacity

Most organizations benefit from combining vendor indemnification, insurance, and risk management rather than self-insurance alone.

Recommendations¶

We recommend organizations manage patent risk in dependencies through:

1. Prefer licenses with patent grants—Apache 2.0 and GPL v3 provide explicit patent licenses; MIT and BSD do not

2. Join OIN if you use substantial open source software—membership is free and provides meaningful protection for Linux System packages

3. Identify high-risk technology areas in your dependency tree (codecs, compression, encryption) for closer attention

4. Seek patent-unencumbered alternatives when available for high-risk technology areas

5. Evaluate vendor indemnification when procuring commercial support for open source software

6. Consider IP insurance for organizations with significant software products and exposure

7. Monitor patent landscape in your technology domain through industry publications and legal alerts

8. Consult IP counsel for specific concerns, particularly when entering high-risk technology areas or facing patent assertions

Patent risk in dependencies cannot be eliminated, but proportionate due diligence and available protections can reduce exposure to manageable levels. Organizations that understand their exposure and implement appropriate protections navigate patent risk more effectively than those that ignore it until litigation arrives.