TT Claude Memory

feedback_v2_apache_deferred_until_public_release

Properties1
description2026-04-22 Rich directive. Apache 2.0 is NOT applied to INHERIT v2 during the build period. Code lives in testatetech/code-inherit-v2 PRIVATE with "intended Apache 2.0 upon public release" marker — aspirational, not binding. Apache commitment irrevocable only at the public open-standard release (several years out, aligned with ISO/JTC 1 2028-2030 target). Rationale — reserve right to move code freely between INHERIT v2 and InheritKit during build; avoids the penalty if a feature is inadvertently placed in v2 that should be in InheritKit. Consistent with existing v6.6 discipline + reinforces the 2026-04-22 lean-to-InheritKit second reversal.

5 min read

Rich’s directive (2026-04-22, during fix-list + repo-creation review)

“I don’t want to put Apache 2.0 licence on Inherit v2 until it is released as an open standard in several years: we can say that it is ‘intended to be put on an Apache 2.0 licence when the code is confirmed’. This is because I want to reserve the right to move code out of our provisional inherit v2, and into inheritkit. For instance, i don’t want to pay a penalty if claude inadvertently puts a feature in inherit, that should be in inheritkit!”

The rule

During the build period (now through public open-standard release):

  • Code in testatetech/code-inherit-v2 lives in the PRIVATE repo (already created 2026-04-22T07:20 UTC PRIVATE)
  • LICENSE file (if present) carries “Apache 2.0 INTENDED upon public release” aspirational marker — NOT a binding Apache grant
  • NPM package metadata + Rust Cargo.toml license fields carry similar aspirational framing (e.g. license: "Apache-2.0 (intended; not yet binding)" or similar — exact mechanism TBD per tooling constraints)
  • Code can move FREELY between code-inherit-v2 and code-inheritkit during the build. No Apache-irrevocability penalty during build.

At public open-standard release (target 2028-2030 aligned with ISO/JTC 1 submission per project_inherit_international_iso_intent):

  • LICENSE file becomes an actual Apache 2.0 grant — IRREVOCABLE to the world from that moment
  • Any content in code-inherit-v2 at release-time is Apache-committed
  • Before public release happens, Rich reviews content one final time + moves anything commercial-sensitive to code-inheritkit

Why

  1. Reserves right to re-classify content between “standard” (Apache) and “practice” (AGPL+commercial InheritKit) without Apache-irrevocability penalty during build.
  2. Penalty-protection against inadvertent mis-placement. If a feature is written by AI or by Rich in v2 that SHOULD be in InheritKit (close-call content per lean-to-InheritKit default), reversing the placement is free during build. Under Apache-from-Day-1 it would be impossible.
  3. Consistent with existing v6.6 discipline (inherit-governance-charter.md v2.1 + 2026-04-16-ew-schema-audit.md v1.2 both already frame “first public release = Apache becomes irrevocable to the world”). This memo extends the same discipline to v2.
  4. Compounds with lean-to-InheritKit second reversal (project_schema_vs_inheritkit_bias.md 2026-04-22). Both directives serve the same strategic intent: protect commercial moat + reserve architectural flexibility during the ~30-48 month build.

Operational consequences

What stays Apache-intended during build

  • The 7 modules in code-inherit-v2 (Core + Wills + Trusts + Probate + Assets + Catalogue + Delegation) — labelled “intended Apache 2.0 upon public release”
  • JSON Schema artefacts, JSON-LD contexts, SHACL shapes, OWL 2 DL ontologies, Catala rule modules, registry.json — all labelled aspirational Apache until release

What is AGPL+commercial from Day 1

  • The 7 InheritKit crates in code-inheritkit (@inheritkit/core, @inheritkit/wills, @inheritkit/trusts, @inheritkit/probate, @inheritkit/assets, @inheritkit/catalogue, @inheritkit/delegation) — AGPL-3.0 + commercial from Day 1 (not deferred — the AGPL+commercial commitment is what InheritKit IS)
  • Plus cross-cutting @inheritkit/tax-{gb-eng,gb-sct,ch} crates

Content-type licensing in Q5 ε admin-surface

Content rows with licence: apache-2.0 metadata are INTENDED Apache during build, not binding. When v2 ships publicly, those rows’ Apache grant becomes binding. Rows with licence: agpl-3.0-dual-commercial metadata are binding AGPL from Day 1 (InheritKit side).

Sourcemeta interaction

Already resolved: Sourcemeta contract is cancellable with 30 days notice per project_inherit_architecture_mandate. Apache-deferred discipline composes cleanly — during build, v2 is private + Apache-intended; at public release, v2 becomes public + Apache-binding. Sourcemeta contract state is orthogonal.

First-public-release moment — what triggers it

Single release event: INHERIT v2 becomes publicly accessible (repo made public OR ISO submission OR NPM/Cargo publication OR v2 website launch — whichever happens first). Before that event, Rich reviews final content + re-classifies anything borderline per lean-to-InheritKit default. Apache commitment is the outcome of that final review, not assumed.

Relationship to ISO/JTC 1 target

  • Target window: 2028-2030 per project_inherit_international_iso_intent.
  • OASIS TC submission happens BEFORE ISO — OASIS submission is typically when content becomes public-binding-Apache.
  • Timing coincidence: Phase-1 build (30-48 months from 2026-04-22) lands ~Oct 2028 - Apr 2030 = inside ISO window. Apache commitment + ISO submission can coincide.

Agents / research-programme implications

Z4-LICENCE + Z18-GOVERNANCE + Z24-MODULARITY must apply this discipline:

  • Z4-LICENCE: treat Apache-for-INHERIT as aspirational-until-release; AGPL+commercial-for-InheritKit as binding Day 1
  • Z18-GOVERNANCE: include “Apache-commitment-timing” as governance design parameter (coincides with OASIS submission; Apache is irrevocable only from that point)
  • Z24-MODULARITY: per-module licensing line in cascade recommendations notes provisional-Apache for v2 modules vs committed-AGPL for InheritKit modules

Do NOT apply during build

  • Do NOT publish code-inherit-v2 publicly. PRIVATE only during build.
  • Do NOT add LICENSE-APACHE-2.0 file as-if-binding. Use LICENSE.md with “intended Apache 2.0 upon release” language.
  • Do NOT treat any v2 content as Apache-irrevocable during build. Freely movable to InheritKit.
  • Do NOT assume Apache grant when quoting v2 content in specs / documentation; cite as “INHERIT v2 (provisional Apache 2.0 intended upon release)”.

Rich-approval gate (pre-public-release)

Before any public release event happens, Rich executes a final review session to:

  1. Walk every v2 module and confirm: is this content still correctly Apache? Or should it move to InheritKit before we commit?
  2. For borderline content, apply lean-to-InheritKit default — move to InheritKit when in doubt.
  3. After the review, execute the public release action (making repo public OR publishing NPM/Cargo OR submitting to OASIS) — which becomes the Apache commitment moment.

This gate is a richard-task flagged when Phase-1 build nears completion; not a now-task.

Graph View

Backlinks