The incoming license is the license under which you received a software package. The outgoing license is the license under which you distribute it. A legal review records both for every component, because a package can contain code under several licenses and the answers may differ per part.
Definitions
The TODO Group guide to using open source code defines the terms this way: the incoming license is the license under which you received the software package, and the outgoing license is the license under which you are licensing the software package. It notes the plural form is deliberate, because a component can include source code available under different licenses.
The guide gives two examples. In a simple case, when the incoming license is a permissive license that allows relicensing, such as BSD, a company may relicense that software under its own proprietary license. In a more complex case, a component includes proprietary code plus code under License A, License B and License C. Then the incoming licenses are the sum of all of them, and the outgoing license is a question counsel must answer.
This post explains terms and process. It is not legal advice, and your counsel decides what applies.
Why record both
Recording only what came in leaves a gap. The outgoing decision determines what you tell customers, what notices you ship, and what source you may need to offer. Writing the two decisions down together makes later questions easy to answer, for example when a customer asks what license applies to a library you ship.
Where it fits in the process
In the guide's five-stage process, the decision on incoming and outgoing licenses is the product of stage three, the legal review. The reviewer starts from the scan report, the license files and comments from engineers and the audit team, and produces a legal opinion of compliance. The guide lists three possible outcomes:
| Outcome | What happens next |
|---|---|
| No issues | Counsel decides on incoming and outgoing licenses and the ticket moves to architecture review |
| Issues found | Counsel flags them and reassigns the ticket to engineering to rework the code |
| Unclear licensing | Counsel or engineering contacts the project maintainer to confirm the license |
What to record per component
A compact record is enough:
- Component name and version.
- Incoming license or licenses, with where you found them.
- Outgoing license decision, and who made it.
- Date of the decision and the product it applies to.
- Obligations that follow, such as notices.
The guide stresses that approval is product-specific, so record the product. Approval for one product is not approval for another deployment, even with the same component.
Common slip-ups
Trusting a single field. A package metadata field may name one license while the repository contains others. See why two license scans show different results.
Missing notices. The guide says to capture copyright and attribution notices as well as the license, so you can provide attribution in product documentation.
Forgetting to re-record after upgrades. A new version can change licenses. Re-review it.
Try it yourself
Click through it at your own pace, or open it full screen. See which license fields appear per component, and think about where you would record the outgoing decision.
How Safeguard fits
Safeguard provides SBOM and dependency scanning and compliance and evidence automation, which can supply the license inventory a reviewer starts from. Try gold.safeguard.sh/scan.
Quick check
Is the outgoing license always the same as the incoming one?
No. The TODO guide notes a company may relicense permissively licensed software under its own proprietary license when the incoming license allows it. Counsel decides.
Who decides the outgoing license?
Legal counsel, typically as part of the review board, per the TODO guide.
Sources
Last reviewed: 19 October 2026.
