License Compliance & Open-Source Hygiene¶
MoE Sovereign is published under Apache 2.0. Every component we ship, embed, or recommend must be compatible with that licence and — more strictly — must remain OSI-approved Open Source. This page is the canonical reference for tool selection, dependency vetting, and the operator-facing legal posture.
Scope. This page applies to
moe-sovereign,moe-libris, andmoe-codexequally. Differences (if any) are called out explicitly.
1. The Linux-Foundation-Fork principle¶
Mandatory rule: Whenever an open-source tool relicenses to a non-OSI-compatible form (BSL, SSPL, Confluent Community Licence, Elastic License v2, RSALv2, "Source-Available" without OSI approval), we evaluate the Linux-Foundation- or community-driven OSI-compatible fork and prefer it — even if it lags the original by a few features.
Why: Vendor relicensing weaponises lock-in. Linux-Foundation forks exist precisely because the community pre-empted that risk. Their governance is transparent, their roadmap public, and their long-term licence stability is structurally protected.
Already applied in the stack:
| Original | Relicense / EOL | We use |
|---|---|---|
| Redis 7.4+ | RSALv2/SSPL | Valkey (BSD-3-Clause, Linux Foundation) |
| Confluent Kafka | Confluent Community Licence | Apache Kafka (Apache 2.0) |
| MinIO | Archived 2026-04-25 (EOL — no further security patches) | Garage (AGPL-3.0, Deuxfleurs French non-profit, EU-sovereignty fit) |
Pre-approved replacements for the moe-codex stack expansion:
| Original | Relicense | We will use |
|---|---|---|
| Elasticsearch ≥ 7.11 | SSPL/Elastic 2.0 | OpenSearch (Apache 2.0) |
| Terraform ≥ 1.6 | BSL 1.1 | OpenTofu (MPL-2.0) |
| Vault ≥ 1.15 | BSL 1.1 | OpenBao (MPL-2.0) |
| Airbyte | Elastic License v2 | Meltano (MIT) |
| Outline | BSL 1.1 | HedgeDoc (AGPL-3.0) |
| Unstructured (Cloud) | Mixed proprietary | DocLing (MIT) for OSS path |
| CockroachDB ≥ 23.1 | BSL 1.1 | Postgres + Citus extension |
2. Allowlist — unrestricted use¶
Components published under any of these licences may be embedded, imported, or bundled without restriction:
- Apache 2.0
- MIT
- BSD-2-Clause / BSD-3-Clause / 0BSD / ISC
- PostgreSQL License
- Unlicense / CC0-1.0
- Python Software Foundation License (for stdlib-adjacent code)
These are the default target for new dependencies.
3. Allowlist with Aggregation Pattern (separate container)¶
The following Copyleft licences are OSI-compatible but introduce source-disclosure obligations if the licensed code is statically or dynamically linked into our own code. We meet the licence by treating each such component as a separate Docker service with a clear network boundary — what the FSF calls "mere aggregation" — and never importing its source into MoE codebases.
| Licence | Components in our stack | Aggregation strategy |
|---|---|---|
| AGPL-3.0 | Grafana, Garage (S3 storage), SearXNG, HedgeDoc (planned) | Own container, talks via HTTP/S3 API only |
| GPL-3.0 | Neo4j Community | Own container, talks via Bolt protocol |
| LGPL | (no current dependency) | Linking allowed; document if introduced |
| MPL-2.0 | OpenTofu, OpenBao (planned) | File-level copyleft; OK to embed |
| OSL-3.0 | Form.io (if selected) | Treat like AGPL — separate container |
Documentation requirement: Every AGPL/GPL component must be listed
in this file plus in the per-repo THIRD_PARTY_NOTICES.md with the
exact container name and the upstream source URL.
4. Blocklist — never use¶
These licences are non-OSI-compatible. Components under them are explicitly disallowed in any MoE repository:
- Server Side Public License (SSPL) — Elasticsearch ≥ 7.11, MongoDB, Redis Stack
- Business Source License (BSL / BUSL 1.1) — Redpanda, HashiCorp tooling ≥ 2023, Cockroach ≥ 23.1, Outline, MariaDB MaxScale
- Elastic License v2 (ELv2) — Airbyte ETL platform, post-2021 Logstash variants
- Confluent Community License (CCL) —
confluentinc/cp-*images - Redis Source Available License v2 (RSALv2) — Redis ≥ 7.4 (until 8.0)
- Llama Community License (only for MoE Sovereign itself; allowed inside operator deployments under operator responsibility)
- Any "Source-Available" licence without OSI approval
EOL / Archived projects — also forbidden regardless of historical licence:
- MinIO — archived 2026-04-25; last Docker image frozen; no further security patches. Replacement: Garage (AGPL-3.0, EU-origin). See section 1 and section 4a.
A component on this list must either be replaced with an OSI-compatible fork, removed, or — if absolutely irreplaceable — explicitly exempted in this page with a documented business reason and a sunset deadline.
4a. Object-storage tier selection¶
Two tiers are supported; the choice depends on compliance requirements:
| Tier | System | Licence | When to use |
|---|---|---|---|
| Standard | Garage v1.0+ (Deuxfleurs) | AGPL-3.0 | DEV, SME production, internal tooling. Fully S3-compatible; EU-origin; Rust-based. Lacks Object Lock + SSE-KMS. |
| Compliance | Ceph RadosGW | LGPL-2.1 | KritIS, government, banking audit, pharma GxP. Full S3 Object Lock (WORM), SSE-KMS (HashiCorp Vault / OpenBao), bucket lifecycle, multi-site replication. Available as managed service at Hetzner, OVH, STACKIT. |
WORM compliance note: BSI Grundschutz OPS.1.1.6 and GDPR Art. 5(1)(e) (storage limitation) may require immutable object retention in regulated deployments. Garage v1.0 does not implement S3 Object Lock; Ceph does.
The application layer (lakeFS, moe-codex API) is storage-backend-agnostic —
switching tiers requires only changing LAKEFS_BLOCKSTORE_S3_ENDPOINT and
credentials. No code changes.
5. Automated enforcement¶
scripts/audit-licenses.sh parses all docker-compose*.yml files and
requirements*.txt against this allow-/blocklist. Exit code 1 on any
hit. The script is wired into:
- Pre-commit gate (developer workflow)
- CI pipeline (every PR)
- Monthly drift report (cron — proposed for
moe-codexPhase 2)
Run locally:
6. Comparative-Advertising guidance¶
When positioning MoE Sovereign against proprietary platforms (Palantir Foundry / Gotham / AIP / Apollo), the following constraints apply under § 6 German UWG and Art. 4 EU Comparative Advertising Directive 2006/114/EC:
| ✅ Allowed | ❌ Prohibited |
|---|---|
| "Foundry-equivalent functionality" | "Foundry clone" |
| "Palantir-coverage table" (factual, verifiable) | Copy of Palantir UI screenshots / icons |
| "Open-source alternative" | "Better than Palantir" without measurable evidence |
Naming our own products in Latin (moe-libris, moe-codex) |
Using "Foundry", "Gotham", "AIP" or "Apollo" as repo or product names |
| Listing Palantir features in a comparison matrix | Asserting that Palantir does not work without evidence |
Comparative claims must be: - Objectively verifiable (✅ — our comparison page does this) - Not denigrating to the competitor (✅ — we name Palantir's strengths) - Not creating likelihood of confusion (✅ — "alternative", not "clone")
7. EU AI Act readiness (Regulation 2024/1689)¶
MoE Sovereign benefits from the Open-Source exemption under Art. 2(12) AIA — Free/Open-Source AI components under Apache/MIT licences are excluded from many obligations unless they are placed on the market as a high-risk system (Art. 6).
Operator obligations (not platform obligations): - Risk-class assessment per use case - DPIA under GDPR Art. 35 if personal data is processed - Logging and traceability for high-risk deployments
These obligations are covered in dedicated pages:
- docs/system/eu_sovereignty_charter.md (sovereignty positioning)
- moe-codex/docs/system/eu_ai_act_mapping.md (use-case risk mapping — planned)
- moe-codex/docs/system/dsgvo_dpia_template.md (DPIA template — planned)
8. Maintenance contract¶
This page is the single source of truth for licence allow-/blocklist.
Update triggers:
- Any new container image added to
docker-compose*.yml→ add row to the per-licence section, runaudit-licenses.shto verify clean exit. - Any upstream relicense announcement (e.g. Apache project moving to BSL) → add a Linux-Foundation-Fork entry and a deprecation path.
- Any new Python dependency in
requirements*.txt→ verify licence, add to allowlist coverage or extend the script. - Any new repository under the
moe-*family → update Scope section.
Coverage discipline: The lists in sections 2–4 must remain in sync
with the BLOCK_IMAGES / BLOCK_PIP_PACKAGES arrays in
scripts/audit-licenses.sh. A mismatch means the audit is silently
missing cases — treat as a bug.