SBOM licence checker
Paste a software bill of materials and see each component's licence class, the obligations for your distribution model and any conflicts or unknown licences.
Safety and securityFree to useHow it worksSourcesWhere it helps
Fills the inputs below with typical figures. Replace any of them with your own.
- Flags for legal review
- 0 conflicts, 0 to review
- 3 notes. Flags are prompts for a lawyer, not rulings
- Components
- 10
- CSV
- Copyleft components
- 0
- Weak, strong or network copyleft
- Unknown or missing licences
- 0
- Without a version
- 0
- Read from loose names
- 0
- Confirm the exact licence
This is a screening aid, not legal advice. A flag is a prompt for a lawyer or your open source programme office, and no flag does not mean clearance. The rules are simplified.
Check these
- A CSV carries no supplier, identifier, author, time stamp or dependency data, so the NTIA coverage below will be low by design. Export CycloneDX or SPDX for the full set.
Sign in to save your inputs and come back to them later.
The class of each component after OR has taken the most permissive option and AND the strictest.
- public domain0
- permissive990%
- weak copyleft0
- strong copyleft0
- network copyleft0
- proprietary or commercial110%
- unknown0
Show the data as a table
| Item | Components |
|---|---|
| public domain | 0 |
| permissive | 9 |
| weak copyleft | 0 |
| strong copyleft | 0 |
| network copyleft | 0 |
| proprietary or commercial | 1 |
| unknown | 0 |
- Conflict0
- Review0
- Note3
Show the data as a table
| Item | Flags |
|---|---|
| Conflict | 0 |
| Review | 0 |
| Note | 3 |
| Class | Components | What it asks of you |
|---|---|---|
| permissive | 9 | Reproduce the copyright and licence notices with the product, for example in a documentation page or an about screen, and pass on any NOTICE file. |
| proprietary or commercial | 1 | Read the licence or contract: the right to redistribute or host, per-unit or per-seat fees, audit rights and any limit on use. Get the permission in writing before you ship. |
| Level | Component | Version | Why |
|---|---|---|---|
| Note | mbed TLS | 3.5.0 | Apache-2.0: pass on the NOTICE file and mark any changes you make. |
| Note | CMSIS | 5.9.0 | Apache-2.0: pass on the NOTICE file and mark any changes you make. |
| Note | Bootloader (in house) | 2.4.0 | Confirm you hold the right to redistribute it in this product, and any per-unit fees. |
| Component | Version | Licence as written | Understood as | Class | Flags |
|---|---|---|---|---|---|
| FreeRTOS-Kernel | 10.6.1 | MIT | MIT | permissive | none |
| lwIP | 2.1.3 | BSD-3-Clause | BSD-3-Clause | permissive | none |
| mbed TLS | 3.5.0 | Apache-2.0 OR GPL-2.0-or-later | Apache-2.0 (chosen from Apache-2.0 OR GPL-2.0-or-later) | permissive | Note |
| CMSIS | 5.9.0 | Apache-2.0 | Apache-2.0 | permissive | Note |
| TinyUSB | 0.16.0 | MIT | MIT | permissive | none |
| littlefs | 2.8.1 | BSD-3-Clause | BSD-3-Clause | permissive | none |
| zlib | 1.3 | Zlib | Zlib | permissive | none |
| Vendor HAL | 1.2.0 | BSD-3-Clause | BSD-3-Clause | permissive | none |
| newlib-nano | 4.3.0 | BSD-3-Clause | BSD-3-Clause | permissive | none |
| Bootloader (in house) | 2.4.0 | LicenseRef-Proprietary | LicenseRef-Proprietary | proprietary or commercial | Note |
| Field | Components with it | Share |
|---|---|---|
| Component name | 10 of 10 | 100% |
| Version | 10 of 10 | 100% |
| Supplier name | 0 of 10 | 0% |
| Other unique identifier (purl or CPE) | 0 of 10 | 0% |
| Licence stated | 10 of 10 | 100% |
| Class | In short |
|---|---|
| public domain | No conditions, or almost none. |
| permissive | Keep notices; very few other conditions. |
| weak copyleft | Changes to the component itself must be shared; your own code stays yours if you keep the boundary. |
| strong copyleft | Anything combined with it into one program must be shared under the same licence when you distribute. |
| network copyleft | As strong copyleft, and the duty also applies when users reach a modified version over a network. |
| proprietary or commercial | Terms set by a supplier or a custom licence: check redistribution, fees and use limits. |
| unknown | Licence missing or not recognised: it cannot be assessed. |
How it works
A software bill of materials lists the parts of a product, and every part carries a licence. This tool reads a bill of materials, works out each component's licence class, says what that class asks of you for the way you distribute the product, and flags clashes with the licence you plan to give your own product. It is a screening aid for engineers and a starting list for a lawyer. It is not legal advice.
- Read the document. The tool detects CycloneDX JSON, SPDX 2.x JSON or a CSV with name, version and licence columns (a header row is optional). From each component it takes the name, version, licence, supplier and identifier. In an SPDX document it uses the concluded licence and falls back to the declared one. The package the document describes (the product itself) is left out.
- Resolve the licence or expression. A licence field may be an SPDX identifier, an SPDX expression or a loose name. Identifiers are matched without regard to case. Deprecated GNU identifiers and the + suffix are read as only or or-later. Loose names such as BSD or GPLv2 are read as the likeliest identifier and marked approximate. Missing, NOASSERTION and unrecognised values are unknown.
- Evaluate AND, OR and WITH. WITH attaches an exception to a licence, AND binds tighter than OR, and brackets group. AND means every licence applies, so the strictest class decides. OR lets the recipient choose, so the tool takes the most permissive class and says which option it chose. A known linking exception, such as the Classpath exception, lowers a strong copyleft licence to weak copyleft.
class order: public domain < permissive < weak copyleft < strong copyleft < network copyleft < proprietary or commercial < unknown; A AND B = the higher class; A OR B = the lower class - Obligations for your distribution model. Copyleft duties are triggered by distribution, so the same component asks different things when you ship a binary, ship source, run a network service or keep the product inside the organisation. The obligations table gives the duties for each class that appears in your bill of materials, in plain words.
- Flags against the outbound licence. Each component is checked against the licence you will give your own product, the distribution model and the way components are linked. A flag is a conflict (the combination looks impossible as stated), a review (the answer depends on facts or on a boundary a lawyer should confirm) or a note (an obligation to remember). The rules are simplified: linking applies to every component alike, the kernel and applications are not told apart, and file-level facts are not seen.
- Gaps in the document. Components without a version, without a licence or with an unrecognised licence are listed. The tool also counts how many components carry the elements NTIA names as a minimum: supplier, name, version, a unique identifier, and, for the whole document, the dependency relationships, the author of the data and a time stamp.
Assumptions
- The licence strings in the document are right. A tool that wrote the document may have guessed, and a dual licence may be written as one entry.
- Several licence entries on one component are read as all applying, unless you choose to read them as alternatives.
- Classes are the Hub's own screening judgement, not part of the SPDX list. Public domain here means the component says so, not that it has been checked.
- One linking setting applies to every component. Real products mix static, dynamic and separate use, and the kernel, the libraries and the applications deserve separate answers.
- SPDX identifiers and names follow the SPDX License List version 3.29.0 of 16 September 2026; an identifier added later is shown as not recognised.
Limits and warnings
- This is a screening aid, not legal advice. A flag is a prompt for a lawyer or your open source programme office, and the absence of a flag is not clearance. Laws and licence readings differ between countries.
- Whether linking creates a combined work, whether a plug-in is a separate program, and what counts as distribution are legal questions that depend on facts the tool cannot see.
- File-level licences, embedded snippets, licence changes between versions, patent terms, export controls and the contents of a package that differ from its stated licence are not checked.
- Dual-licensed components use the OR rule, which picks the most permissive option. You must be able to comply with the option the tool chose.
- A bill of materials is only as complete as its generator. Components missing from it are missing from the check, and transitive or vendored code is often absent.
Sources
The methods and default figures rest on these public sources. The wording here is our own; read the source for its full text.
- SPDX License List (opens in a new tab), SPDX Workgroup, The Linux Foundation, Version 3.29.0, 16 September 2026. Identifiers and names of the licences in the table.
- SPDX Specification version 2.3, Annex D: SPDX license expressions (opens in a new tab), SPDX Workgroup, The Linux Foundation, August 2022. The grammar of AND, OR, WITH and the + suffix, and the fields read from SPDX JSON.
- CycloneDX Specification, version 1.7 (ECMA-424, 2nd edition) (opens in a new tab), OWASP Foundation and Ecma International, Released 21 October 2025. The components, licences, supplier and metadata fields read from CycloneDX JSON.
- The Minimum Elements For a Software Bill of Materials (SBOM) (opens in a new tab), National Telecommunications and Information Administration (NTIA), US Department of Commerce, 12 July 2021. The baseline data fields behind the coverage table.
- Frequently Asked Questions about the GNU GPL v2.0 (opens in a new tab), Free Software Foundation, Online edition. The view that static or dynamic linking makes a combined work, and what compatible means. One party's reading; others differ, which is why linking cases are flagged for review.
Where it helps
The lifecycle stages this tool serves: 3 stages in 2 lifecycles.
More safety and security tools
- Hardware safety metrics calculator
- Safety integrity level determination
- Fault tree calculator
- Fault injection campaign sizer
- Safety function failure probability calculator
- Threat risk assessment calculator
- Vulnerability severity calculator
- Side-channel leakage assessment
- Software update impact assessment
- Development assurance objectives checklist
- Medical device classification helper
Method notev1Formula, ranges, sources and limits
Reads a software bill of materials, resolves each licence or SPDX expression to a class, and counts the obligations, conflicts and gaps for a distribution model and an outbound licence. A screening aid, not legal advice.
Formula
class order: public domain < permissive < weak copyleft < strong copyleft < network copyleft < proprietary or commercial < unknown; A AND B = the higher class; A OR B = the lower class
| Input | Unit | Range it holds for | Comes from |
|---|---|---|---|
| Distribution model | choice | binary, source, service, internal | Your figure |
| Outbound licence of your product | choice | proprietary, permissive, mpl-2.0, gpl-2.0-only, gpl-2.0-or-later, gpl-3.0-only, gpl-3.0-or-later, agpl-3.0-or-later | Your figure |
| Linking | choice | static, dynamic, separate | Your figure |
| Several licences on one component | choice | and, or | Your figure |
Outputs: Components (count); Permissive components (count); Copyleft components, weak, strong or network (count); Components with an unknown licence (count); Conflict flags (count); Review flags (count).
Assumptions
- The licence strings in the document are right. A tool that wrote the document may have guessed, and a dual licence may be written as one entry.
- Several licence entries on one component are read as all applying, unless you choose to read them as alternatives.
- Classes are the Hub's own screening judgement, not part of the SPDX list. Public domain here means the component says so, not that it has been checked.
- One linking setting applies to every component. Real products mix static, dynamic and separate use, and the kernel, the libraries and the applications deserve separate answers.
- SPDX identifiers and names follow the SPDX License List version 3.29.0 of 16 September 2026; an identifier added later is shown as not recognised.
Uncertainty: The counting is exact for the document. The classes and flags are screening judgements with simplified rules, so a flag can be a false alarm and a missing flag is not clearance.
Known limits
- This is a screening aid, not legal advice. A flag is a prompt for a lawyer or your open source programme office, and the absence of a flag is not clearance. Laws and licence readings differ between countries.
- Whether linking creates a combined work, whether a plug-in is a separate program, and what counts as distribution are legal questions that depend on facts the tool cannot see.
- File-level licences, embedded snippets, licence changes between versions, patent terms, export controls and the contents of a package that differ from its stated licence are not checked.
- Dual-licensed components use the OR rule, which picks the most permissive option. You must be able to comply with the option the tool chose.
- A bill of materials is only as complete as its generator. Components missing from it are missing from the check, and transitive or vendored code is often absent.
Where the method comes from
Follows SPDX Specification version 2.3, Annex D: SPDX license expressions (opens in a new tab). The platform's version departs from it as follows.
- An OR expression is resolved by taking the most permissive option, and AND by taking the strictest class. Why: A screening count needs one class per component, and the SPDX grammar leaves the choice to the user.
- Each licence is placed in a class of the Hub's own, and flags are raised against an outbound licence. Why: SPDX identifies licences but does not classify their obligations or judge compatibility.
Reference example, checked by test: The default firmware bill of materials in this tool, counted by hand: 10 components. Nine are permissive (FreeRTOS-Kernel, lwIP, mbed TLS taken as Apache-2.0 from its OR expression, CMSIS, TinyUSB, littlefs, zlib, the vendor HAL and newlib-nano) and one is the in-house bootloader under a proprietary reference. Nothing is copyleft or unknown, and there is no conflict or review flag. Components 10; Permissive components 9; Copyleft components, weak, strong or network 0; Components with an unknown licence 0; Conflict flags 0; Review flags 0.
Versions
- v1 (2026-10-25): First version, built from the tool idea.
Terms on this page
- SBOM
- A machine-readable inventory of every component, version and licence in a shipped software image, expressed in formats such as SPDX or CycloneDX.
- BOM
- The structured list of every component, with part number and quantity, needed to build one unit of a product.
- BSD
- A function that monitors the adjacent lanes rearward and warns the driver, usually with a mirror-mounted indicator, when another road user occupies the area not visible in the mirrors.
- Kernel
- In GPU programming, a function launched across a grid of many threads on the device.
- Export control
- Government rules that restrict the export, re-export or transfer of specified goods, software and technology, including chips, design tools, manufacturing equipment and technical data.
Need help acting on this?
Tell us what you're after and leave your email: we'll connect you with the right person on the Hub.