pingcap / pingcap/ticdc

compliance: add root third-party notices for Go dependencies

Open
#6,164 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type/enhancement
Dominant language
Go
Stars
56
Forks
63
Avg merge
2d 20h
Merged PRs (30d)
34

Description

Background

Open-source license compliance requires the source repository itself to carry a complete, redistributable notice for the third-party components it bundles. Apache License 2.0 Section 4(d) requires attribution notices to be passed along with redistribution, and the notice must accurately reflect what is actually shipped. TiCDC currently has no root notice file for its third-party Go dependencies.

Goals

  • Maintain a root ThirdPartyNotices.txt in the repository listing third-party components: names, versions, license identifiers, and license texts, so it can be redistributed with source bundles and release artifacts.
  • The content must be traceable to a fixed source commit and fixed generation inputs (pinned tool version, audited overrides).
  • Updates should be generated by an automated process (periodic, e.g. weekly) rather than manual editing, without blocking on dependency changes.

Approach

  • Collect components and license evidence from the dependency graph (go list -deps ./...), excluding the standard library and first-party modules.
  • The generator is only responsible for discovering and extracting evidence; it does not decide legal matters. Cases it cannot decide (missing license metadata, unusual license choices) are handled by audited, exact-version overrides owned by humans. A renderer produces the final stable file; raw generator output is never used directly as the final notice.
  • Components with unresolved evidence must be recorded explicitly for review, never silently dropped.

Scope of this track

  • PR https://github.com/pingcap/ticdc/pull/6098 adds the first root third-party notices for this repository:
    • Scope: Linux/amd64 go list -deps ./... with tests excluded; 346 components.
    • appdash-data covered by an asset-level inventory at the exact version.
  • Follow-ups: wire the generation into a periodic CI job that opens update PRs, and keep the override/policy inputs versioned in the repository.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review PR 6098 and the root ThirdPartyNotices.txt to understand the existing notice inputs and output. Run the described go list -deps ./... scope, then trace how a periodic CI job could generate updates; done means update PRs are opened automatically and override or policy inputs remain versioned in the repository.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
ci-cd, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.