Licensing & Foundation Strategy (formerly SPEC §10)

10.1 Project license — Apache-2.0 (decided and applied 2026-07-10)

The repository is licensed Apache-2.0 (was MIT in the first draft). Justification (all verified):

1. Foundation fit. Apache-2.0 keeps Fgentic's original code compatible with the selected LF AI & Data path and possible later CNCF or AAIF review. No path is described as friction-free: asset custody, the linked MPL-2.0 dependency, and the exact submitted scope still require separate review. The sequence and current evidence are in Architecture §1.3 and the dated CNCF dossier.
2. Patent grant. Apache-2.0 §3 grants and defensively terminates patent rights — the property enterprise counsel checks first on an agent-infrastructure platform; MIT has none.
3. Stack coherence. A2A, MCP, kagent, agentgateway, CloudNativePG, Flux, cert-manager are all Apache-2.0.
4. Cost. Trivial now (sole author); painful after external contributions. Done before the first outside PR. DCO (not CLA) — matches kagent/agentgateway and avoids the asymmetric-rights problem Element's CLA exemplifies.
5. Obligation: the bridge binary embeds maunium.net/go/mautrix (MPL-2.0 — verified, not AGPL). The NOTICE files (repo root + app, shipped in the image) state that and link the source. That is MPL's entire ask for unmodified use.
6. Synapse policy module: apps/synapse-federation-policy is original Apache-2.0 project code, distributed independently from Synapse and loaded through Synapse's documented module API. The repository neither copies Synapse implementation code nor builds or redistributes a modified Synapse image; the deployment continues to reference the separately published upstream AGPL image. The module README records this packaging boundary and the operational obligation to reassess it before vendoring, modifying, or redistributing Synapse.

10.2 The honest AGPL/open-core map (the "no strings attached" audit)

