The open source landscape

What is open source software?

Open source means more than making source code visible. The Open Source Initiative’s definition requires distribution terms that permit redistribution, provide source code, allow modifications and derived works, avoid discrimination, and remain technology-neutral, among other criteria.^[1]

The specific license controls the permissions and conditions for a component. Therefore, teams should record the exact license text and version that applies to each dependency rather than rely on a broad “open source” label.

License compliance and patent clearance are related but separate. For the patent-search side of the review, Eureka IP Search includes an FTO workflow that builds and refines search strategies, screens potentially relevant claims with legal-status context, and organizes claim-level comparisons.^[10] It does not replace a software composition inventory or determine open source license compliance.

Common open source licenses

Permissive licenses generally allow use, modification, and redistribution subject to comparatively limited conditions, but their exact terms differ:

• MIT License: permits use, modification, distribution, sublicensing, and sale, subject to retaining the copyright and permission notice.^[6]
• Apache License 2.0: includes separate copyright and contributor patent licenses, redistribution conditions, a NOTICE mechanism, and patent-litigation termination language.^[2]
• 3-Clause BSD License: permits redistribution and use with conditions covering notices and endorsement; its core text does not contain an express patent grant.^[7]

Copyleft licenses apply conditions to covered modifications, combined works, distribution, or network use, depending on the license and version:

• GPLv2 and GPLv3: both impose copyleft conditions, but GPLv3 contains a detailed express contributor patent-license provision that does not appear in the same form in GPLv2.^[3][4]
• AGPLv3: adds a requirement for a modified program used for remote network interaction to offer corresponding source to those users, subject to the precise conditions in section 13.^[5]
• LGPLv3: incorporates GPLv3 terms and adds permissions and conditions for libraries, applications, and combined works.^[8]

Hybrid approaches include dual licensing and products that combine proprietary and open source components. Each component, license choice, modification, interface, and distribution path should be analyzed on its own facts.

How open source licenses address patents

Patent grants in license review

Some open source licenses contain express patent grants. Others do not. Even an express grant is limited by its definitions, the patents controlled by the granting party, the covered contribution or work, and any termination conditions. It does not license unrelated third-party patents.

Apache License 2.0

Apache License 2.0 separates the copyright grant in section 2 from the patent grant in section 3. Section 3 grants a patent license only for patent claims licensable by a contributor that are necessarily infringed by the contributor’s contribution alone or in combination with the work to which it was submitted.^[2]

The same section states that specified patent litigation alleging that the work or an incorporated contribution infringes will terminate patent licenses granted for that work. Accordingly, “perpetual” and “irrevocable” should not be read without the section’s scope and termination language.

Patent provisions in GPL versions

GPLv3 section 11 states that each contributor grants a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims for the contributor version. The definitions and downstream patent-license provisions in that section limit and shape the grant.^[4]

GPLv2 should not be described as containing the same express GPLv3 contributor patent license. Its text addresses patents differently, including through conditions that may prevent distribution when other obligations cannot be satisfied.^[3] Always identify the applicable GPL version and any “only” or “or later” designation.

Licenses without an express patent grant

The standard MIT and 3-Clause BSD texts grant broad copyright permissions but do not contain an express patent-license clause.^[6][7]

What this means: the absence of an express clause is a fact about the license text, not a complete conclusion about implied rights or patent exposure. Counsel should assess the governing law, project history, contributor agreements, and third-party patents before drawing a legal conclusion.

FTO risks in open source software

Risk 1: Patent claims involving contributors

Scenario: a project includes code from contributors who control patents relevant to their contributions.

Risk: the applicable license or contributor agreement may grant patent rights, but the scope may be limited to defined contributions and essential claims. It may also include termination conditions.

Mitigation:

• identify the exact license, version, and contributor terms;
• map the implemented functionality to the patent-grant definitions;
• review termination clauses before initiating or responding to patent disputes;
• conduct a focused patent search where the component is material.

Risk 2: Patent claims from non-contributors

Scenario: a third party that did not grant rights under the project license controls a patent alleged to cover the component or its use in the product.

Risk: an open source license cannot automatically grant rights under patents controlled by unrelated third parties. In the United States, infringement questions turn on the acts and requirements stated in 35 U.S.C. §271, while validity defenses are separately addressed under §282.^[11][12]

Mitigation: conduct a claim-focused FTO review, confirm jurisdiction and legal status, assess design-arounds or licenses, and obtain qualified legal advice for material exposure.

Risk 3: Copyleft obligations

Scenario: proprietary software incorporates, modifies, links to, or interacts with copyleft-licensed code.

Risk: obligations depend on the license version, the covered work, what was modified or combined, and whether code is conveyed or used for remote network interaction. It is too broad to say that every use of GPL code requires disclosure of all proprietary source.

Mitigation:

• analyze the actual architecture and distribution model;
• do not assume that process separation or a separate module automatically resolves the issue;
• review applicable exceptions and additional permissions;
• seek legal advice before release when proprietary and copyleft code interact materially.

Risk 4: License compatibility

Scenario: a product combines code under different licenses.

Risk: compatibility is directional and version-specific. Apache License 2.0 code can be included in a GPLv3 project under GPLv3 terms, while the Free Software Foundation does not consider Apache License 2.0 compatible with GPLv2. Apache also explains that GPLv3 code cannot simply be included in an Apache-licensed project.^[9]

Mitigation: record every license version, direction of code flow, combination method, and intended distribution terms. Use an authoritative compatibility source and counsel rather than a license-name-only rule.

Conducting software FTO for open source components

