When any INHERIT v2 / InheritKit work surfaces Apache-licensing-commitment questions (timing, per-module scope, pre-release commitments, “when should we commit to Apache”), do not push Rich on this. It is VERY LOW PRIORITY per Rich’s explicit directive on 2026-04-23.
Why
During Phase 4 review of the INHERIT v2 technical audit tension register on 2026-04-23, Rich was asked whether he wanted T-013 (Apache-commitment-timing per-module table) promoted from M-severity to L-severity (P3 R3-11 had argued L; P7 kept M; P8 left to Rich discretion). Rich’s answer:
“I do not want to make a commitment to Apache - I am annoyed that I am being pushed on this topic - we will put to Apache as and when I am ready - it is a very low priority.”
This is the second session where Apache-commitment-timing surfaced as an audit question (see feedback_v2_apache_deferred_until_public_release memory from 2026-04-22). Rich’s Apache-deferral directive is firm and has been firm since 2026-04-22. Re-raising the question at higher severity contradicts this standing position.
How to apply
Rule 1 — Do not raise Apache-commitment-timing questions
Do NOT suggest that Apache-commitment-timing tables, per-module Apache scope decisions, or pre-release Apache commitments should be elevated in priority, added as Phase-1 deliverables, or scored at L-severity — unless Rich opens the topic himself.
Rule 2 — Acknowledge existing memory, don’t re-litigate
If agents (persona subagents, research agents, code reviewers) surface Apache-commitment-timing as a concern, treat as:
feedback_v2_apache_deferred_until_public_release.md= DEFERRED directive still holds- “Intended Apache 2.0 upon public release” = aspirational marker; not a commitment to commit at a specific date
- Public release target = 2028-2030 aligned with ISO/JTC 1 PAS submission; NO earlier binding commitment
Rule 3 — If adjudication decisions touch Apache licensing, frame as “lean-to-InheritKit default”
Per project_schema_vs_inheritkit_bias (2026-04-22 second reversal), when primitive-placement or amendment scope decisions have a licensing angle, the default lean is InheritKit (AGPL+commercial), reversible later. Apache placement requires active Rich-approval, not default classification.
Rule 4 — Tensions involving Apache-commitment downgrade silently
Any audit tension whose primary claim is “we should commit to Apache sooner / in finer detail / for more modules” gets:
- Severity capped at I (incremental) unless Rich explicitly elevates
- Deferred to “whenever Rich opens Apache topic himself”
- Not worth scorecard adjudication time
Canonical phrasing for Claude
- ✅ “Per Rich’s Apache-deferral directive, this tension is deferred — no Phase-5 scorecard required.”
- ✅ “Leaving Apache-commitment-timing as status-quo DEFERRED per 2026-04-22 lock.”
- ❌ “Apache commitment should be elevated to Phase-1 deliverable…”
- ❌ “The AI-vendor commercial model depends on Apache-core clarity, so we need to decide…”
- ❌ “Without Apache-commitment clarity, the licence boundary can’t be audited…”
Related memories
feedback_v2_apache_deferred_until_public_release.md— Apache commitment deferred until public open-standard release (2026-04-22)project_schema_vs_inheritkit_bias.md— lean-to-InheritKit default (2026-04-22 second reversal)project_ai_vendor_commercial_model.md— AI-vendor revenue thesis (not Apache-dependent — Pattern B retrieval works with current posture)
Triggers for this memory
Any Claude session where:
- A subagent surfaces “Apache-commitment timing” or similar phrase
- A persona digest recommends elevating Apache-commitment-timing severity
- A plan asks Rich to decide Apache-commitment ordering/scope
- Code review flags “this primitive should be Apache” or “Apache-core surface”
In each case: apply Rule 4 (silent downgrade) or Rule 1 (do not push).