Third-Party License Attribution#

Third-party license attribution is the process of documenting and distributing copyright notices and license texts for software dependencies in compliance with open-source license requirements. In the context of the opnDossier project, this involves tracking approximately 89 Go dependencies (19 direct, 70 indirect), many of which carry BSD and other permissive licenses requiring attribution in distributed binaries. The project implements both automated SBOM (Software Bill of Materials) generation using cyclonedx-gomod and human-readable THIRD_PARTY_NOTICES file generation using go-licenses.

The opnDossier project's approach exemplifies modern supply chain security practices by integrating license compliance into its CI/CD pipeline as part of a broader Pipeline v2 compliance strategy. This strategy uses both machine-readable artifacts (CycloneDX JSON SBOMs) and human-readable license notices (THIRD_PARTY_NOTICES), enabling automated vulnerability scanning and license policy enforcement through tools like FOSSA while also providing accessible license information for end users. SBOMs are generated at multiple points—locally during development, in CI builds, and during release packaging—ensuring that license information remains current and verifiable.

This article documents opnDossier's dual-track implementation: SBOM generation using cyclonedx-gomod for automated tooling and THIRD_PARTY_NOTICES generation using Google's go-licenses tool for human readability. This hybrid approach satisfies the attribution requirements of BSD and other permissive licenses while providing license information in formats suitable for both automated security scanning and manual review by end users.

Dependency Landscape#

The opnDossier project maintains 19 direct dependencies and 70 indirect dependencies totaling approximately 89 packages. Key BSD-licensed dependencies requiring attribution include:

