License Conclusions vs. License Corrections
Understand the difference between concluding a license and correcting one, when to use each, and how they interact.
Overview
FOSSA gives you two distinct tools for getting a dependency's license right, and they're easy to mix up because both touch the Licenses tab of the dependency drawer. They solve different problems:
- A License Conclusion picks the single dominant license from the data FOSSA already detected. It doesn't change the underlying detected data; it decides which of the detected licenses wins.
- A License Correction changes the detected data itself: adding, changing, or removing a license when FOSSA got it wrong.
In short: conclude when the detected data is right but you need one authoritative answer; correct when the detected data is wrong.
At a glance
| License Conclusion | License Correction | |
|---|---|---|
| Question it answers | "Which of the detected licenses is the dominant one?" | "What is the dependency's license, really?" |
| Acts on | A choice among declared and discovered licenses | The detected license data itself |
| Origin | Auto-computed during analysis (optionally overridden by hand) | Always a manual edit |
| Default behavior | Disabled until enabled at the org level | Always available |
| Scope | Per dependency version, with optional scoping (org → project → revision) | Org-wide for that dependency, across every project and every version |
| Drives policy? | Yes, has dedicated policy settings | Indirectly, corrected data is what policy evaluates |
| Surfaced in SBOMs | As PackageLicenseConcluded (SPDX) | As the dependency's license data |
What a License Conclusion does
FOSSA detects licenses two ways: Declared licenses from package manifests and Discovered licenses from scanning source code. A dependency can carry several of each. A conclusion combines those inputs into a single authoritative license that drives policy evaluation and attribution, mirroring the PackageLicenseConcluded field in SPDX.
Conclusions are generated automatically during analysis. When the inputs are unambiguous (exactly one declared, or exactly one discovered) FOSSA concludes to that license; when they conflict or are missing, FOSSA either resolves a dominant license, concludes multiple licenses with AND, or leaves the dependency Unconcluded for review. You can also override the automated result by hand with Conclude / Unconclude.
Because a conclusion is a decision layer on top of detected data, it has its own policy settings (for example, Only create issues for Concluded Licenses and Intelligent Auto-Ignore) and must be enabled at the organization level before it appears in projects.
Note
A conclusion never edits the Declared or Discovered data underneath it. Unconcluding a dependency simply returns to FOSSA's automated result; the original detected licenses are still there.
What a License Correction does
A correction fixes the detected data when it's wrong: FOSSA found no license and you know what it should be, or it detected a false positive (for example, a license name picked up from a code comment). You add, change, or remove the license directly.
Corrections are org-wide. Editing a dependency applies the change to every project and every version of that dependency across your organization; fix it once and it takes effect everywhere. This is why corrections require an appropriate organization-level role.
Warning
Unlike a conclusion, which you can scope to a single project or revision, a correction always applies to the dependency everywhere it appears in your organization. Use it for facts that are universally true about the package, not project-specific preferences.
How they interact
Corrections and conclusions are not independent; a correction feeds into the conclusion, but not the other way around:
- When you correct a dependency's licenses, FOSSA re-runs the conclusion against the corrected data and reconciles any existing conclusions. If a correction removes a license, that license is also dropped from any conclusion that referenced it.
- Concluding or unconcluding a license never alters the corrected or detected data. Conclusions are stored separately from the dependency's license records.
So the pipeline reads detected data → (optional correction) → conclusion → policy evaluation. Correct first when the raw data is wrong; conclude (or let FOSSA conclude) to choose the dominant license from whatever data remains.
Which one should I use?
| If you want to… | Use |
|---|---|
| Choose one dominant license among several FOSSA correctly detected | Conclusion |
| Reduce issue noise so only the dominant license generates issues | Conclusion (policy settings) |
| Flag dependencies FOSSA couldn't resolve to a single license | Conclusion (Create issues when a license can't be concluded) |
| Add a license FOSSA missed entirely | Correction |
| Remove a license FOSSA detected by mistake | Correction |
| Replace a wrong license with the correct one for the whole org | Correction |
| Apply a license decision to just one project, not the whole org | Conclusion (scoped) |
Note
Still seeing the wrong license after concluding? Check whether the detected data itself is wrong; a conclusion can only choose among what FOSSA detected, so a bad detection needs a correction first. For anything you can't resolve, contact support@fossa.com with your project locator and the affected dependency.