Component	License	Verdict for Fgentic
Synapse, MAS, Element Web/X	AGPL-3.0 OR Element-Commercial (CLA-encumbered)	The repository references unmodified upstream images. AGPL-3.0 §13's extra remote-network source offer applies to a modified version; manifests do not combine those programs with the bridge. Operators still review their own modification and redistribution duties. Many enterprises blanket-ban AGPL (Google policy, CNCF allowlist), so the stack remains documented as swappable (§10.3).
ESS Community (ess-helm)	AGPL-3.0 chart, open-core funnel	README says "non-commercial… up to 100 users… not for production in commercial environments" — that is positioning, not license terms (AGPL can't restrict commercial use), but HA/autoscaling, Secure Border Gateway, audit bots, LDAP, Synapse Pro are genuinely Pro-gated. Stated openly in the README rather than papered over; §8.2's policy-as-code border is the open answer to the Pro-gated border gateway.
Keycloak + KeycloakX chart	Apache-2.0	Optional sovereign reference IdP. KeycloakX remains actively maintained and deploys Keycloak's official Quay image; Bitnami's public Keycloak artifacts no longer provide maintained, version-pinned production images after its 2025 catalog change.
Ketesa administrator client	Apache-2.0	Optional digest-pinned static SPA with native Synapse/MAS support. It remains disabled by default and stores no service credential. Element Admin is the AGPL/commercial alternative and is not deployed.
mautrix/go (library)	MPL-2.0	The load-bearing good news: the bridge stays permissive. NOTICE shipped (§10.1).
mautrix bridges (Slack/Telegram/…)	AGPL-3.0	Deployment-only artifacts (M7), never linked — fine, same "unmodified" logic.
Grafana, Loki, Tempo	AGPL-3.0 (Grafana Labs CLA)	Default observability stack, with documented Apache-2.0 alternates (VictoriaMetrics/VictoriaLogs, Jaeger).
vLLM + Production Stack chart	Apache-2.0	The optional CPU self-hosted model runtime and its Helm packaging remain permissive; images and chart are referenced upstream at immutable version/digest pins.
Qwen2.5-0.5B-Instruct	Apache-2.0	The optional demo model is downloaded from its upstream repository at an immutable revision. Preserve the included license in the model cache; its small size enables a demo but does not imply production quality or a safety assessment.
Python evaluation fixture/runtime	PSF-2.0	clusters/demo embeds a zero-dependency standard-library response stub and pins the official multi-architecture Python image by digest. It is evaluation-only and is not linked into or shipped with the Go bridge.
Draupnir (moderation bot)	AFL-3.0 + Apache-2.0	Optional standalone policy-list moderation service (infra/moderation), disabled by default, image referenced upstream at an immutable digest and never mirrored into a project registry. AFL-3.0 is unproblematic for a standalone service run unmodified; its code is never vendored into the bridge or project code.
synapse-http-antispam (Synapse module)	MIT	Optional server-side invite/event filtering wired through ESS additional config. Referenced upstream, never vendored into the bridge or project code; the operator supplies it on Synapse's Python path.
policyserv (MSC4284 policy server)	Apache-2.0	Candidate room policy server for the federation lab evaluation only (issue #136 Task 4); permissive, no caveats. Not yet deployed or recommended for production.
Everything else in the stack	OSI-approved permissive licenses	No caveats relevant to Fgentic.

10.3 Homeserver strategy (deep dive concluded 2026-07-10 — keep ESS, don't switch)

Two supported profiles behind the same Helm layer; a full candidate comparison (ESS-less Synapse, Tuwunel, continuwuity, Conduit, Palpo) was researched against primary sources on 2026-07-10:

1. Reference profile (default): ESS Community, pinned 26.7.2. Nothing in mid-2026 beats Synapse+MAS+Element on the platform's top requirements — appservice API maturity (the bridge's lifeline), MAS/MSC3861 + Element X, federation policy hooks (spam-checker module callbacks, the basis of §8.2's border-policy design), and PostgreSQL (the only candidate that fits the shared CNPG cluster at all). Dropping the ess-helm chart for community charts (ananace + a separate MAS chart) yields zero licensing gain — the AGPL + open-core funnel lives in Synapse/MAS/Element themselves, not the chart — at real maintenance cost. The stale pin was the actual problem, and it is fixed.
2. Pure-permissive profile: Tuwunel first, continuwuity as the community alternate (both Apache-2.0, both active). Tuwunel: monthly releases, built-in MSC3861 OIDC + explicit MAS integration (v1.8.0), battle-tested MSC4186 (Element X), the only nation-scale non-Synapse production deployment (Swiss government sponsorship) — but bus factor ≈ 1 (one maintainer ≈ 85% of commits), four appservice regressions shipped in 2026 alone, admin-room appservice registration (no Secret-mounted file), RocksDB only (no Postgres — this profile deviates from ADR 0007 with a PVC + RocksDB backup engine), and no maintained Helm chart. continuwuity: healthier contributor spread (~15 humans) and richer federation allowlist knobs, but deliberately no MAS path, OIDC still alpha, zero institutional funding. The two forks' databases are mutually incompatible — the profile choice is a one-way door once data exists. Watch-list: Palpo (Rust + PostgreSQL, Apache-2.0) is the only future candidate that would satisfy CNPG, still pre-production.
3. Switch triggers (do not switch preemptively): (a) Element moves a Community capability the platform uses (appservice loading, MAS wiring, well-known, non-worker Synapse) behind Pro or discontinues ESS Community; (b) a deployment hard-bans AGPL → activate the pure-permissive profile for that deployment; (c) Tuwunel/continuwuity ship Postgres + a maintained chart + 6 regression-free months on the appservice API → re-evaluate the default. Migration cost if triggered: the bridge survives nearly intact (spec-only API; only the registration delivery mechanism changes); MAS and the synapse/mas CNPG databases are orphaned; accounts/history are recreated, not migrated (no tooling exists).

Rules regardless of profile: never mirror AGPL images into project registries (reference upstream only — redistribution is what triggers source-offer duties), never fork AGPL components in-repo.

For foundation scope, those upstream AGPL images remain separately published runtime integrations: Fgentic does not vendor, rebuild, mirror, redistribute, or link them into the Apache-2.0 bridge, and does not propose them as donated project code. That packaging boundary narrows the review scope; it does not erase an operator's AGPL obligations.

10.4 Consulting-engagement AGPL compliance — what is and isn't permitted

This project's adoption path is OSS-free/consulting-paid: deployments happen on customer premises or GCP as a paid engagement, not as a sold product. That model interacts with AGPL differently from "we ship a SaaS" — recorded here so no engagement crosses a licensing boundary by accident.

The extra §13 duty requires a modified network-facing version, not mere network use. AGPL-3.0 §13 says that if the Program is modified and users interact with that version remotely, the modified version must offer its Corresponding Source. Remote interaction by itself is not conveyance, and this repository does not modify the referenced Synapse, MAS, Element, Grafana, or Loki artifacts.

Why the repository boundary is narrow, not blanket legal clearance. Every AGPL component in the stack (§10.2) is referenced as an unmodified upstream chart or image, with no in-repo fork (§10.3). The repository therefore creates no modified version that needs a new §13 source offer. An operator that modifies or redistributes an artifact must assess those separate duties for the exact deployment. Fgentic's bridge talks to Synapse over the stable-spec appservice HTTP API (§5–§6) and never links against its source. This records repository policy and packaging facts, not deployment-specific legal advice.

ESS Community's "non-commercial, up to 100 users" README line is Element's support/liability positioning, not an enforceable license term. AGPL cannot legally restrict commercial use or scale (verified against the license text linked above) — Element's own README says so is a statement about what Element will support for free, not what the license permits. Treat it as a signal that ESS Community carries no vendor SLA or liability coverage at scale, which is exactly the gap a consulting engagement fills or a customer buys off via ESS Pro.

Repository policy, subject to deployment-specific review:

1. Deploy the referenced AGPL components unmodified from their named upstream sources onto customer-owned infrastructure, while preserving the upstream license and reviewing any operator-specific obligations. ESS Community's "100 users" note is not a license ceiling.
2. Charge for the deployment, integration, operation, and support work itself — AGPL places no restriction on charging for services rendered around the software.
3. Keep this project's own code (the bridge, manifests, policy module — all Apache-2.0) under Apache-2.0 terms, including in a customer engagement, because it is architecturally separate from the AGPL components it talks to over network APIs (never statically or dynamically linked).

Outside repository policy or requiring deliberate review:

1. Modifying Synapse/MAS/Element/Grafana/Loki source for a customer without offering that modified source to the customer's users — this is the actual §13 trigger this project avoids by policy (§10.3's closing rule: never fork AGPL components in-repo).
2. Representing ESS Community as carrying Element's official support/SLA — it does not; either the consulting engagement is the support layer (state that explicitly in scoping) or the customer buys ESS Pro.
3. Mirroring or redistributing AGPL images/charts into a project- or customer-owned registry (§10.3) — reference upstream only, per-engagement, to avoid becoming the source of a "conveyed" copy.

Engagement scoping checklist (apply before signing, not after):

1. State in the SOW that AGPL components are deployed unmodified from named upstream sources at a pinned version/commit, with no warranty beyond the consulting services themselves.
2. If a customer's procurement policy blanket-bans AGPL (common in large enterprises and some regulated sectors — the Google OSPO AGPL policy is the frequently-cited reference case), say so during scoping, not after: the pure-permissive homeserver fallback (§10.3, profile 2) is a real, uncosted migration today (no Postgres, no maintained Helm chart on any candidate), not a drop-in swap — price it as such rather than assume it.
3. For sovereignty-first buyers (EU/government), note AGPL can be a selling point, not just a risk: it guarantees any vendor modification stays public. Lead with that where relevant instead of only defending against the license.