Software FTO and Open Source Risk

Software FTO requires teams to review both patent risk and open source license obligations before shipping code. Software development has fundamentally changed how companies build products. Open Source Software—code that is freely available and can be modified and distributed—has become ubiquitous. But open source introduces a unique FTO challenge: the intersection of open source licenses and patent rights.

A software product built on open source components may face patent risks that are distinct from traditional FTO concerns. This article explains how open source licenses interact with patents and why software companies must carefully analyze both when conducting FTO analysis.

The Open Source Landscape

What is Open Source Software?

Open source software is software whose source code is publicly available and can be freely used, modified, and distributed, subject to the terms of an open source license.

Common Open Source Licenses

Permissive Licenses (Allow proprietary use):

• MIT License: Minimal restrictions, allows proprietary use
• Apache License 2.0: Allows proprietary use, includes patent grant
• BSD License: Similar to MIT, allows proprietary use

Copyleft Licenses (Require derivative works to be open source):

• GPL (General Public License): Requires derivative works to be open source
• AGPL (Affero GPL): Requires derivative works to be open source, even for network services
• LGPL (Lesser GPL): Weaker copyleft, allows linking with proprietary code

Hybrid Approaches:

• Dual licensing: Software available under multiple licenses
• Proprietary + open source: Some components proprietary, others open source

How Open Source Licenses Address Patents

open source patent search in License Review

Many open source licenses include explicit patent grants—permissions to use patents held by the licensor.

Example: Apache License 2.0:
“Each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright and patent license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.”

What This Means:

• Contributors grant patent licenses to users
• Users can use the software without fear of patent infringement claims from contributors
• The patent grant is perpetual and irrevocable

Patent Grants in GPL

GPL v2 and v3 include patent provisions:

• If a contributor asserts patent claims against GPL users, the contributor’s license is terminated
• This creates a deterrent against patent assertion

Example: GPL v3:
“If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to become publicly available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients.”

What This Means:

• Contributors grant patent licenses to GPL users
• If a contributor asserts patents against GPL users, the patent license is forfeited
• This creates strong protection against patent assertion

Licenses Without Patent Grants

MIT License and BSD License do not include explicit patent grants. This creates potential patent risks.

Example: MIT License:
“Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions…”

What This Means:

• The license grants copyright rights but not explicit patent rights
• Users may face patent claims from the licensor or other patent holders
• Patent risks are not addressed by the license

FTO Risks in Open Source Software

Risk 1: Patent Claims from Open Source Contributors

Scenario: An open source project includes code contributed by multiple developers. One contributor holds a patent that covers the functionality implemented in the code.

Risk: The contributor may assert patent claims against users of the open source software.

Mitigation:

• Use open source licenses with strong patent grants (Apache 2.0, GPL v3)
• Require contributors to grant patent licenses
• Conduct patent searches for open source projects
• Monitor for patent assertions

Risk 2: Patent Claims from Non-Contributors

Scenario: Your software uses open source components. A third party (not a contributor) holds a patent that covers the functionality.

Risk: The third party may assert patent claims against your software.

Mitigation:

• Conduct FTO analysis for open source components
• Identify patents that may cover the functionality
• Assess infringement risk
• Develop mitigation strategies (design-around, licensing, etc.)

Risk 3: software composition analysis

Scenario: Your proprietary software incorporates GPL-licensed open source code.

Risk: GPL requires that derivative works also be open source. Using GPL code in proprietary software may require you to open source your proprietary code.

Mitigation:

• Understand copyleft license obligations
• Use permissive licenses when possible
• Use LGPL instead of GPL if you need to link with proprietary code
• Isolate GPL code in separate modules
• Obtain legal advice on license compliance

Risk 4: license compatibility review

Scenario: Your software combines components licensed under different open source licenses.

Risk: Some license combinations are incompatible, creating legal uncertainty.

Example: GPL and Apache 2.0 are not fully compatible. Combining GPL code with Apache 2.0 code creates legal uncertainty.

Mitigation:

• Understand license compatibility
• Use compatible licenses
• Consult legal counsel on license combinations
• Use license compatibility tools

Conducting FTO Analysis for Open Source Software

Step 1: Identify Open Source Components

Create an inventory:

