License Policy

This document is binding on every third-party dependency pulled into the nexus codebase, including transitive dependencies. It is enforced by local license checks for Rust, TypeScript workspaces, and redistributable artifacts; CI/CD wiring is tracked separately.

nexus project license

nexus itself is licensed under Apache License, Version 2.0. See ../../LICENSE.

The choice is backed by ../decisions/0011-license-policy.md.

Third-party dependency allowlist

The following licenses are permitted for dependencies compiled into or distributed with any nexus artifact (binary, container image, Helm chart, air-gap bundle):

• Apache-2.0
• BSD-2-Clause
• BSD-3-Clause
• MIT
• ISC
• Unlicense / CC0-1.0 (public-domain equivalents)
• Zlib
• Unicode-3.0
• 0BSD
• CC-BY-4.0 (browser capability data and similarly low-risk redistributable data)
• CDLA-Permissive-2.0, limited to permissively licensed data bundles such as root certificate data. New dataset uses outside that scope require ADR-backed review.

SPDX identifiers are the source of truth. A dependency that declares multiple licenses via OR is acceptable if at least one is on this list; a dependency that declares AND must have every listed license on this list.

Dependency-specific exceptions

• aws-lc-fips-sys version 0.13.15 may use the OpenSSL license as part of its conjunctive license expression. This exception applies only to that exact crate version for the FIPS build described by ../decisions/0021-fips-build-support.md; it does not add OpenSSL to the general allowlist.
• khroma version 2.1.0 is treated as MIT. Its published package.json declares no license field, so pnpm licenses list reports it as Unknown, which the enforcement script otherwise fails on. The license was validated by hand against the package’s upstream repository and the license file in its published tarball, both of which carry the MIT text. This exception applies only to that exact package version, is enforced by the licenseOverrides map in ../../scripts/check-node-licenses.mjs, and does not relax the rule that an unknown license text fails the check. khroma reaches the console as a transitive dependency of mermaid by way of streamdown; removing that path removes the need for this exception.
• victory-vendor version 37.3.6 declares the compound license MIT AND ISC. Both MIT and ISC are independently on the allowlist above, so per this document’s own AND rule (“must have every listed license on this list”), the combination is already compliant; it is recorded here only because the exact-match allowedExpressions list in the enforcement script had not previously seen this specific string. This is enforced by an entry in allowedExpressions in ../../scripts/check-node-licenses.mjs, not the licenseOverrides map (no override of the reported license is happening; the reported string is accepted as-is). victory-vendor reaches the console as a transitive dependency of recharts. The enforcement script currently checks compound license expressions by exact string match rather than by decomposing AND/OR into individual licenses and checking each against the allowlist; that generic-parsing improvement is tracked as follow-up work, not part of this exception.

Forbidden licenses

The following licenses are not permitted in any runtime or distributable artifact:

• AGPL-3.0 (and all AGPL variants). Linked-only use may be considered case-by-case with security-team approval and an ADR.
• SSPL-1.0 (Server Side Public License).
• BUSL-1.1 (Business Source License). Even after the Change Date, BUSL dependencies require an ADR.
• Commons Clause (any base license with this additional restriction).
• Proprietary / “source-available” licenses that forbid redistribution, forbid modification, or add field-of-use restrictions.
• GPL-2.0 and GPL-3.0 in a form that would subject nexus to copyleft obligations (dynamic linking from an Apache-2.0 binary is considered a compatibility problem we avoid by default).

A dependency that is GPL-compatible but introduces additional restrictions (patent retaliation beyond Apache-2.0, advertising clauses, etc.) requires an ADR before adoption.

Dev-time-only exceptions

Tooling that is never shipped (e.g. a build-time code generator, a CI-only linter) may use any OSI-approved license, provided:

1. The dependency is marked dev-only in the relevant manifest ([dev-dependencies] in Cargo, devDependencies in package.json).
2. CI verifies that the dependency does not appear in any release artifact.
3. The dependency does not perform any network call that touches nexus source at build time.

Additions to the allowlist

Adding a license to the allowlist requires:

1. A short ADR under ../decisions/ explaining the need, the risk, and the mitigations.
2. Sign-off from the security reviewer listed in ../../CONTRIBUTING.md.
3. An enforcement update to teach the local license checks about the new entry.

Local enforcement

Local checks:

• cargo deny check licenses — the deny.toml allowlist is the Rust subset of this document’s list (0BSD and CC-BY-4.0 occur only in the Node graph and are enforced by scripts/check-node-licenses.mjs).
• Node license checks (scripts/check-node-licenses.mjs) run against each package that ships to production.
• Redistributable artifact checks must fail on unknown license texts and on dev-only images entering a bundle.

A change that introduces a dependency whose license is not on the allowlist must do one of:

• drop the dependency,
• switch to a permitted alternative,
• open an ADR asking for an allowlist addition (as described above).