ADR-029: Governance over License — Tool Selection Rule¶
Status¶
Accepted — 2026-04-25
Context¶
Between 2018 and 2025, AKKO watched a series of "obviously safe" open-source dependencies become commercial liabilities:
| Year | Project | Move | Impact on a SaaS like AKKO |
|---|---|---|---|
| 2018 | Redis | RSAL -> SSPL -> AGPL | Forced fork to Valkey |
| 2018 | MongoDB | AGPL -> SSPL | Removed from cloud distribution |
| 2019 | Elastic | Apache 2.0 -> SSPL / Elastic License | Fork to OpenSearch |
| 2023 | Terraform | MPL 2.0 -> BSL | Fork to OpenTofu |
| 2024 | Grafana | Apache 2.0 -> AGPL v3 (Loki, Grafana, Promtail) | Eliminated from AKKO (ADR-028) |
| 2024 | MinIO | Apache 2.0 -> AGPL v3 + maintenance mode | Eliminated from AKKO (ADR-027) |
Common pattern: single-vendor open source with no foundation governance. When the vendor's commercial strategy shifts, the license follows. Picking a permissive license at integration time is necessary but not sufficient.
We need a deterministic rule for tool selection that survives the next decade of relicensing waves.
Considered Options¶
Option A — License-only filter¶
Accept anything Apache 2.0 / MIT / BSD at integration time. Re-evaluate only when something breaks.
Verdict: This is what we did until 2024. It failed three times in 18 months (Loki, Grafana, MinIO).
Option B — Governance-only filter¶
Only accept projects under a recognised foundation (Apache, Linux Foundation, CNCF, Eclipse).
Verdict: Too restrictive. Excludes high-quality single-vendor Apache 2.0 projects (SeaweedFS, VictoriaLogs, JuiceFS) that are objectively the best technical fit in their category.
Option C — Lego Pattern (the decision)¶
For load-bearing non-substituable components, require multi-stakeholder governance.
For pluggable components, allow single-vendor open source if and only if a mode: external BYOS escape hatch is built into AKKO.
Re-score every 6 months on a 5-criterion grid.
Decision¶
Governance > license for load-bearing non-substituable bricks. Modularity + BYOS for pluggable bricks. 5-criterion scoring grid, re-evaluated every 6 months.
The 5-criterion grid¶
| Criterion | Weight | What we check |
|---|---|---|
| Governance | 25 % | Foundation (Apache, LF, CNCF, Eclipse) > multi-vendor consortium > single-vendor with public roadmap > single-vendor closed |
| License | 20 % | Apache 2.0 / MIT / BSD / MPL 2.0 -> green; LGPL -> yellow with isolation; AGPL / SSPL / BSL / Elastic / Confluent CL -> red |
| Vitality | 20 % | Commits per month, release cadence, issue response time. Last commit < 3 months, last release < 6 months |
| Maturity | 20 % | Production users at scale, stable APIs, semver discipline, CVE response track record |
| Cloud-native fit | 15 % | First-class Helm chart, Kubernetes operator if stateful, OCI images on a public registry, ARM64 support |
A score < 7.0 / 10 disqualifies a candidate from becoming a packaged default.
Load-bearing vs pluggable taxonomy¶
| Brick | Class | Governance requirement | Current choice |
|---|---|---|---|
| Trino | Load-bearing | Foundation | Trino Software Foundation |
| Iceberg | Load-bearing | Foundation | Apache Software Foundation |
| Polaris | Load-bearing | Foundation | Apache (incubating) |
| PostgreSQL | Load-bearing | Foundation | PostgreSQL Global Development Group |
| OPA | Load-bearing | Foundation | CNCF Graduated |
| Spark | Load-bearing | Foundation | Apache Software Foundation |
| Airflow | Load-bearing | Foundation | Apache Software Foundation |
| Storage | Pluggable | BYOS required | SeaweedFS (default) + external (ADR-027) |
| Logs / dashboards | Pluggable | BYOS required | VictoriaLogs / Perses / Fluent Bit (default) + external (ADR-028) |
| Identity (LDAP) | Pluggable | BYOS required | LLDAP (default, AGPL -> migration to 389-DS planned Sprint 39.5) + external |
| LLM gateway | Pluggable | BYOS required | LiteLLM (default) + external |
Rationale¶
- Foundations exist precisely to prevent unilateral relicensing. Apache, CNCF, Linux Foundation each require trademark and copyright assignment that makes a unilateral flip impossible.
- Single-vendor is acceptable when reversible. If a customer can swap the implementation in one Helm value, the blast radius of a future relicensing is "we update the default", not "we fork the universe".
- Periodic re-scoring is non-optional. Vitality and governance change over time; a 6-month cadence is short enough to catch a deteriorating project before it becomes a 12-month migration.
- No exceptions for load-bearing bricks. Replacing Trino or Postgres mid-flight would cost AKKO 6+ months. Foundation governance is the only insurance policy that scales.
Consequences¶
Positive¶
- Survives the next relicensing wave by construction.
- Forces every new dependency through an explicit, documented review.
- Customer-friendly: every pluggable brick has a BYOS escape hatch -> easier enterprise procurement.
- Re-scoring cadence catches drift early (eg. LLDAP relicensing risk caught in Sprint 39 audit).
Negative¶
- More design work upfront. Each pluggable brick needs an
externalmode and a compat shim. - Some best-of-breed single-vendor tools (eg. Quickwit pre-AGPL) are excluded from the default position.
- 6-month re-score is operational overhead (~2 days of analyst time).
Neutral¶
- The rule is documented as a memory file (
feedback_governance_first.md) so it applies to every future tool selection without needing to re-derive it.
Implementation¶
- Memory rule:
/Users/ab2dridi/.claude/projects/-Users-ab2dridi-newera/memory/feedback_governance_first.md(one-line index entry inMEMORY.md). - Selection grid template:
/Users/ab2dridi/newera/akko-technical-map/templates/tool-selection-grid.md. - Audit cadence: every 6 months a
tool-governance-audit-YYYY-MM.mdis produced inakko-technical-map/audits/. - CI gate: any new dependency added to a Helm chart must be accompanied by a completed grid in the PR description; missing grid = block merge (enforced in
.github/workflows/dependency-review.yml). - P1 trigger: any single-vendor brick whose 6-month re-score drops below 7.0 opens a P1 ticket with a 30-day SLA to either improve confidence (eg. join a foundation) or queue a replacement.
Validation¶
- ADR-027 (storage) and ADR-028 (observability) are the first two decisions made under this rule.
- Sprint 43 audit applied the grid retroactively to all 30+ services; 4 single-vendor bricks (LLDAP, LiteLLM, JupyterHub spawner extensions, OpenMetadata) flagged as P1, migration plans drafted in
akko-technical-map/sprints/backlog.md. - Pilot customer security review (Sprint 43) accepted the methodology and waived 2 of 3 standard "open-source supply chain" objections.
References¶
- Sprint 43 introduction of the rule: this ADR + memory file
feedback_governance_first.md - MEMORY.md AGPL alert (2026-04-19) and
[Choix de techno : 5 critères universels](feedback_verify_tool_maintained.md) - Past relicensing case studies: Redis (2024-03), Elastic (2021-01), Terraform (2023-08), MongoDB (2018-10)
- Related: ADR-020 (monitoring stack relicensing), ADR-027 (storage backend), ADR-028 (observability backend)