Tracking License Obligations in Copied Source Snippets

Stripped notices become silent risk

A developer copies a permissively‑licensed utility into a new repository. The original header comment is deleted, the LICENSE file is omitted, and the code is refactored. At the next audit the file is flagged as “unknown origin”. The liability is real: every line that lacks a clear provenance is a potential breach of the upstream licence. The problem is not the licence itself; it is the missing paper trail.

Refactoring erodes ad‑hoc provenance

Most teams track vendored code with a simple folder. The folder may contain a copy of the source and a single LICENSE file at the root. When a file is moved, renamed, or merged into a larger module, the association between that file and its original licence is lost. Automated tools that generate an SBOM will list the component, but without an origin hash or commit reference the SBOM entry is meaningless for compliance. The result is a false sense of security: the SBOM exists, but it cannot be used to prove that the licence terms survive the refactor.

A reproducible record that survives change

The reliable way to keep licence compliance intact is to bind each artefact to an immutable provenance record at the moment it is harvested. The record must contain:

• The exact source commit hash.
• The licence identifier and any required attribution text.
• A checksum of the artefact as it appears in the repository.

When the artefact is later copied or transformed, the provenance record travels with it. A certification harness can re‑execute the artefact against its contract and emit a verdict (CERTIFIED, PROVISIONAL, INCONCLUSIVE, or FAILED). Because the harness runs on the stored artefact, not on a model‑generated guess, the outcome is repeatable and auditable.

In practice this looks like a small JSON file stored alongside the component:

{
  "origin": "git@github.com:upstream/lib.git@a1b2c3d",
  "license": "MIT",
  "checksum": "sha256:9f2e…",
  "verdict": "CERTIFIED"
}

The file can be referenced from an SBOM entry, satisfying the requirement for origin hashes described in our post on “Why an SBOM Without Origin Hashes Is Meaningless”. Tools that ingest the SBOM can verify the checksum against the stored artefact, confirming that the licence text has not been altered.

SHPBL’s answer

SHPBL supplies a model‑independent library of reusable software capability and a method for harvesting more of it from existing repositories. The harvest process registers each component through a Build Intent gate, attaches a verified provenance record, and stores the artefact in a repeatable archive sealed by published checksums. A certification harness then executes the artefact and records a verdict, giving you a concrete licence compliance signal that survives refactoring. You can try the workflow on a single repository for free via our repository evaluation. For ongoing use, the same tools are available through the typed TypeScript client, the HTTP API, or the offline edition, all governed by the same meter. See the full details on the SHPBL home page.