Automated License Inheritance Mapping for Vendored Code

Most vendor/ directories are maintained by accretion. A developer needed an unreleased bugfix three years ago, copied a subfolder from upstream, stripped the build scripts, and committed the raw source files. The top-level repository had an MIT licence, so the PR was merged without scrutiny.

Two years later, an audit reveals that a sub-module tucked inside that folder contains code pulled from an MPL-2.0 or AGPL-3.0 project. Because the files were pasted directly into the tree, the build system compiles them directly into the primary binary.

As we covered when explaining why vendoring code without a paper trail is unsecured debt, copying source without tracking its origin leaves you with an unhedged compliance liability. To resolve this, compliance automation must evaluate license inheritance down to the individual file path.

The mechanics of license inheritance

A top-level licence file in a vendored package only covers what the original author owned. If that author bundled third-party utilities into their own tree, their licence does not extinguish the upstream obligations.

When you vendor code, you inherit a tree of terms:

1. Root terms: The licence declared in the upstream repository’s root LICENSE or package.json.
2. File-level overrides: Headers within specific files (SPDX-License-Identifier) that alter or restrict terms for particular algorithms.
3. Transitive vendoring: Dependencies that the upstream package vendored into its own internal subdirectories.

Resolving these terms manually does not scale. You need an automated parser that walks the vendored directory, evaluates SPDX headers alongside parent licences, and produces an unambiguous SBOM mapping for every physical file on disk.

{
  "path": "vendor/crypto/internal/poly1305/poly1305_arm64.s",
  "origin": {
    "repository": "github.com/golang/crypto",
    "commit": "c05e3f169fcb6045d90e2418e26aa54605e54d66"
  },
  "declared_license": "BSD-3-Clause",
  "effective_license": "BSD-3-Clause",
  "inheritance_path": [
    "github.com/golang/crypto:BSD-3-Clause"
  ]
}

If a file lacks an explicit header, the tool assigns the root licence of the nearest parent directory that contains a manifest. If that manifest references external components, the inheritance chain must resolve them before assigning an effective_license.

Enforcing inheritance rules in CI

Once you have a machine-readable manifest for your vendored code, you can enforce policy gates inside your continuous integration pipeline.

A compliance gate should verify two invariants on every pull request that touches the vendor/ directory:

1. No unmapped paths: Every file under the vendor prefix must map to a known upstream commit and a resolved effective licence.
2. Policy conformance: The effective licence must belong to your organisation's allowlist for the target distribution tier (e.g., permissive for proprietary commercial artifacts; copyleft allowed only in internal CLI tooling).

#!/usr/bin/env bash
set -euo pipefail

## Generate the current inheritance map for vendored code
vendor-mapper --dir=./vendor --output=dist/vendor-sbom.json

## Validate against organisation policy rules
compliance-eval \
  --sbom=dist/vendor-sbom.json \
  --deny-licenses="GPL-2.0-only,GPL-3.0-only,AGPL-3.0-only" \
  --require-origin-commit

If a contributor vendors a utility that brings transitive copyleft obligations into a proprietary build target, the pipeline fails immediately. The failure is concrete: it outputs the offending file path, the upstream commit it was copied from, and the specific licence rule it violated.

How SHPBL manages provenance

SHPBL eliminates the guesswork of vendored code by ensuring every reusable component has a strictly verifiable paper trail. Every write an agent performs passes a Build Intent gate first: the proposal is registered, the invariants and licensing are resolved in code, and a terminal state is returned.

The corpus is model-independent. No AI model runs inside our software, and runtime behaviour is computed rather than generated. We distribute release archives sealed by published checksums linked to our root of trust. If you want to see where your current codebase stands, start with a free repository evaluation.

What to audit on Monday

Do not wait for an acquisition audit or an enterprise vendor review to map your supply chain. On Monday morning, take these steps:

1. Locate all vendored source: Run git ls-files across directories like vendor/, third_party/, or pkg/deps/.
2. Flag missing SPDX headers: Search for files in those trees that lack an inline licence identifier or an upstream origin comment.
3. Extract top-level terms: Check if any upstream repository contains sub-components with mismatched licences.
4. Automate the check: Add a basic map validation step to CI to prevent unindexed code from entering your main branch.