FOSSA License Compliance Gap When Dependencies Include Dual-Licensed Libraries
Dual-licensed open source libraries create a structural challenge for software composition analysis (SCA) tooling. When a dependency offers multiple licenses and the user must choose which terms to follow, automated scanners face a fundamental ambiguity: they can detect every license present, but they cannot determine which license governs a specific project’s use without additional context. FOSSA, a prominent SCA platform for license compliance, exhibits this limitation in its documented scanning behavior. This analysis examines how FOSSA represents dual-licensed dependencies, identifies the specific compliance gap this creates, and provides guidance for teams working within FOSSA’s current architecture.
How Dual-Licensed Libraries Are Structured
Dual-licensed and multi-licensed libraries appear in open source ecosystems in three common forms. Understanding these structures is essential because each presents different challenges for dependency scanning and policy enforcement.
OR-licensed dependencies present a choice between two or more licenses at the package level. The Mozilla Public License 2.0 and the GNU General Public License version 2 or later are canonical examples. The package manifest or documentation states that the user may comply under any of the listed licenses.
Multi-licensed files contain code under different licenses within the same distribution. A project might combine MIT-licensed core code with Apache-2.0-licensed contributions, or include third-party components under separate terms. The dependency as a whole carries multiple license obligations simultaneously rather than offering a choice.
License choice clauses appear in package metadata where the author specifies a default license but allows alternative licensing through explicit agreement or configuration. Commons Clause variants and custom commercial licensing arrangements fall into this category.
FOSSA’s documentation distinguishes between two license signals for each dependency: the Declared License, which the package author stated in the manifest, and the Discovered License, which FOSSA found by scanning the source code. A single dependency can carry both signals, and FOSSA records which signal triggered a given license issue.
FOSSA’s Documented Scanning Behavior for Dual Licenses
Per FOSSA’s documentation, the platform identifies all licenses across the dependency tree and source, surfaces what each one requires, and helps you stay compliant. For dual- or multi-licensed projects, FOSSA’s glossary defines that a project has a Dual or Multi-license if the user can choose between two or more licenses to adhere to.
The platform’s License Conclusion feature determines a single, dominant license for each dependency by combining FOSSA’s Declared License data with Discovered License data from source code scans. This suggests a mechanism for reducing license multiplicity to a single actionable conclusion.
However, the critical gap emerges in how this conclusion operates for choice-based dual licenses. FOSSA’s documentation establishes that it identifies licenses and surfaces requirements. It does not state that FOSSA automatically resolves which license choice a specific project has made or should make based on that project’s context, compatibility constraints, or business requirements. The License Conclusion combines declared and discovered signals—it does not appear to incorporate project-specific license selection logic.
For a dependency published as “GPL-2.0-or-later,” FOSSA would detect both GPL-2.0 and GPL-3.0 as present. For “MIT OR Apache-2.0,” it would surface both licenses. The compliance team must then determine which license terms apply to their specific use case and whether that choice is compatible with their broader dependency graph.
The Specific Gap: Detection Without Contextual Resolution
The gap is not in FOSSA’s ability to find licenses—it is in the boundary between detection and resolution. FOSSA reports all detected licenses without resolving which license applies to the dependency’s use in your project context. This leaves compliance teams to manually verify license selection and compatibility.
Consider a concrete scenario. Your project depends on a library dual-licensed under MIT OR Apache-2.0. Your organization’s policy might prefer Apache-2.0 for patent protection reasons, or might accept MIT for its simplicity. FOSSA will flag both licenses as present. It will not automatically apply your policy preference to conclude “this dependency is under Apache-2.0 for our purposes.” The compliance team must:
- Review the dependency’s license metadata
- Determine which license option the project has selected or should select
- Verify that this selection is compatible with all other dependencies’ terms
- Document this decision for audit purposes
This manual step scales poorly. A project with hundreds of dependencies, even a small percentage with dual licensing, creates significant review overhead. The risk of inconsistent decisions across teams or missed incompatibilities increases with dependency count.
FOSSA’s policy automation can flag licenses that violate configured rules, but the policy engine appears to operate on detected licenses rather than resolved choices. A policy blocking GPL-3.0 might trigger on a “GPL-2.0-or-later” dependency even if the project has validly chosen to comply under GPL-2.0 terms only.
Configuration Guidance
The following instructions reflect FOSSA’s documented behavior, with reference to features discussed in available product documentation and update notices.
Before Any Irreversible Policy Change: Back Up First
Back up your current FOSSA configuration before modifying license policies. Export your existing policy definitions, project configurations, and any custom license conclusions your team has established. FOSSA’s documentation does not describe a native full-configuration export; document your current settings through screenshots, policy rule documentation, or API-retrieved configuration data. Store this backup outside the FOSSA system. License policy changes can trigger immediate re-evaluation of project compliance status and may alter build-passing conditions for integrated CI pipelines.
Working with Dual-Licensed Dependencies in FOSSA
-
Review License Conclusions manually. Navigate to the dependency’s license details in FOSSA’s interface. Verify whether the License Conclusion reflects your organization’s intended license choice. If FOSSA has selected a dominant license that does not match your project’s selection, prepare to override or document.
-
Configure policy rules for each detected license. Since FOSSA surfaces all detected licenses, create policy rules that address each license individually. For an MIT OR Apache-2.0 dependency, your policy must explicitly handle both MIT and Apache-2.0 rather than relying on a single resolved conclusion.
-
Use issue states to track manual resolutions. FOSSA’s documentation describes Active and Ignored issue states. When your team manually resolves a dual-license ambiguity, use the appropriate issue state and add documentation explaining the resolution rationale.
-
Leverage the fossa-cli for local verification. The vendor’s FAQ indicates the open-source fossa-cli is free to run locally without CI integration or automated updates. Use this for pre-commit verification of how FOSSA will classify dependencies before pushing to integrated scanning.
-
Monitor product updates for dual-license handling improvements. Available product update notices have mentioned container scanning, CycloneDX report improvements, and NOTICE file recreation support. Documentation does not indicate that these updates explicitly addressed automatic license-choice resolution, but the product’s evolution in automation suggests this area may receive future attention.
| FOSSA Feature | Behavior for Dual-Licensed Dependencies | Action Required |
|---|---|---|
| Declared License detection | Reads package manifest license field | Verify manifest accuracy against upstream |
| Discovered License scanning | Finds all licenses in source | Review for multi-licensed files |
| License Conclusion | Combines signals into dominant license | Manually validate against project context |
| Policy automation | Evaluates all detected licenses | Configure rules per detected license, not per resolved choice |
| Issue tracking | Active/Ignored states | Document manual resolution rationale |
Applicability Boundary
This analysis applies to teams using FOSSA for SCA license compliance who consume dual-licensed dependencies. Common examples include GPL-2.0-or-later, MIT OR Apache-2.0, and Commons Clause variants. Teams with strict compliance frameworks requiring deterministic single-license attribution per dependency are particularly affected.
Organizations whose dependencies are predominantly single-licensed, or whose open source governance processes already incorporate manual legal review for all dependencies, will experience less friction from this gap. The overhead of manual resolution is already embedded in their workflow.
Who FOSSA Is Wrong For
FOSSA is the wrong choice for two categories of teams:
Teams expecting automatic license-choice resolution without manual policy configuration. If your compliance model assumes that SCA tooling will read a dual-licensed dependency and automatically apply the correct single license based on your project’s characteristics, FOSSA’s documented behavior does not support this. The platform identifies and surfaces; it does not contextually resolve.
Organizations whose compliance framework requires deterministic single-license attribution per dependency. If your audit standards, customer contracts, or regulatory obligations demand that every dependency in your SBOM carry exactly one unambiguous license identifier, FOSSA’s multi-license detection and conclusion mechanism introduces documentation complexity. You will need supplemental processes to achieve the deterministic output your framework requires.
Comparable Tool Positioning
Published third-party benchmarks report that FOSSA is the better tool for organizations where license compliance is a board-level concern, while Snyk is the better tool for organizations where developer adoption of security findings is the bottleneck. Another comparison notes that FOSSA goes a step further by providing comprehensive license compliance management relative to Snyk’s license identification capabilities.
Snyk’s official pricing page lists plans with a free tier and paid options starting at a specific price point, with Enterprise options available. Snyk’s CLI and native CI plugins exit non-zero on blocked licenses, with results shown inline in builds.
GitGuardian offers a free plan and trial period for its Business plan, per its documentation. GitGuardian’s platform focuses on secrets security and non-human identity governance rather than license compliance as a primary capability.
Neither Snyk nor GitGuardian’s documented features indicate automatic resolution of dual-license choices. The structural challenge—detecting multiple licenses without project-context selection logic—appears to span current SCA tooling broadly. FOSSA’s explicit License Conclusion feature represents one approach to reducing complexity, but the manual verification gap persists across the category.
Doc-vs-Reality Considerations
FOSSA’s documentation describes License Conclusion as determining a single, dominant license for each dependency. The practical implementation of this feature for choice-based dual licenses is not fully specified in publicly available material. Teams should verify whether their observed FOSSA behavior matches documented intent, particularly for dependencies with complex license metadata or custom license choice clauses.
Product update notices mention CycloneDX report improvements. The CycloneDX specification includes license choice expression support (SPDX OR syntax). Whether FOSSA’s CycloneDX exports preserve dual-license expressions or flatten them to conclusions is not detailed in the available update description. Teams using FOSSA-generated SBOMs for downstream compliance should validate export behavior against their requirements.
Summary
Dual-licensed libraries create inherent ambiguity for automated SCA tooling. FOSSA detects all licenses present in a dependency and provides a License Conclusion mechanism, but its documented behavior does not include automatic resolution of which license choice applies to a specific project’s context. Compliance teams must manually verify license selection, configure policies to address each detected license individually, and document resolutions for audit purposes.
The gap is structural, not unique to FOSSA, but teams evaluating FOSSA should assess whether their compliance overhead budget accommodates this manual step. Those requiring deterministic single-license attribution without manual intervention should expect to implement supplemental processes or await tooling evolution.
This article documents FOSSA’s published tooling behavior based on available documentation and product update notices. It is not legal advice, security advice, or a substitute for professional counsel on open source license compliance. Organizations should consult qualified legal expertise for license interpretation specific to their use cases and jurisdictions.
