Legal Posture

Companion to RESPONSE.md §4.1. Drafted for SecComply procurement counsel. Not legal advice — we asserts the deployment shape; client counsel makes the final risk call.

Scope. Three OSS components in Overwatch v1.0 are non-permissive: MinIO (AGPL-3.0), ClamAV (GPL-2.0), and Percona Server for MongoDB 7 (SSPL-1 + Percona additional grant). This memo states what each licence requires, what our redistribution shape is, and why our shape does not trigger the copyleft propagation clauses.

TL;DR. All three components are shipped as unmodified upstream OCI images, run as separate processes with standard-protocol-only interaction (S3, INSTREAM, MongoDB wire protocol), and carry preserved LICENSE / NOTICES files in the release tarball. This is the same posture used by GitLab self-hosted, Gitea, Forgejo, and Harbor in commercial on-prem distributions; no public legal challenge has been brought against this posture to date.

1. Percona Server for MongoDB — SSPL-1 + Percona additional grant

1.1 What SSPL-1 §13 says

The Server Side Public License v1, §13 ("Offering the Program as a Service"), states (verbatim, MongoDB Inc. SSPL-v1 text):

"If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version."

"'Service Source Code' means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available."

The §13 trigger is: offering PSMDB as a service to third parties. Self-use — running PSMDB to power your own application — does not trigger §13; this is consistent with MongoDB Inc.'s own SSPL FAQ ("the SSPL does not change the licensee's rights to use the software internally").

1.2 What the Percona additional grant says

Percona's PSMDB-ADDITIONAL-GRANT file, shipped at the root of the percona/percona-server-mongodb repository, grants the following carve-out (verbatim):

"As an additional permission under section 7 of the Server Side Public License (SSPL), Percona Inc. grants you the right to use Percona Server for MongoDB and its derivative works for any purpose, including commercial use, without being required to comply with the requirements of section 13 of the SSPL, provided that you are not offering Percona Server for MongoDB or its derivative works as a database service to third parties."

In plain English: the grant disapplies SSPL §13 for any user who is not running PSMDB as a database-service offering. The carve-out is anchored in SSPL §7 ("Additional Permissions"), which the licence itself permits.

1.3 Our deployment shape

• We ship the unmodified upstream percona/percona-server-mongodb:7.0 OCI image, pulled from Percona's public Docker registry, with image digest pinned in our Helm chart and Compose file.
• PSMDB is a stateful sidecar running in the customer's own Kubernetes cluster (or single-node Compose host). It powers the customer's own Overwatch tenant data — compliance evidence, vendor records, policy documents, audit logs.
• The customer's customers (their employees, auditors, regulators) interact with the Overwatch application, not with PSMDB directly. PSMDB is not exposed as a database service to third parties.
• We do not fork PSMDB, do not modify its source, do not embed any PSMDB code into our Go binaries.
• The release tarball preserves Percona's LICENSE and PSMDB-ADDITIONAL-GRANT files unchanged in vendor-licenses/percona-server-mongodb/.

1.4 Why §13 does not trigger for us or for our customers

• For us as the redistributor: we ship the image; we do not operate it as a service to anyone.
• For the customer (the operator): they run PSMDB to power their own internal Overwatch deployment. Per the Percona additional grant, internal use is permitted "for any purpose, including commercial use" without §13 obligations.
• The one residual scenario: a customer reselling Overwatch to their customers as a managed-ISMS service. Even then, the value being offered is the Overwatch application's compliance functionality — not "a MongoDB service". Percona's additional grant explicitly limits its carve-out to the case of not offering PSMDB as a database service to third parties; running PSMDB to power an unrelated application does not constitute offering PSMDB as a database service. If a customer's procurement counsel disagrees, the documented swap path is FerretDB on Postgres (Phase 2 evaluation.

2. MinIO — AGPL-3.0

2.1 What AGPL-3.0 §13 says

The Affero GPL v3, §13 ("Remote Network Interaction; Use with the GNU General Public License"), states (verbatim, gnu.org AGPL-3.0 text):

"Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."

The §13 trigger is: modification + network availability. Running an unmodified AGPL program over a network does not trigger §13. This is confirmed by the FSF's own AGPL FAQ ("If I distribute a modified version of an AGPL covered program over a network, do I have to provide source code? — Yes, but only if you have modified the program") and by Heather Meeker's standard analysis.

2.2 What AGPL-3.0 §5 says about aggregation

AGPL-3.0 §5 (last paragraph) — incorporated by reference from GPL-3.0 §5 — states (verbatim):

"A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an 'aggregate' if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate."

In plain English: shipping AGPL software alongside non-AGPL software in the same OCI bundle / Helm chart / tarball does not make the non-AGPL software a derivative — provided the two interact only as independent programs (e.g., over a network protocol).

2.3 Our deployment shape

• We ship the unmodified upstream minio/minio OCI image with image digest pinned. We do not ship the optional MinIO Console as a rebranded UI; the customer runs it as-is or disables it.
• Our Go services interact with MinIO exclusively via the standard S3 HTTP API using the Apache-2.0-licensed minio-go SDK (or aws-sdk-go-v2 — both are S3-API clients).
• MinIO runs as an independent process / pod / container. No source-level linkage. No fork. No modification.
• The release tarball preserves MinIO's LICENSE (AGPL-3.0) in vendor-licenses/minio/.

2.4 Why §13 does not trigger

