compliance: add release-scoped third-party notice draft for v3.2.3 assembly #2831

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. The TiSpark v3.2.3 Spark 3.0 assembly has no release-scoped third-party notice in its packaged JAR.

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 docs(assembly): add v3.2.3 third-party notice draft #2830 adds the first root third-party notices for this repository:
  • Adds assembly/src/main/assembly/ThirdPartyNotices.txt to the assembly descriptor so the built JAR carries the notice at its root.
  • Draft inventories 92 evidenced payload components against the published v3.2.3 Spark 3.0 assembly baseline (SHA-256 116a2ac7...9eba64) and is explicitly marked DRAFT / NOT APPROVED FOR RELEASE.
  • Owner/compliance review required before release: confirm proposed SPDX expressions (including dual-license choices for JNA, JAXB API, checker-compat-qual), ownership/retention decisions for 16 final legal assets and 29 native assets (incl. Netty tcnative/BoringSSL), and whether tikv-client-java is third-party or first-party.
• Follow-ups: wire the generation into a periodic CI job that opens update PRs, and keep the override/policy inputs versioned in the repository.