English · 한국어

License notes (third-party & project licensing)¶

What this document is: an accounting of every license pqcota uses internally as of today, organized by how it is consumed. The consumption form matters because license obligations change completely depending on whether something is linked into a distributed binary.

This is the licensing axis: what each dependency is licensed under, and how it is consumed.

§ notation: a §N in this document is a section number of this document.

⚠️ Disclaimer: this document is not legal advice. Before distribution, due diligence by counsel specializing in OSS licensing (GPL vs AGPL, or-later, the exact per-version conditions) is required.

0. The conclusion in one line¶

Every third party linked or bundled into a pqcota product binary is permissively licensed (Apache-2.0 / MIT / BSD-3). Copyleft (GPL and friends) exists only in tools that run as separate processes (Ansible, the JDK in the demo environment); none of it is linked into or bundled with a pqcota binary (§5). What that means under each tool's license is a separate review, not something this document settles.

1. pqcota's own licensing¶

This repo (pqcota) is Apache-2.0. Every third party linked or bundled into the distributed outputs (Go binaries, the Java sidecar) is permissively licensed (the §2 table).

pqcota-cbom-ingest does not run CBOMkit or other GPL-family generators; it only reads the CycloneDX files they produce (delegated CBOM intake design). What that means under those tools' licenses is a separate review (below).

2. Runtime dependencies linked into the build output (Go)¶

Dependencies compiled and linked into the static Go binaries built from this repo (collectors, CLIs). All permissive.

gopkg.in/yaml.v3 (MIT) is not in the list above — it is used only by the demo topology generator and by tests, so it is not linked into the collectors or CLIs.

Summary: no copyleft is linked. Apache-2.0, MIT and BSD-3 are generally treated as compatible with an Apache-2.0 distribution, provided their notices are kept (below). (A distribution has to keep the notices and conditions each license requires: for MIT, its copyright and permission notice; for BSD-3-Clause, its copyright notice, conditions and disclaimer, and it limits using contributors' names to endorse a product. This repo collects them in THIRD-PARTY-NOTICES; that file name is not itself a requirement.)

3. Build-time tools (not linked into the output)¶

Used only for code generation and compilation; not linked into the resulting binaries.

4. Demo environment components (demo/) — separate processes/containers, not linked¶

The components below run in the discovery demo (demo/) over SSH, as subprocesses, or in containers, and are not linked into any pqcota binary.

demo/ operates through containers and separate executables. Nothing there is statically or dynamically linked into a pqcota binary; it all runs beyond an SSH, subprocess, or container process boundary → GPL/copyleft tools there stay separate programs; what their licenses require is reviewed separately (§5).

How the GPL tools (Ansible, Temurin) are treated: these are separate programs pqcota invokes, not link targets. Ansible is the orchestrator that runs playbooks; Temurin is just the runtime on the target node. Whether a use of them creates obligations under the GPL depends on more than how the programs communicate, so that is left to a separate review. With the build procedure provided today, the user downloads these tools when building the image; pqcota does not ship them. If a built container image is distributed, the redistribution terms of what it contains are checked separately.

5. Keeping GPL code separate — what enforces it¶

GPL code is kept apart from pqcota's code and distributions by structure. Three principles (technical measures, not a legal conclusion):

1. Process separation — a GPL component is invoked as an independent binary, never linked as a library.
2. A standard data boundary — inter-process exchange happens only through CycloneDX CBOM (a standard). Core internal APIs never cross it.
3. Distribution separation — GPL code is never bundled, statically linked, or vendored into this repo or its distributions.

The same boundary applies even if we write our own GPL collector. The exact license per component (GPL vs AGPL, or-later) and the AGPL implications for a SaaS deployment require due diligence — this document is not legal advice.

What enforces those principles is the table below.

Ansible (GPL-3) and Temurin (GPLv2+CE) in demo/ likewise run as separate processes outside the same boundary.

This repo is published under Apache-2.0. The point is to open up observability so the community can add collectors, and the reference collectors are OSS for the same reason (including the JVM introspection, which nothing off the shelf covers).

Where the license is stated. Each collector states its license in CollectorCapabilities.license (and Envelope.collector_license), so a caller can show whether a backend means "a GPL component installed separately" or "the reference = Apache-2.0, included".

Appendix: consumption forms at a glance¶