Step 1: Identify open source components

Create and maintain an inventory that records:

• component and package name;
• exact version, commit, fork, and source repository;
• direct and transitive dependencies;
• license identifier and full license text;
• copyright, NOTICE, attribution, and modification records;
• how the component is linked, modified, deployed, and distributed.

Software composition analysis tools, dependency managers, package manifests, build records, and manual review can support this inventory. Automated classifications should be checked against the actual files shipped with the selected version.

Step 2: Analyze license obligations

For each component, identify attribution and notice requirements, source-offer or disclosure conditions, modification notices, relinking or installation-information duties where applicable, network-use provisions, compatibility constraints, express patent grants, and termination clauses.

Ask whether the product is distributed, hosted, embedded, or used only internally; whether the component is modified; and whether any exception, dual-license option, or commercial license applies. Do not treat “commercial use allowed” as meaning “no conditions apply.”

Step 3: Assess patent risks

Define the product functionality and commercial acts, then search potentially relevant claims across the target jurisdictions. Review patent families, current owners, legal status, claim limitations, component versions, and the way the component is used in the complete product.

For this separate patent workstream, Eureka IP Search’s claim-review workflow can organize product-derived search strategies, legal-status context, and claim-level comparisons for professional review.^[10]

Step 4: Assess copyleft obligations

For each copyleft component, identify the exact license version, covered work, modifications, linking or combination, distribution event, network interaction, corresponding-source requirements, notices, and any exceptions. Architectural labels such as “plugin,” “service,” or “separate process” are relevant facts but not automatic legal outcomes.

Step 5: Develop mitigation strategies

For license obligations:

• provide required notices, license copies, offers, or corresponding source;
• change the component, version, architecture, or distribution model;
• use an available exception, alternative license, or commercial license after review;
• obtain a legal opinion for material uncertainty.

For patent risks:

• confirm whether an express license grant covers the relevant claim and use;
• design around required claim limitations where feasible;
• seek a patent license or other commercial resolution;
• evaluate non-infringement and validity separately;
• accept documented residual risk only through the organization’s approval process.

Practical examples: open source and patents

Example 1: Linux and patent scope

The Linux kernel is provided under GPL-2.0-only, with an explicit syscall exception described in its licensing documentation.^[13]

Lesson: identify the precise license, exceptions, relevant code, and third-party patent rights. A project’s license cannot resolve patents controlled by unrelated parties.

Example 2: Apache License 2.0 projects

Apache License 2.0 includes an express contributor patent grant with defined scope and a patent-litigation termination condition.^[2]

Lesson: an express patent clause can be important, but it is not an unlimited warranty, indemnity, or license to every patent that could affect the software.

Example 3: Copyleft compliance

GPL, LGPL, and AGPL obligations depend on the exact license version and facts. AGPLv3, for example, addresses remote network interaction with modified versions, while LGPLv3 adds permissions and conditions for libraries and combined works.^[5][8]

Lesson: review the actual release architecture and license text before concluding that source disclosure is—or is not—required.

Best practices for software FTO analysis

1. Maintain an open source inventory. Include versions, forks, transitive dependencies, licenses, notices, and release use.
2. Read the actual license. License family names are not a substitute for the controlling text and version.
3. Use compliance tools with human review. Validate automated results against shipped artifacts.
4. Conduct patent analysis. Focus on material components and product functionality in target jurisdictions.
5. Avoid blanket license preferences. Choose components based on technical, licensing, patent, and business requirements.
6. Do not rely on isolation alone. Architecture can affect analysis but does not create a universal safe harbor.
7. Obtain qualified legal advice. Escalate material patent, copyleft, compatibility, and distribution questions.
8. Monitor updates. Track component versions, license changes, forks, ownership, and relevant patent status.
9. Contribute with defined terms. Review contributor agreements and inbound/outbound licensing before contributing.
10. Document decisions. Preserve inventory evidence, legal analysis, approvals, notices, and remediation records.

Open source license comparison

This table summarizes selected provisions in the standard license texts. It is not a compatibility opinion and does not account for project-specific exceptions, contributor agreements, dual licenses, or governing-law questions.

Conclusion

Open source software creates two connected review needs: compliance with the licenses governing each component and patent clearance for the functionality and commercial activity of the product. A disciplined software FTO process maintains a version-specific component inventory, reads the controlling license text, separates contributor grants from third-party patents, evaluates copyleft and compatibility on the actual architecture, and documents each software FTO decision.

Frequently asked questions about software FTO

Sources and verification

1. The Open Source Definition. Open Source Initiative.
2. Apache License, Version 2.0. Apache Software Foundation.
3. GNU General Public License, version 2. Free Software Foundation.
4. GNU General Public License, version 3. Free Software Foundation.
5. GNU Affero General Public License, version 3. Free Software Foundation.
6. The MIT License. Open Source Initiative.
7. The 3-Clause BSD License. Open Source Initiative.
8. GNU Lesser General Public License, version 3. Free Software Foundation.
9. Apache License v2.0 and GPL Compatibility. Apache Software Foundation.
10. AI Patent Search, FTO & Design Clearance. Patsnap Eureka IP Search.
11. 35 U.S.C. §271—Infringement of patent. U.S. House Office of the Law Revision Counsel.
12. 35 U.S.C. §282—Presumption of validity; defenses. U.S. House Office of the Law Revision Counsel.
13. Linux kernel licensing rules. Linux Kernel documentation.

Sources checked July 31, 2026. Eureka product wording is limited to capabilities stated on the current public IP Search page. License and product terms may change; verify the version that applies to the shipped software.