The three questions Rich raised
-
Will the research report comment on licence plans? v3.3 did not surface licence strategy as an open question — Apache 2.0 foundation + AGPL+dual InheritKit + proprietary Tier 3 was treated as settled. Rich wants this opened, given the pre-publication window means Apache 2.0 is not yet irrevocably binding.
-
What would Bruno Lowagie advise? Bruno is the creator of iText — the canonical successful AGPL+commercial-dual-licensing precedent in enterprise embedded libraries. His 2009 MPL→AGPL shift, the ~$150M Apryse acquisition in 2017, his writings on CLA discipline and pricing, make him the most directly applicable external authority on TT’s commercial position.
-
How is InheritKit used by MFI and LegacyLists? TT’s Tier 3 proprietary apps consume InheritKit (which is AGPL+commercial-dual). Without a documented internal-licence arrangement, MFI running AGPL InheritKit on its backend would strictly trigger AGPL contamination on MFI’s entire stack. Due-diligence scrutiny in fundraising will flag this.
Why this matters for v4.0.0
The pre-publication window is genuinely open. Apache 2.0 is not yet binding to the world. Decisions made before v4.0.0 ships are revisable; after, they’re not. The InheritKit-first bias (default to more restrictive tier when in doubt, because Apache is irrevocable) argues for deliberate rather than defaulted choice on the foundation licence.
TT’s three-tier licence stack (Apache foundation / AGPL+dual InheritKit / proprietary Tier 3) is probably correct — but “probably” is not the standard a 20-year decision deserves.
What v3.4 adds to the foundation-architecture handoff prompt
- New architectural + commercial criterion: licence strategy
- Phase 1 subject 32 — foundation-layer licence evaluation (Apache / MIT / MPL / AGPL / BSL / custom); explicit rationale; sign-off memo if anything other than Apache is recommended
- Phase 1 subject 33 — Bruno Lowagie perspective (subagent research); specific research agenda covering iText history, pricing mechanics, CLA discipline, enterprise-customer pushback, comparison with MongoDB/Elastic/HashiCorp precedents; synthesise what Bruno would advise TT
- Phase 1 subject 34 — TT internal-licence architecture for MFI / LegacyLists / InheritWills / other Tier 3 apps consuming InheritKit; internal licence memo; architectural analysis per app; licence-compatible deployment patterns; future partner-licence pattern template; AGPL-pushback handling guidance
- New deliverable 7 — licence strategy memo
Key precedents worth researching
- iText — Java PDF library, MPL→AGPL 2009, Apryse acquisition ~$150M 2017. Bruno Lowagie’s career work is the closest analogue to InheritKit’s position.
- MongoDB — SSPL (Server Side Public License) — went further than AGPL; OSI refused to approve; community forks emerged. Cautionary tale about going too far.
- Elastic — BSL + SSPL; OpenSearch community fork (AWS-led). Cautionary.
- HashiCorp — BSL; OpenTofu community fork. Cautionary.
- Redis — module licence changes; similar dynamics. Cautionary.
- MySQL — original dual-licence precedent (GPL + commercial); Sun/Oracle acquisition. Rich’s original InheritKit design spec references this model.
- Qt — LGPL + commercial; similar category to iText.
What a good licence-strategy answer looks like
- Explicit recommendation per layer with rationale
- Documented internal-licence arrangement for TT’s own apps consuming InheritKit
- Template language for handling external-customer AGPL pushback
- CLA template aligned with dual-licence requirements
- Patent-grant + trademark-restriction clauses assessed
- Pricing model cross-checked against iText’s actual experience at comparable scale
- A clean story an investor or institutional reviewer would find defensible