• spf13/cobra v1.10.2 — CLI framework providing command structure
• spf13/pflag v1.0.10 — POSIX/GNU-style command-line flag parsing
• gorilla/css v1.0.1 — CSS tokenizer and parser
• golang.org/x/* packages — Standard extended libraries (term, text, crypto, exp, net, sync, sys)

The project's dependency tree is tracked through Go's standard go.mod and go.sum files for reproducible builds. All dependencies undergo automated license scanning to ensure compatibility with the project's Apache License 2.0, which permits mixing with BSD-licensed components.

Current Implementation: CycloneDX SBOM Generation#

Overview#

The opnDossier project uses cyclonedx-gomod to generate Software Bills of Materials in the industry-standard CycloneDX JSON format. This approach provides machine-readable license attribution data suitable for automated compliance checking and vulnerability scanning. The project generates two types of SBOMs:

1. Binary SBOMs: Scan compiled binaries per platform/architecture combination
2. Module SBOMs: Analyze the Go module dependency tree including license information

Local Development Workflow#

The just sbom command enables developers to generate SBOM artifacts locally before committing code:

# Generate SBOM with cyclonedx-gomod
[group('security')]
sbom: build-release
    @echo "Generating SBOM..."
    @{{ mise_exec }} cyclonedx-gomod bin -output sbom-binary.cyclonedx.json ./{{ binary_name }}
    @{{ mise_exec }} cyclonedx-gomod app -output sbom-modules.cyclonedx.json -json .
    @echo "✅ SBOM generated: sbom-binary.cyclonedx.json, sbom-modules.cyclonedx.json"

This recipe depends on build-release to ensure a current binary exists, then generates both binary and module SBOMs. The {{ mise_exec }} variable ensures the command uses mise-managed tool versions for consistency.

Release Pipeline Integration#

GoReleaser automates SBOM generation during the release process, creating platform-specific SBOMs for each compiled binary:

sboms:
  - id: binary-sbom
    documents:
      - "{{ .Binary }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}.bom.json"
    artifacts: binary
    cmd: cyclonedx-gomod
    args: ["bin", "-json", "-output", "$document", "$artifact"]
  - id: module-sbom
    documents:
      - "{{ .ProjectName }}_{{ .Version }}_module.bom.json"
    artifacts: any
    cmd: cyclonedx-gomod
    args: ["mod", "-licenses", "-std", "-json", "-output", "$document", "../"]

The -licenses flag in the module SBOM configuration instructs cyclonedx-gomod to include full license information for each dependency. The -std flag includes Go standard library packages in the analysis. Each binary artifact receives its own SBOM, enabling consumers to verify the exact dependencies present in their specific platform build.

Tool Installation#

Unlike most development tools in the opnDossier project, cyclonedx-gomod is installed via go install in CI rather than being managed through mise.toml. This approach ensures the tool is available in GitHub Actions workflows without requiring mise configuration for CI runners.

Pre-Release Validation#

The .goreleaser.yaml pre-hooks execute several preparatory tasks before building release artifacts, including shell completion generation and man page creation. These hooks do not include SBOM generation, as GoReleaser's native sboms configuration handles license attribution automatically during the build process.

License Compliance Strategy#

Automated Policy Enforcement#

FOSSA provides automated license compliance scanning through GitHub App integration. The system enforces an Apache License 2.0 compatibility policy, automatically scanning pull requests and blocking merges if dependencies introduce incompatible licenses. This proactive approach prevents license violations before they enter the codebase, eliminating the need for manual license audits.

SBOM Distribution and Availability#

The project distributes license information through multiple channels:

• SBOMs published alongside release archives, checksums, and Cosign signatures on GitHub Releases
• Release archives include LICENSE, README.md, and CHANGELOG.md files providing user-facing documentation
• SBOMs available as GitHub Actions artifacts with 30-day retention from CI workflow runs
• Scheduled weekly SBOM generation (Sunday midnight UTC) with 90-day artifact retention for historical tracking

This multi-tier distribution strategy ensures license information is accessible to both automated tooling (via JSON SBOMs) and human reviewers (via release documentation).

License Compatibility#

The project's Apache License 2.0 is compatible with BSD licenses, MIT, ISC, and other permissive licenses commonly found in the Go ecosystem. FOSSA's policy engine validates this compatibility automatically, allowing developers to add dependencies without manual license review in most cases.

Human-Readable Attribution: go-licenses and THIRD_PARTY_NOTICES#

The opnDossier project uses Google's go-licenses tool to generate human-readable THIRD_PARTY_NOTICES files that complement the machine-readable SBOMs. This approach provides end users with accessible license information without requiring specialized JSON parsing tools.

go-licenses Tool#

go-licenses is a Google-developed tool for analyzing Go dependencies and generating license reports. Unlike cyclonedx-gomod's machine-readable JSON output, go-licenses can produce human-readable text files suitable for inclusion in software distributions. The tool identifies dependencies, fetches their license texts, and formats them according to user-defined templates.

Template System#

The project uses a Go template file (packaging/notices.tpl) to define the output format for each dependency. The go-licenses tool provides these template fields:

• .Name — Package name/import path (e.g., github.com/spf13/cobra)
• .LicenseName — License type identifier (e.g., BSD-3-Clause, MIT)
• .LicenseURL — URL to the license file in the source repository
• .LicenseText — Full text of the license including copyright notices

The implemented template structure:

THIRD-PARTY SOFTWARE NOTICES AND INFORMATION

This project incorporates material from the projects listed below.
The original copyright notices and license terms are included below.
{{ range . }}
============================================================
Package: {{ .Name }}
License: {{ .LicenseName }}
URL: {{ .LicenseURL }}
------------------------------------------------------------
{{ .LicenseText }}
{{ end }}

Justfile Recipe#

The just notices recipe generates the THIRD_PARTY_NOTICES file as part of the development workflow:

# Generate THIRD_PARTY_NOTICES from dependency licenses
[group('licensing')]
notices:
    {{ mise_exec }} go-licenses report ./... \
        --ignore github.com/EvilBit-Labs/opnDossier \
        --template packaging/notices.tpl > THIRD_PARTY_NOTICES 2>/dev/null

Key command parameters:

• ./... — Scan all packages in the project recursively
• --ignore github.com/EvilBit-Labs/opnDossier — Exclude the project's own code from attribution
• --template packaging/notices.tpl — Use the custom template for formatting
• > THIRD_PARTY_NOTICES — Redirect output to the notices file

The {{ mise_exec }} prefix ensures go-licenses is executed through mise's tool management system, maintaining version consistency across development environments.

GoReleaser Integration#

The .goreleaser.yaml pre-hooks regenerate THIRD_PARTY_NOTICES before building release artifacts:

before:
  hooks:
    - go mod tidy
    - go generate ./...
    - git-cliff --output CHANGELOG.md
    - just notices
    # ... existing hooks for completions and man pages

This hook regenerates THIRD_PARTY_NOTICES immediately before building release artifacts, capturing any dependency changes made during the release preparation process.

Tool Management#

The go-licenses tool is managed through mise.toml for version management:

[tools]
"go:github.com/google/go-licenses" = "1.6.0"

This configuration instructs mise to install go-licenses as a Go binary tool, making it available via mise exec or in shells with mise activated.

Distribution Strategy#

The THIRD_PARTY_NOTICES file is included in release archives and Linux packages alongside existing documentation. GoReleaser's archive configuration bundles:

• LICENSE — Apache License 2.0 project license
• README.md — Project documentation
• CHANGELOG.md — Release notes
• THIRD_PARTY_NOTICES — Dependency attributions

This placement ensures users receive license information with every software distribution, satisfying BSD license requirements for binary distributions. For Linux packages, THIRD_PARTY_NOTICES is installed to /usr/share/doc/opndossier/THIRD_PARTY_NOTICES.

BSD License Compliance Requirements#

Legal Obligations#

BSD licenses (both 2-Clause and 3-Clause variants) impose specific requirements on software redistribution:

1. Copyright notice preservation — The original copyright statement must be retained
2. License text redistribution — The complete license text must accompany the software
3. Binary distribution documentation — For binary distributions, copyright and license information must appear in accompanying documentation or materials

These requirements ensure that end users can identify the origins of the software they receive and understand their rights under the BSD license terms. Projects like opnDossier that incorporate BSD-licensed dependencies must provide this attribution in their release artifacts.

Current Compliance Mechanism#

The opnDossier project satisfies BSD attribution requirements through:

• CycloneDX SBOMs with embedded license texts — Machine-readable JSON files containing complete license information for all dependencies
• THIRD_PARTY_NOTICES file — Human-readable text file with copyright notices and license texts for all dependencies
• FOSSA automated compatibility checking — Prevents introduction of incompatible licenses through CI enforcement
• Apache License 2.0 project license — Permissive license compatible with BSD, MIT, and other common open-source licenses
• Distribution of both SBOMs and THIRD_PARTY_NOTICES alongside binaries — Ensures license information accompanies every release in multiple formats

This dual-format approach provides both machine-readable attribution for automated tooling and human-readable attribution for end users.

Implementation Best Practices#

Eliminate Manual Processes#

Automated license compliance reduces human error and maintenance burden. The opnDossier approach demonstrates key automation principles:

• Local/CI parity through justfile commands — Developers run just sbom and just notices locally to verify license generation before pushing to CI
• Dependabot weekly dependency updates — Automated monitoring of Go modules, GitHub Actions, Docker images, and Dev Containers
• Programmatic license file generation with no manual editing — SBOMs and THIRD_PARTY_NOTICES are always generated from current source code, never hand-crafted

This automation ensures license information stays synchronized with the actual dependency tree, even as dependencies change through updates or additions.

Integrate with Supply Chain Security#

License compliance should not exist in isolation but as part of comprehensive supply chain security:

• SBOMs enable rapid vulnerability response — When security advisories are published, SBOMs allow security teams to immediately determine if affected dependencies are present
• Cosign signatures on SBOMs and binaries — Cryptographic verification ensures SBOMs haven't been tampered with after generation
• FOSSA blocks incompatible licenses at PR time — Prevents license violations from entering the codebase rather than discovering them later

This integrated approach treats license compliance as a first-class security concern, subjecting it to the same rigor as vulnerability management and access control.

Provide Multiple Verification Methods#

The opnDossier project offers developers several ways to verify license compliance:

• just sbom — Generate SBOMs locally to inspect dependency licenses
• just notices — Generate THIRD_PARTY_NOTICES file to review human-readable license information
• just security-all — Run comprehensive security checks including SBOM generation, gosec scanning, and vulnerability detection
• just ci-full — Execute the complete CI validation suite locally before pushing

These commands enable proactive compliance verification during development rather than discovering issues during CI builds or release preparation.

Comparison: SBOM vs THIRD_PARTY_NOTICES#

CycloneDX SBOM Approach#

Advantages:

• Machine-readable format — JSON structure enables automated parsing by security tools, CI systems, and dependency analyzers
• Industry standardization — CycloneDX and SPDX are widely adopted standards with broad tooling support
• Comprehensive metadata — Includes not just licenses but also package hashes, dependencies relationships, and vulnerability data
• Automated tool integration — SBOM scanners can automatically detect license violations, security issues, and supply chain risks
• Security ecosystem compatibility — Works with FOSSA, Snyk, GitHub Advanced Security, and other enterprise security platforms

Disadvantages:

• Human readability challenges — Requires JSON parsing tools or SBOM viewers to extract readable information
• Accessibility barriers — Non-technical users cannot easily review license information
• Tooling dependency — Consumers need specialized software to make use of SBOM data

THIRD_PARTY_NOTICES Approach#

Advantages:

• Immediate readability — Plain text format readable in any text editor without special tools
• User familiarity — Many commercial and open-source projects use this format, making it recognizable to users
• Explicit compliance — Directly satisfies BSD license requirements by presenting copyright notices and license texts
• No tooling required — Users can review licenses without installing parsers or specialized software

Disadvantages:

• Manual maintenance risk — If not automated, THIRD_PARTY_NOTICES files can become stale or incomplete
• Additional tooling — Requires go-licenses or similar tools, adding dependency management complexity
• Data redundancy — Duplicates information already present in SBOMs
• Limited machine processing — Text format not suitable for automated license scanning or policy enforcement

Hybrid Strategy#

The opnDossier project adopts both approaches to maximize benefits:

• CycloneDX/SPDX SBOMs for automated security scanning, vulnerability tracking, and CI/CD integration
• THIRD_PARTY_NOTICES for end-user accessibility, manual review, and explicit license compliance

This combination provides machine-readable data for tooling while ensuring human consumers can easily access license information. The project balances technical rigor with user experience through automated generation of both formats.

Usage Examples#

Generating License Attribution Files Locally#

Developers can generate both SBOMs and THIRD_PARTY_NOTICES before committing code:

# Generate both binary and module SBOMs
just sbom

# Output files:
# - sbom-binary.cyclonedx.json
# - sbom-modules.cyclonedx.json

# Generate human-readable license notices
just notices

# Output file:
# - THIRD_PARTY_NOTICES

The module SBOM contains complete license information extracted from the dependency tree, while the binary SBOM analyzes the compiled executable. The THIRD_PARTY_NOTICES file provides the same license information in a human-readable format.

Running Complete Security Validation#

To verify all security checks pass locally before pushing:

# Run comprehensive security suite
just security-all

# Includes:
# - SBOM generation
# - gosec security scanning
# - License compliance checking
# - Vulnerability detection

# Generate license notices separately if needed
just notices

Verifying License Attribution in Releases#

Release artifacts include both machine-readable and human-readable license information:

1. Download a release from GitHub Releases
2. Extract the archive to find:
   • LICENSE — Project license (Apache-2.0)
   • THIRD_PARTY_NOTICES — Human-readable dependency licenses
   • *.bom.json files — Machine-readable SBOMs
3. Review licenses by opening THIRD_PARTY_NOTICES in any text editor
4. Parse SBOMs using tools like jq or SBOM viewers for detailed analysis

Related Topics#

• Software Bill of Materials (SBOM) — Machine-readable inventory of software components, dependencies, and licenses
• License Compliance Automation — Tools and processes for ensuring open-source license obligations are met
• Supply Chain Security — Practices for securing software dependencies and preventing supply chain attacks
• GoReleaser — Multi-platform build automation tool with native SBOM generation support
• Mise (formerly rtx) — Development tool version management system used by opnDossier
• FOSSA — Automated open-source license compliance and vulnerability scanning platform
• CycloneDX — OWASP-maintained SBOM standard used by opnDossier for license attribution

Relevant Code Files#

Current Implementation#

References#

• Pipeline v2 Compliance Documentation — opnDossier's comprehensive compliance strategy
• Supply Chain Security Documentation — Detailed SBOM generation and security practices
• CycloneDX Specification — OWASP SBOM standard documentation
• go-licenses GitHub Repository — Google's Go dependency license analysis tool
• BSD-3-Clause License — OSI-approved BSD license text and requirements
• SPDX License List — Standardized license identifiers