0008. Licensing (Apache-2.0), the DCO, and dependency-selection criteria

Context

Vord's adopters are the same kind Wyrd targets — providers and application teams that must be legally able to deploy, modify, and build products on the system — and Vord is assembled from pluggable engines at every seam: the Authorizer (ADR-0006), KeyCustody (ADR-0003), the metadata core it borrows from Wyrd (ADR-0001 rule 4), the NATS revocation/event transport (ADR-0005), and the deployment substrate. An identity system is, even more than a storage system, a sovereignty artifact: it holds the principals and the keys. A sovereignty-first system is only as sovereign as its weakest pluggable component, so its dependency choices cannot rest on technical merit alone.

Wyrd already encoded exactly this reasoning (Wyrd ADR-0003): a permissive outbound license, contribution provenance by DCO rather than CLA, and a three-test rubric applied to every external engine so "the next CockroachDB" — source-available, single-vendor, un-self-hostable — is caught at selection time rather than after adoption. Vord ships an Apache-2.0 LICENSE already; what is missing is the rule, recorded so Vord's own engine picks (SpiceDB vs OpenFGA, the KMS, the authz dev backend) are evaluated against a standard rather than by taste.

Decision

1. Outbound license and contribution provenance

License Vord under Apache 2.0 — permissive, with an explicit patent grant — and ship LICENSE, NOTICE, and SECURITY.md from the first commit (done as part of governance adoption, ADR-0007). Track contribution provenance with the Developer Certificate of Origin (DCO), not a CLA: a per-commit Signed-off-by attestation, inbound-equals-outbound under Apache 2.0, enforced in CI (dco.yml). The reasoning is Wyrd ADR-0003's verbatim: the CLA's friction is paid by exactly the drive-by contributors an open project wants, and the one thing a CLA would buy — the unilateral right to relicense — is the lever a sovereignty-first project should deliberately not hold.

2. Dependency-selection criteria (inbound)

Every external dependency at a pluggable seam — and every component recommended as a default — is evaluated against the same three tests Wyrd ADR-0003 defines, adopted here unchanged:

• License. Permissive and clearly-licensed (MIT / Apache-2.0 / BSD-class) is preferred. Adopter-infecting copyleft (AGPL) and source-available "paywall" licenses (BSL, SSPL, vendor community licenses) are disqualifying for a default and must be explicitly justified if used at all.
• Governance. Foundation- or multi-stakeholder-governed (e.g. CNCF) is preferred over a single vendor who can unilaterally relicense; a permissive license is the safety net, because forkable code cannot be relicensed away.
• Control resilience. A component passes if control over it cannot be withdrawn and you can run it yourself: forkable, self-hostable with no forced phone-home and no required managed service, and — for components that hold data — data residency under the operator's control. Vendor nationality is explicitly not a test; the test is whether control can be withdrawn.

3. Principle

Prefer foundation-governed, permissively-licensed components at every pluggable seam. When a chosen default carries a control-resilience wrinkle, name it; when a more resilient alternative exists, offer it. This makes the audit a standing rule, not a one-time cleanup — and the seam abstractions Vord already mandates (ADR-0003 KeyCustody, ADR-0006 Authorizer) are what keep any one wrinkle swappable.

Consequences

• Commercial providers can adopt Vord without legal friction (patent grant included), with lower contribution friction than a CLA and sufficient provenance.
• The three tests turn the engine picks Vord has deferred into rubric-bound decisions rather than matters of taste — most importantly the SpiceDB-vs-OpenFGA choice (ADR-0006), made at M3.
• This ADR governs Vord's choices; the engines it borrows through Wyrd (the metadata core and its TiKV/etcd backends) already passed the identical Wyrd ADR-0003 audit, so Vord inherits clean provenance there by construction (rule 4).

Audit of currently-named dependencies (the three tests applied)

Standing rule: any ADR that introduces a dependency at a seam appends its row to this table in the same change — the audit stays current by construction, not by periodic cleanup.