[License Exception Request] Prometheus/OpenTelemetry MPL-2.0 (hashicorp/nomad/api)

[dashpole]

For which CNCF project are you requesting exceptions?

Prometheus and OpenTelemetry

Are you an official maintainer of this project?

Yes

List of components requiring an exception

Component	Upstream URL	Project Usage URL	License(s)	Purpose
github.com/hashicorp/nomad/api	https://github.com/hashicorp/nomad/tree/main/api	https://github.com/prometheus/prometheus/tree/main/discovery/nomad	MPL-2.0	Go client library for the Nomad HTTP API, used by Prometheus (discovery/nomad) for Nomad target service discovery and consumed downstream by OpenTelemetry Collector Contrib Prometheus receivers/exporters.

Distribution and integration model

• CNCF-Distributed: The CNCF project will distribute the dependency or the resulting combined artifacts to users.
• User-Fetched Dependency: The CNCF project code will cause the user's system to automatically retrieve the dependency from an upstream source at build, install, or runtime.
• System Component: The CNCF project expects that the dependency will either already be present on the user's system or will be installed independently by the user.
• Not Distributed + Not Needed by End User (Internal Project Tooling): ALL of the following are true:

Please explain

Prometheus and OpenTelemetry Collector Contrib distribute pre-compiled official binaries (prometheus, otelcol-contrib) that incorporate Nomad service discovery. Additionally, developers embedding Prometheus discovery or building custom OpenTelemetry Collectors retrieve this Go module automatically at build time via go build or go get.

Modification status

• Modified Upstream: The CNCF project will patch, alter, or otherwise modify the source code of the dependency and contribute upstream.
• Modified Downstream: The CNCF project will patch, alter, or otherwise modify the source code of the dependency and maintain a downstream fork or local copy.
• Unmodified: The CNCF project will use the dependency exactly as provided by the upstream maintainers without any changes to its source code.

Please explain

The dependency (github.com/hashicorp/nomad/api) is consumed unmodified as an upstream standard Go module dependency.

Structural separation

• Separated Component: The dependency's code will either be (a) kept in a distinct directory or module clearly separated from CNCF project code, or (b) retrieved at build/installation time from a third-party repository and never stored in the CNCF project repository.
• Intermingled Code: The dependency's code will be "mixed in" with CNCF source files, copied into existing project files, or will otherwise lose its distinct directory/module boundary.

Please explain

The dependency is fetched at build time by the Go module toolchain from its third-party repository (github.com/hashicorp/nomad/api) and is never vendored or stored within the Prometheus or OpenTelemetry repositories.

Communication mechanism

• Static Linking: The dependency and the CNCF project code will be combined into a single binary or similar type of artifact during the build process.
• Dynamic Linking: The CNCF project code will interact with the dependency by loading it into the shared address space (memory) at run-time. This includes traditional shared objects compiled into a separate binary, as well as runtime module loading in interpreted or JIT-compiled languages.
• Separate Process: The dependency and the CNCF project code will run as distinct executables and communicate via Inter-Process Communication (e.g., pipes, sockets, or shared files)
• Network Interaction: The dependency and the CNCF project code will be logically and physically separated by a network boundary, with the CNCF project's code acting as a client or consumer of the remote service and interacting with the dependency exclusively via standardized network protocols.

Please explain

Standard Go compilation statically links the dependency into the resulting executable binary (prometheus and otelcol-contrib).

Data exchange

• Tightly Coupled: The upstream dependency and CNCF project code will exchange complex internal data structures such as shared pointers, class instances, or private memory offsets that require extensive knowledge of the other component's internal memory layout.
• Arms-Length Only: The communication between the dependency and the CNCF project code will be limited to standard serialized data (e.g., JSON, XML, or Protobuf) where data is "flattened" for transport and neither component accesses the other's internal memory structures.

Please explain

Prometheus imports github.com/hashicorp/nomad/api directly as a Go library, calling its client functions and interacting with exported Go structs and memory structures (api.Client, api.QueryOptions, etc.) within the same process address space.

Please explain

Most other HashiCorp Go libraries (github.com/hashicorp/consul/api, go-version, golang-lru, errwrap, go-cleanhttp, go-retryablehttp, etc.) already have approved blanket exceptions for all CNCF projects under MPL-2.0. We request that github.com/hashicorp/nomad/api (MPL-2.0) be approved for Prometheus and OpenTelemetry (or added to the blanket exception list for all CNCF projects).

[github-actions]

Automated Triage Summary

Project: Prometheus and OpenTelemetry
Components Requested: 1

---

This issue will be reviewed by the CNCF staff and Legal Committee. See process documentation.