Approved Monday 20 April 2026 by Rich: “Law vs practice is a brilliant way to put it.”
Why: Rich raised the concern that partners won’t contribute commercially-valuable, potentially litigious content to an Apache 2.0 product — but if all such content goes to AGPL/commercial InheritKit, the Apache INHERIT standard becomes a hollow shell that external governance bodies (OIDF, W3C, OASIS) won’t host. The healthy split is on content type, not revenue potential.
The principle:
- INHERIT (Apache 2.0) = what the law says. Statutory, jurisdictional, auditable, schema. Plus the schema itself. Partners contribute for prestige + accuracy-reputation (like publishing a practice note in a law journal).
- InheritKit (AGPL + dual commercial) = what practitioners do with that law. Interpretive, workflow, partner-contributed, commercial. Partners contribute for revenue share + commercial protection.
Industry analogue: INHERIT is the case-law reporter; InheritKit is the practice-note library.
How to apply:
- When asked “where does this content live, INHERIT or InheritKit?” — apply the two-lawyers test: if two competent lawyers would agree on the content without needing case law to settle it, it’s statutory (INHERIT). If they would disagree, it’s interpretive (InheritKit).
- Two admin surfaces exist: the Advisory BackOffice (InheritKit) AND a Standard Registry (INHERIT, Apache). Partners choose based on contribution intent; licence terms are explicit at each entry point.
- Catala rulebases split by content type. IHT calculation rules (statutory arithmetic) → INHERIT. “Given client profile X, recommend trust structure Y” (interpretive) → InheritKit.
- Critical-question annotations (Carneades / ASPIC+, Year-2+ uplift per Option F) — interpretive by nature → InheritKit.
- AI-vendor query surface — Apache for public-facing agent use; AGPL/commercial for agents that want interpretive depth (OpenAI / Anthropic / Google pay for InheritKit access).
- Err on the side of InheritKit when uncertain — migration asymmetry applies: once in INHERIT the licence is Apache-irrevocable; you can always graduate content from InheritKit to INHERIT later, never the reverse.
- Do NOT propose collapsing to one admin surface — the two-surface design is the load-bearing piece that makes the licence split workable.
Downstream application status (20 Apr 2026):
- Principle captured:
docs-strategy/ideas/2026-04-20-law-vs-practice-split.md - Applied to
brand-architecture.md§2 + §4 (v1.11) — new subsection “The law-vs-practice split principle”, two-admin-surface table, Supabase 2/3 boxes updated - Applied to
option-G.md§3 (v1.4) — licensing stack reframed with law-vs-practice verdict column; per-Catala-module licence assignment flagged as PENDING Rich sign-off (not unilaterally flipped) - Not yet applied to future
brands/inheritkit.md+brands/openinherit.md— will carry the principle when drafted
Pending Rich decision (surfaced by applying the principle):
- Per-Catala-module licence. Statutory modules (attestation, intestacy, IHT arithmetic, BPR/APR, GWR/QSR, basic trust IHT) are LAW by the two-lawyers test → principle implies Apache. Standing default-to-InheritKit bias implies stay AGPL. Asymmetry reminder: Apache is irrevocable. The principle says “apply to content”; the application requires Rich’s per-module call.
Rejected alternative framings (avoid slipping back to these):
- “Objective vs subjective” — Rich’s original phrasing; “subjective” reads as arbitrary where “practice” reads as professional
- “Data vs logic” — misses the licence asymmetry
- “Free vs paid” — conflates licence with price
- “Non-partner vs partner-contributed” — conflates origin with nature