License Conclusion
License Conclusion (Starting from Xray version 3.124.x and above) allows users to determine a final, authoritative license for a specific SBOM entry, automatically or manually, without removing the originally declared licenses.
Instead of discarding conflicting or multiple declared licenses, Xray now supports automatic, priority based license conclusion to perform this task easily
Organizations often face challenges when managing multiple or conflicting licenses in a Software Bill of Materials (SBOM). For instance, a software package declared under both the MIT and Apache 2.0 licenses can create confusion regarding compliance obligations. As companies integrate diverse open source and proprietary components, clarity around licensing becomes essential to avoid legal issues. Compliance teams need effective tools to navigate these complexities and accurately communicate licensing obligations.
Benefits
- Improves legal clarity by distinguishing between declared and concluded licenses
- Supports compliance teams with more accurate reporting and audit readiness
- Allow to better communicate the actual combined license obligations of a certain artifact
How It Works
- License conclusion is performed based on the assigned license “priority” value (lower is better)
- Each license is assigned a default priority based on its license category (see license priority table) - the default priority value can be overridden using the “Set license” API endpoint
- Custom license priority can be used to differentiate between licenses in the same category (e.g. MIT and ISC - 2 permissive licenses with the same default priority)
Default License Priority Table
| License Category | Priority | Description |
|---|---|---|
| CLA | 5 | Contributor License Agreement. An administrative legal instrument defining the terms of contribution to a project, not usage. Often signals corporate ownership and potential future relicensing risk. While not a blocker for usage, it requires review to ensure the project structure aligns with long-term dependency goals. |
| Copyleft Limited | 3 | The Component-Level Compromise. Also known as "Weak Copyleft." Mandates that source code modifications to the specific library be shared, but allows the library to be linked to proprietary applications without the "viral" spread of the license to the main codebase. Requires developmental discipline (dynamic linking) and is mainly useful in dynamic-linked languages . Includes LGPL, MPL, EPL. |
| Proprietary Free | 5 | Closed-Source Freeware. Software provided at no cost but with no source code and strict prohibitions on modification or reverse engineering. Carries high operational risk ("Abandonware"): if the vendor disappears, the user cannot fix bugs or patch security holes. A "Black Box" dependency. |
| Permissive | 2 | The "Do-Anything" Standard. Grants broad rights to use, modify, and redistribute with minimal obligations (typically just copyright attribution). It allows for "freedom to close," meaning code can be incorporated into proprietary products without problems. Ideal for commercial development. Includes MIT, BSD, and Apache 2.0. |
| Patent License | 5 | Invention Rights Only. A specific grant of patent rights, distinct from copyright. It acts as a covenant not to sue for patent infringement. Categorized as high priority because these licenses are often complex, may contain defensive termination clauses ("if you sue us, this license ends"), and often appear alongside, but separate from, usage licenses. |
| Source-available | 4 | Don't Resell This Software category. Source code is viewable and often modifiable for internal use, but the license contains discriminatory restrictions (e.g., prohibiting SaaS competition or commercial exploitation). Breaks the "Open Source Definition." Used by vendors (MongoDB, Elastic) to protect business models. Risk depends on the user's business model. |
| Free Restricted | 4 | Free with Strings Attached. Free of charge but imposes field-of-use restrictions. Includes "Ethical Source" (e.g., no military use) or industry-specific limitations (e.g., no nuclear use). These restrictions create binary compliance risks—the software is legally forbidden for specific sectors, requiring careful vetting of the user's domain. |
| Unstated License | 5 | No License Found Components found without any explicit license file or header. Extremely Risky to use since author intentions are completely unknown |
| Copyleft | 5 | The Viral Licenses. Strong Copyleft (GPL, AGPL) mandates that any derivative work (often including statically linked applications) be licensed under the same terms. For AGPL, this extends to network access (SaaS). This is a "poison pill" for proprietary software, frequently forcing full source disclosure of the user's application. |
| Commercial | 5 | Pay-to-Play. Proprietary software requiring a purchased license. Usage without a valid contract constitutes theft. |
| Public Domain | 1 | The Zero-Restriction Licenses. Software where the author has waived all copyright, or rights have expired (e.g., CC0, Unlicense). Effectively the most permissive state possible. |
REST API Support
Updated 3 months ago