Principle:Triton inference server Server Copyright Management

Overview

The Copyright Management principle governs how the Triton Inference Server project enforces consistent copyright and license headers across its entire source tree. Every source file in the repository -- whether Python, C++, Shell, YAML, Dockerfile, reStructuredText, HTML, or Markdown -- must carry a properly formatted BSD 3-Clause license header with an accurate NVIDIA copyright year. This principle is implemented through two complementary tools: an additive tool that inserts or updates copyright headers in source files, and a verification tool that scans the repository to detect missing or malformed headers.

Theoretical Basis

Why copyright headers matter in open-source projects

Copyright headers serve multiple purposes in a large open-source project:

Legal compliance: The BSD 3-Clause license used by Triton requires that redistributions in source form retain the copyright notice. Without headers in individual files, files extracted or copied out of the repository lose their license attribution.
Provenance tracking: The copyright year range (e.g., 2018-2025) documents when a file was first created and when it was last substantively modified. This provides a coarse-grained history of file authorship beyond what Git logs offer.
Contributor clarity: The explicit attribution to "NVIDIA CORPORATION & AFFILIATES" makes it unambiguous who holds the copyright, which simplifies due diligence for downstream consumers and integrators.
Automated enforcement: By encoding the copyright policy in tooling rather than relying on developer memory, the project ensures that every committed file meets the standard regardless of who authored it.

The BSD 3-Clause license structure

Triton uses the BSD 3-Clause ("New BSD") license, which consists of:

A copyright line identifying the holder and year(s).
A redistribution clause permitting source and binary redistribution under three conditions.
A disclaimer of warranties and limitation of liability.

The full license body is maintained in the root LICENSE file and is reproduced (with appropriate comment prefixes) in every source file. The copyright management tooling reads this canonical LICENSE file at runtime to ensure that the body text inserted into source files always matches the authoritative version.

File-type-aware header insertion

Different file types require different comment syntax. The additive tool (tools/add_copyright.py) uses a registry pattern where file type handlers are registered with path-matching predicates:

File Type	Comment Prefix	Special Handling
Python, Shell, YAML, pbtxt, CMakeLists.txt, Dockerfiles	`#`	Insert after shebang line (`#!`) if present
C++ source and headers (`.cc`, `.h`)	`//`	Insert at file beginning
HTML and Markdown (`.html`, `.md`)	`<!--\n# ... \n-->`	Wrapped in HTML comment block
reStructuredText (`.rst`)	`..`	Uses reST comment directive syntax
Template files (`.tpl`)	`Principle:Triton inference server Server Copyright Management/*\n`	Wrapped in Go template comment block

This approach uses a decorator-based registration mechanism:

@register(
    any_of(
        has_ext([".py", ".pyi", ".sh", ".bash", ".yaml", ".pbtxt"]),
        basename_is("CMakeLists.txt"),
        path_contains("Dockerfile"),
    )
)
def py_or_shell_like(path):
    update_or_add_header(
        path,
        prefix_lines(LICENSE_TEXT, "# "),
        insert_after(r"#!(.*)\n"),
    )

The insert_after function is a higher-order function that returns a callback. This callback locates the shebang line via regular expression and inserts the copyright header immediately after it, preserving the shebang's position at line 1 (which is required by the operating system's script interpreter).

Copyright year management

The additive tool handles three year-related scenarios:

New file (no existing copyright): Inserts a header with the current year as a single value (e.g., Copyright (c) 2025).
Existing copyright with an older year: Updates to a year range (e.g., Copyright (c) 2018 becomes Copyright (c) 2018-2025).
Existing copyright with a year range: Updates the upper bound of the range (e.g., Copyright (c) 2018-2023 becomes Copyright (c) 2018-2025).

The year detection uses the regular expression pattern:

COPYRIGHT_YEAR_PAT = re.compile(
    r"Copyright( \(c\))? (\d{4})?-?(\d{4}), NVIDIA CORPORATION"
)

This pattern accommodates both the (c) symbol and its absence, single years and year ranges, ensuring broad compatibility with existing headers across the repository's history.

Verification and CI enforcement

The verification tool (qa/common/check_copyright.py) performs a complementary role. Rather than modifying files, it walks the repository tree and validates that every source file:

Has a copyright line matching the expected regular expression pattern.
Contains the full BSD 3-Clause license body with correct formatting.
Uses copyright years that are logically consistent (start year does not exceed current year, years are strictly increasing in ranges).
Uses the correct comment prefix for its file type.

The tool maintains explicit skip lists for file extensions (binary formats like .jpeg, .png, .onnx, .pdf) and repository paths (build artifacts, third-party vendored content, generated model files, and other non-source assets). This prevents false positives from files that should not carry copyright headers.

The verification tool returns a non-zero exit code when any file fails validation, making it suitable for integration into CI/CD pipelines and pre-commit hooks. This ensures that copyright violations are caught before code is merged.

Idempotency and safety

Both tools are designed to be idempotent. Running the additive tool on a file that already has a correct, current-year copyright header produces no changes. The tool includes a safety check that verifies the string "Copyright (c)" appears exactly once in the file after processing; if it appears zero times or more than once, a warning is emitted to alert the developer to a potential double-insertion or format mismatch.

The additive tool deliberately does not run git add on modified files, ensuring that developers can review changes via git diff before staging them. This design choice trades a small amount of convenience for better visibility into automated modifications.

Page Connections

Double-click a node to navigate. Hold to expand connections.

Principle

Implementation

Heuristic

Environment