• List all open source components used in your software
• Document the version of each component
• Document the license of each component
• Document the source of each component

Tools for Identifying Components:

• Software composition analysis (SCA) tools
• Dependency management tools
• Manual code review

Step 2: Analyze License Obligations

For each open source component:

1. Understand the license terms
2. Identify obligations (e.g., attribution, copyleft)
3. Assess whether you can comply with obligations
4. Identify potential conflicts with other licenses

License Analysis Questions:

• Does the license require attribution?
• Does the license require source code disclosure?
• Does the license restrict commercial use?
• Does the license include patent grants?
• Is the license compatible with other licenses in your software?

Step 3: Assess Patent Risks

For each open source component:

1. Identify the patent holder(s)
2. Search for patents held by the patent holder(s)
3. Assess whether patents may cover the functionality
4. Assess infringement risk
5. Assess enforcement likelihood

Patent Risk Assessment Questions:

• Does the open source license include a patent grant?
• Are there patents that may cover the functionality?
• Is the patent holder known for enforcing patents?
• What is the enforcement likelihood?

Step 4: Assess Copyleft Obligations

For GPL and other copyleft licenses:

1. Understand the copyleft requirements
2. Assess whether you can comply
3. Identify potential conflicts with proprietary code
4. Develop mitigation strategies

Copyleft Assessment Questions:

• Does your software include GPL code?
• Are you distributing your software?
• Would GPL require you to open source your proprietary code?
• Can you isolate GPL code to avoid copyleft obligations?

Step 5: Develop Mitigation Strategies

For License Obligations:

• Comply with license terms (attribution, source code disclosure)
• Use permissive licenses instead of copyleft licenses
• Isolate copyleft code in separate modules
• Obtain legal opinions on license compliance

For Patent Risks:

• Use open source licenses with strong patent grants
• Conduct FTO analysis for open source components
• Design around patents if necessary
• Obtain licenses if necessary
• Accept risk if appropriate

Real-World Examples: Open Source and Patents

Example 1: Linux and Patent Risks

Linux is licensed under GPL v2, which includes patent protections. However, Linux has faced patent claims from various patent holders.

Lesson: Even with strong patent protections in the license, patent risks can still exist from third parties.

Example 2: Apache Software Foundation

The Apache Software Foundation uses Apache License 2.0, which includes explicit patent grants. This has made Apache projects attractive to companies concerned about patent risks.

Lesson: Open source licenses with explicit patent grants provide better patent protection.

Example 3: Copyleft Compliance Issues

Companies have faced legal issues when using GPL code in proprietary software without understanding copyleft obligations.

Lesson: Understanding and complying with copyleft obligations is critical.

Best Practices for Open Source FTO Analysis

1. Maintain an Open Source Inventory

Keep a current inventory of all open source components used in your software.

2. Understand License Obligations

Understand the obligations of each open source license used in your software.

3. Use License Compliance Tools

Use software composition analysis tools to identify open source components and assess license compliance.

4. Conduct Patent Analysis

Conduct FTO analysis for open source components, particularly those without strong patent grants.

5. Prefer Permissive Licenses

When possible, use open source components licensed under permissive licenses (Apache 2.0, MIT) rather than copyleft licenses (GPL).

6. Isolate Copyleft Code

If you must use copyleft code, isolate it in separate modules to minimize copyleft obligations.

7. Obtain Legal Opinions

For complex license situations, obtain legal opinions on license compliance and patent risks.

8. Monitor for Updates

Monitor open source projects for license changes, patent assertions, and security issues.

9. Contribute Back

Consider contributing improvements back to open source projects, which can improve your relationship with the community and reduce legal risks.

10. Document Everything

Document your open source usage, license analysis, and patent analysis for future reference.

Open Source License Comparison

Conclusion

Open source software provides tremendous value but introduces unique FTO challenges. By understanding open source licenses, assessing patent risks, and complying with license obligations, software companies can:

• Leverage open source effectively
• Manage patent risks
• Comply with license obligations
• Avoid costly legal disputes

For software companies, open source FTO analysis is as important as traditional patent FTO analysis.

Key Takeaway: Open source software introduces unique FTO challenges related to both licenses and patents. Maintain an open source inventory, understand license obligations, conduct patent analysis, and use tools to manage compliance.