Licensing

CommonLayer involves several layers of software, and each has its own license. Applying Apache-2.0 to a Dockerfile does not relicense what the image contains. This guide explains which license applies to the platform, the project template, a project's build configuration, its Helm chart, the components inside an image, and the upstream application, and how the repository records them.

This is an explanation of how the repository is set up, not legal advice.

The layers

Layer	Example	License	Where it is recorded
The platform	`crates/`, `apps/`, `infrastructure/`, `docs/`	Apache-2.0	root `LICENSE` and `NOTICE`; `license = "Apache-2.0"` in `Cargo.toml`
The project template	`templates/project-template/`	Apache-2.0	the template's own `LICENSE` and `NOTICE`
A project's build configuration	Dockerfile, entrypoint, scripts, tests, workflows of the project's repository (for example `commonlayer-org/nginx`)	Apache-2.0	the project's `LICENSE`; `metadata.license` in `commonlayer.yaml`
A project's Helm chart	`chart/` of the project's repository	Apache-2.0 (part of the build configuration)	the project's `LICENSE`
The upstream application	nginx, PostgreSQL, Valkey	the upstream's license (BSD-2-Clause for nginx, the PostgreSQL License, BSD-3-Clause for Valkey)	`upstream.license` (SPDX) in `commonlayer.yaml`; the project's `NOTICE` and README; the license text in the image under `/usr/share/licenses/`
Bundled components	musl (MIT), BusyBox (GPL-2.0-only), OpenSSL (Apache-2.0), zlib, PCRE2, ICU, tzdata, CA certificates	each component's own license	the SBOM; `THIRD_PARTY_LICENSES.md` generated per release; texts under `/usr/share/licenses/`

The decision to use Apache-2.0 for everything CommonLayer authors is ADR-0016.

What each project states

Every project README states the three layers separately: the license of the build configuration, the license of the upstream application, and the licenses of bundled components, pointing to the generated inventory. Each project's NOTICE carries upstream attribution. For example, templates/project-template/NOTICE names darkhttpd (ISC) and the base image's components (musl MIT, BusyBox GPL-2.0-only, ca-certificates MPL-2.0 AND MIT, tzdata public domain, cl-probe Apache-2.0).

Inside an image

/usr/share/licenses/ holds the upstream application's license file, BusyBox's own license, an SPDX expression per Alpine package and the SPDX reference texts. It does not hold the individual copyright notices of every Alpine package (WP-20 deviation).
The base image keeps the apk package database, so scanners and SBOM tools can identify every package and its declared license.
BusyBox is GPL-2.0-only. CommonLayer rebuilds it from Alpine's published source and patches (ADR-0020); the source comes from Alpine's aports at a pinned commit and from busybox.net. Distributors of images containing GPL components have source-availability obligations; how the operating entity meets them (for example by publishing the source archives used for each release) is not yet documented by a release process.

The license inventory and allowlist

scripts/generate-license-inventory.sh (in the template and every project; make licenses) derives THIRD_PARTY_LICENSES.md from the SPDX SBOMs and fails when a component has no license data or a license outside the project's allowlist:

security/license-allowlist.txt: one SPDX id per line; without it a default list applies (Apache-2.0, BSD-2-Clause, BSD-3-Clause, GPL-2.0-only, GPL-2.0-or-later, LGPL-2.1-only, LGPL-2.1-or-later, MIT, MPL-2.0, ISC, Zlib, OpenSSL, PostgreSQL, Unicode-3.0, Unicode-DFS-2016, curl, X11, 0BSD and public domain identifiers).
security/license-overrides.txt: <purl without version> <SPDX expression> lines for components built from source whose SBOM entry carries no license (for example pkg:generic/nginx BSD-2-Clause); overridden licenses are marked "(reviewed)".

The release workflow publishes the inventory with each GitHub release (THIRD_PARTY_LICENSES.md next to the SBOM archive).

Upstream licenses and candidates

Whether CommonLayer can build an application at all depends on its upstream license. The Bitnami migration catalog proposes this rule (awaiting governance confirmation): an OSI-approved upstream license is required for redistribution; SSPL, RSAL, Elastic License and BUSL lead to status blocked; an unmaintained upstream leads to not_suitable. See projects/bitnami-migration/README.md.

Contributions to this repository

Contributions to this repository are accepted under Apache-2.0 (see CONTRIBUTING.md). Do not copy Dockerfiles, chart templates, scripts, helper-library names, logos or wording from other image catalogs, including Bitnami; implementations derive from the upstream projects.