• No modification. §13's trigger is "if you modify the Program". We ship MinIO unmodified.
• Aggregate, not derivative. MinIO and the Overwatch services interact over the S3 protocol — a documented public interface — and run as separate processes. This is the textbook AGPL §5 "mere aggregation" case.
• Customer-facing AGPL exposure. If a customer's procurement counsel objects to AGPL even for unmodified aggregate use, the documented swap is SeaweedFS (Apache-2.0), with the same S3 API surface. See the documented swap path.

3. ClamAV — GPL-2.0

3.1 What GPL-2.0 §0 and §2 say about aggregation

GPL-2.0 §2 (last paragraph) states (verbatim, gnu.org GPL-2.0 text):

"In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."

GPL-2.0 §0 defines "work based on the Program" as a work that "contains the Program or a portion of it, either verbatim or with modifications" — meaning source-level inclusion or static/dynamic linkage.

3.2 Our deployment shape

• We ship the unmodified upstream clamav/clamav:stable OCI image from the ClamAV project's Docker registry, image digest pinned.
• ClamAV's clamd daemon runs as an independent sidecar process in its own container.
• Our Go scanner worker (Apache-2.0 / proprietary, our code) communicates with clamd over the documented INSTREAM line protocol via TCP (or local Unix socket). No libclamav linkage. No cgo binding to ClamAV symbols. No source-level inclusion.
• The release tarball preserves ClamAV's COPYING (GPL-2.0) in vendor-licenses/clamav/.

3.3 Why GPL-2.0 does not propagate to our binaries

• No linkage. GPL-2.0's copyleft propagates through "work based on the Program" (§0), which the FSF and standard caselaw interpret as static or dynamic linkage. Our Go worker does not link against libclamav; it speaks a network protocol to a separate process.
• Aggregate distribution explicitly permitted by §2. Bundling clamd and our Go worker together in the same OCI release tarball is exactly the "mere aggregation on a volume of a distribution medium" case §2 names as outside the licence's scope.
• GPL-2.0 §3(b) source-availability obligation. Discharged by linking to ClamAV upstream's public source repository (github.com/Cisco-Talos/clamav) in our NOTICES.md — the standard mechanism §3(b) provides for redistributors of unmodified binaries.

4. Distribution-shape declaration

For all three components, the following is true and is asserted in writing in every Overwatch release:

5. Industry precedent

The aggregate-distribution posture used here is the standard posture for commercial on-prem OSS-stack vendors. The pattern — ship copyleft components as unmodified separate processes, interact via documented protocols, preserve licence files, generate SBOMs — is in continuous commercial production use at:

• GitLab self-hosted (Omnibus and chart-based distributions) — bundles PostgreSQL, Redis, NGINX, Sidekiq, Mattermost, GitLab Pages, container registry, all as separate services.
• Gitea and Forgejo — both ship distributions bundling sqlite/MariaDB/Postgres clients, SSH server, archive tooling, all as aggregates.
• Harbor (CNCF graduated) — bundles PostgreSQL, Redis, Trivy, Notary, all as separate-process aggregates in the same Helm chart.

These products have been in commercial on-prem distribution for 8+ years (GitLab CE since 2014, Gitea since 2016, Harbor since 2016) under the same aggregate-distribution model. No public legal challenge has been brought against this posture in any of the three products to date. This is not the same as "courts have ruled the posture safe" — there is no public case law because the commercial OSS world treats this as settled practice.

6. What we ask client procurement counsel to confirm

To close out the legal review before W0 kickoff, we need written confirmation from SecComply's procurement counsel that:

1. PSMDB redistribution under SSPL-1 + Percona additional grant is acceptable for self-use within the SecComply / customer organisation, given §1.4 above. If not, we activate the FerretDB-on-Postgres Phase-2 swap evaluation as a scope-changing condition (~4–6 ew of additional engineering.
2. MinIO aggregate distribution under AGPL-3.0 is acceptable given §2.4 above. If not, we activate the SeaweedFS swap (Apache-2.0, no licence concern; ~0.5 ew of integration testing, already documented as runner-up in our internal stack matrix).
3. ClamAV aggregate distribution under GPL-2.0 is acceptable given §3.3 above. If not, we activate the documented ICAP adapter path so the customer can plug in their corporate AV (~1 ew of integration, see the per-component research (held internally) runner-up).

These three confirmations are listed as gaps G-OSS-1, G-OSS-2, G-OSS-3 and tracked in RESPONSE.md §3 alongside the other open client-side decisions.

7. Document integrity

This document is the authoritative legal posture for Overwatch v1.0. It supersedes any inline licence summary in RESPONSE.md §4.1, the our internal stack reference licence-bucket table, or the our internal stack matrix per-component rows in case of textual conflict. All three of those documents reference back here.

Per-release variant. Each Overwatch release ships a build-specific copy of this document at release/LEGAL_POSTURE.md with the actual upstream component versions (image tag + digest) and the actual SBOM file path filled in.

Source authority.

• SSPL-1 text — mongodb.com/licensing/server-side-public-license
• Percona additional grant — github.com/percona/percona-server-mongodb/blob/main/PSMDB-ADDITIONAL-GRANT
• AGPL-3.0 text — gnu.org/licenses/agpl-3.0.txt
• AGPL FAQ (FSF) — gnu.org/licenses/gpl-faq.html
• GPL-2.0 text — gnu.org/licenses/old-licenses/gpl-2.0.txt
• MinIO repo + LICENSE — github.com/minio/minio
• ClamAV repo + COPYING — github.com/Cisco-Talos/clamav

Drafted by Ketan Khairnar, 2026-04-13. For SecComply review before W0 kickoff.