[License Exception Request] [Cozystack] Percona MongoDB operator (Apache-2.0) with SSPL-1.0 deploy-time payload — permitted-interaction confirmation

[kvaps]

For which CNCF project are you requesting exceptions?

Cozystack

Are you an official maintainer of this project?

Yes

List of components requiring an exception

Component	Upstream URL	Project Usage URL	License(s)	Purpose
percona-server-mongodb-operator (vendored Helm chart)	https://github.com/percona/percona-server-mongodb-operator	https://github.com/cozystack/cozystack/tree/main/packages/system/mongodb-operator	Apache-2.0	Operator backing the optional MongoDB catalog app; the only MongoDB-related material in the repository
Percona Server for MongoDB (runtime payload; never in the repository or in project artifacts)	https://github.com/percona/percona-server-mongodb	https://github.com/cozystack/cozystack/tree/main/packages/apps/mongodb	SSPL-1.0	Unmodified upstream image pulled by the user's cluster when a catalog instance is created

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)

Please explain

CNCF-Distributed applies only to the Apache-2.0 operator chart (vendored in the repository and republished within the cozystack-packages OCI packaging artifact). The SSPL payload is User-Fetched only: Cozystack is a platform that lets operators offer managed services from a catalog, and the SSPL-licensed server reaches the user exclusively as an unmodified image their own cluster pulls from Percona's registry at deploy time. The integration is optional, disabled by default, and one of several database options (PostgreSQL, MariaDB, ClickHouse and others); core functionality does not depend on it. No SSPL material exists in the repository or in any artifact Cozystack publishes.

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

Both the operator chart and the payload image are consumed exactly as published upstream.

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

Please explain

The operator chart lives in its own vendored directory (packages/system/mongodb-operator/charts/psmdb-operator); the payload is never stored in the repository.

Communication mechanism

• Static Linking
• Dynamic Linking
• 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

The operator manages the database via the Kubernetes API; the database serves its clients over the MongoDB wire protocol. No linking of any kind occurs.

Data exchange

• Tightly Coupled
• 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

Kubernetes API objects (JSON/Protobuf) and standard network protocols only.

Additional information

This follows up ServiceDesk ticket CNCFSD-3175, where we were asked to file before merging the operator. Per the source-available guidance, an SSPL exception is not eligible — and we are not requesting one; the operator itself is Apache-2.0 and needs none. We ask the Legal Committee to confirm that this profile is a permitted technical interaction under the proprietary interactions guidance, categories 5 and 8. We are adding the prominent disclosure it prescribes, including that operators offering MongoDB-as-a-service are themselves subject to SSPL §13. If the Committee concludes otherwise, we will remove the integration from the CNCF repository.

Unlike foundation#750, where Redis was a required internal dependency of Argo CD, this payload is deploy-only catalog content and never a dependency of the project. The pattern itself is established practice: Vitess (graduated) ships GPLv2 mysqld in its released images, KubeVirt publishes virt-launcher images containing GPL-2.0 QEMU, OpenTelemetry's demo chart enables the AGPL-3.0 Grafana chart by default, and Artifact Hub indexes charts deploying SSPL/SUL products — none with an exception on file. The closest decided case is foundation#461 (Dapr), where an Apache-2.0 operator deploying AGPL-3.0 k6 was approved because the payload "does not get shipped as part of the binaries". Our profile is narrower: nothing non-Apache is redistributed at all.

Cozystack is under Incubation review, so we would appreciate a timely determination.