# Software licensing: make the shipped artifact explainable

Original SecNet workpaper · 1.0 · 11 October 2026

Complete placeholders for your assessment. The example below is fictional; it is not an executed test or a legal decision.

## Assessment identity

- Record ID: [___]
- Objective and decision question: [___]
- Scope / exclusions: [___]
- Criteria and version: [___]
- Authorization and limits: [___]
- Owner / independent reviewer: [___]
- Period / artifact digest: [___]
- Evidence access / retention: [___]

## Planned procedure

1. Inventory the actual shipped build, transitive dependencies, embedded assets and copied code. Distinguish development-only components from what customers receive or access.
2. Collect license expressions, notices, origin and versions with evidence. Treat unknown, conflicting or custom license text as a review item rather than guessing a familiar license.
3. Review obligations against distribution, modification, linking and network-service use with qualified license review. Do not assume all copyleft licenses have identical conditions.
4. Prepare the required notices, license texts and any applicable source/offers or other artifacts. Verify that the delivered package contains the approved materials.
5. Assess dependency security and provenance in parallel but keep conclusions distinct. A vulnerability patch can introduce a new license or component requiring review.
6. Link the approved SBOM and review record to the immutable release digest. Reconcile changes on upgrades and route unresolved obligations to an accountable decision.

## Evidence and decision register

| ID | Criterion | Observation | Redacted evidence / origin / time | Conclusion and limitation | Owner / date | Recheck |
|---|---|---|---|---|---|---|
| [___] | [___] | [___] | [___] | [___] | [___] | [___] |

## Topic-specific deliverables

- [ ] Release-linked component inventory/SBOM and provenance gaps.
- [ ] License-obligation matrix with review decisions and evidence.
- [ ] Delivered notices/source artifacts and exception/change record.

## Worked fictional decision example

Fictional release: the source repository has an SBOM, but the container includes another dependency added during packaging. The team compares the image inventory with the repository inventory, reviews the extra component’s license and updates the delivered notices. The release record refers to the container digest, preventing approval of one artifact from being silently reused for another.

## Closure check

- [ ] Actual shipped artifact inventoried?
- [ ] Unknown licenses and obligations reviewed?
- [ ] Notices and review match the release digest?

## Official references · checked: 2026-10-11

- [SPDX overview](https://spdx.dev/learn/overview/)
- [ScanCode Toolkit documentation](https://scancode-toolkit.readthedocs.io/en/latest/)
- [Trivy documentation](https://trivy.dev/latest/docs/)