Skip to content

Automate third-party notice generation #227

@rdeago

Description

@rdeago

Reference version

1.0.154-preview

Background and motivation

Third-party notice generation and maintenance is a huge burden, especially if one wants to stay on the safe side by including license information for all distributed third-party code, including transitive dependencies.

THIRD-PARTY-NOTICES.md needs to be generated automatically from the resolved NuGet dependency graph as part of the pack pipeline.

Note

A proper Software Bill of Materials is beyond the scope of this issue; however it's worth mentioning, as tooling choices made now may affect the feasibility of adding SBOM generation later.

Proposed enhancement

Upon pack1, Buildvana SDK should generate / update THIRD-PARTY-NOTICES.md, using either the resolved NuGet dependency graph, or the list of files to be shipped.

Implementation proposals

Approach

Immediately before packing each project (in a target with BeforeTargets="Pack"):

  • Check whether the GenerateThirdPartyReferences property is set to true (it should default to true for packable projects); otherwise, skip third-party reference generation without a warning.
  • Check whether nuget-license is installed in the project(or globally) in a known /compatible version; otherwise, issue a warning.
  • Check whether another third-party notice file (THIRD-PARTY-NOTICES, THIRD-PARTY-NOTICES.txt, or whatever defined by the PackageThirdPartyNoticeFile property) exists and was not automatically generated (YAML front matter may help in marking automatically-generated files); if so, issue a warning and skip subsequent steps.
  • Check whether a third-party notice file (THIRD-PARTY-NOTICES or THIRD-PARTY-NOTICES.txt) exists; if so, issue a warning and skip subsequent steps.
  • Use a compiled MSBuild task to invoke nuget-license as a subprocess, consume its JSON output, and emit project-level third-party reference information.
  • Structure the task as a thin orchestrator over two internal components: an invoker (runs the tool, returns parsed JSON) and a formatter (pure function from JSON schema to Markdown). The formatter must be unit-testable against canned fixtures without nuget-license present.

bv pack should gather generated information and produce the final repo-level Markdown file.

Design notes

  • Define a merged intermediate schema distinct from nuget-license's JSON, so additional sources (manual entries, overrides, non-NuGet components) can be folded in without coupling the formatter to the tool's output shape.
  • License text resolution: prefer embedded LICENSE from the .nupkg → fall back to canonical SPDX text → flag as "needs manual review" otherwise.
  • Sort deterministically at every level (packages, licenses within a group, everything). Non-determinism breaks the CI diff check.
  • Support grouping by license + copyright holder, or by project family (e.g., all Microsoft.Extensions.* under one entry). Data model should allow it from v1 even if unused initially.
  • TOC conditional on entry count (threshold ~20).
  • Scope is direct dependencies only; transitive dependencies (including packages referenced solely to override vulnerable transitive versions, tracked via Bv* metadata) are excluded. Document this policy at the top of the generated file.
  • Graphics attributions remain in a separate, hand-maintained THIRD-PARTY-GRAPHICS.md. Same for any other non-NuGet components (fonts, vendored source) if volume warrants.

Further enhancements

  • Generation of project-level third-party notices should be possible, enabled via another MSBuild property.

Out of scope for this issue

  • SBOM generation (see background section).
  • License compliance policy enforcement (allow/deny lists) — can be added later using the same nuget-license infrastructure.

Usage examples

No usage example necessary, as third-party notice generation should be enabled by default for packable projects.

Risks

  • Third-party notice generation might take a while, especially on CI. If complete automation breaks the CI bill, maybe make a bv subcommand instead of (or in addition to) the pre-pack task.
  • Added build-time dependency on nuget-license might not be well-received by some users (they can easily set GenerateThirdPartyReferences to false in Common.props though).

Additional information

No response

Footnotes

  1. "Pack" here is intended as whatever the "Pack" task is redefined to (e.g., installer generation).

Metadata

Metadata

Assignees

Labels

area:code[issue/PR] affects project code (excluding tests).enhancement[issue/PR] requests / implements new or improved functionality.
No fields configured for Feature.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions