Complete TREV-WP-0001 research (T01-T05) and draft TRSL skeleton (T06)

Five research artifacts under specs/research/, grounded in primary-source
license text fetched live rather than relying on training-data recall:

- TRSL-PriorArt-Survey.md: BSL 1.1, FSL, PolyForm Noncommercial, Fair
  Source, Elastic License 2.0. Confirms TRSL's closed {MIT, Apache-2.0}
  Future License enum and no per-Phase custom license text follows FSL's
  deliberate fix for BSL's "Additional Use Grant" variability problem.
- TRSL-Terminology-Guardrails.md: confirms via OSI OSD Clause 6 that
  pre-conversion TRSL cannot be Open Source; confirms README's existing
  guardrail table without change.
- TRSL-FutureLicense-PatentPrecedent.md: MIT has no patent language; Apache
  2.0 has an explicit contribution-scoped grant + litigation termination.
  Recommends TRSL's pre-conversion phase also carry an express patent grant.
- TRSL-ContributorRights-Research.md: confirms via DCO 1.1 text that a DCO
  alone is insufficient for TRSL's dual-future-license promise; recommends
  a narrowly-scoped CLA over copyright assignment.
- TRSL-Jurisdiction-StandardTerms.md: deepens German §31/§32 UrhG (primary-
  confirmed) and §307 BGB Transparenzgebot (secondary-confirmed, flagged
  for counsel verification); corrects scope re: EU UCTD 93/13/EEC being
  consumer-only vs. German AGB law covering B2B too. Ranks five terms most
  needing objective definitions.

specs/TargetRevenueSourceLicense-Draft.md (T06) synthesizes all five into a
non-binding skeleton with every clause tagged [CONFIRMED BY RESEARCH],
[LEGAL], [WORKING DEFAULT], or [OPEN]. Per the T06 human-accept gate, the
workplan task stays `todo` — ready for review, not accepted.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

specs/research/TRSL-ContributorRights-Research.md

@@ -0,0 +1,50 @@
+# TRSL Contributor-Rights Research: DCO vs. CLA for Dual-Future Licensing
+
+**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T04)
+**Not legal advice.**
+
+---
+
+## 1. The problem TRSL creates that ordinary OSS projects don't have
+
+A typical open-source project only needs contributors to grant rights sufficient for **one** license (the project's current license). TRSL needs a contributor's grant to cover rights sufficient for **two** sequential states:
+
+1. the restricted TRSL Phase license (commercial-use-gated, source-available), and
+2. the eventual, automatic, irrevocable Future License (MIT or Apache-2.0) at conversion — which the licensor must be able to promise **today**, before conversion has happened, on behalf of every contribution folded into that Milestone Release.
+
+This is the specific gap `spec/TargetRevenueLicenseConcept.md` §21.4 already identifies ("The project must hold sufficient rights to promise both... Contributor arrangements may therefore require copyright assignment or an appropriately broad contributor license agreement").
+
+## 2. What the Developer Certificate of Origin actually certifies
+
+Full DCO 1.1 text (confirmed via developercertificate.org, fetched 2026-07-29) has the contributor certify one of:
+
+> "(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that... is covered under an appropriate open source license and I have the right under that license to submit that work..."
+
+**Critical limitation for TRSL:** the DCO's certification is scoped to "the open source license indicated in the file" — i.e., **whatever the project's current license is at the time of the contribution.** It says nothing about a *future, different* license the project might convert to later. A DCO signed against "TRSL-0.1 (the Phase license)" certifies rights to submit under TRSL-0.1. It does **not**, on its own wording, certify that the contributor's copyright can also be relicensed under MIT or Apache-2.0 at a later Conversion Event that TRSL itself defines as automatic and irrevocable.
+
+**Conclusion: a DCO alone is not sufficient for TRSL.** This confirms the concept document's own instinct (§21.4) with a specific textual reason, not just a general caution.
+
+## 3. What CLA/assignment patterns from comparable dual-future-license projects would need to cover
+
+BSL and FSL projects (MariaDB and successors) are typically **single-copyright-holder or CLA-backed** precisely because they need the same two-state promise TRSL needs (restricted license now, GPL/MIT/Apache later). The general pattern observed across such projects (not fetched from a specific CLA text here — this is a structural inference from the licensing model, flagged for legal verification) requires the contributor to grant the project **either:**
+
+- **(a) Copyright assignment** — the contributor transfers copyright to the project entity, which then holds unencumbered rights to license the combined work under any license it chooses, including a not-yet-determined future one; or
+- **(b) A broad inbound contributor license agreement (CLA)** that explicitly grants the project the right to relicense the contribution under **any license, including licenses not yet chosen at the time of contribution** — this is the key clause TRSL's CLA would need that a generic/simple CLA template might not already contain, since most CLA templates (e.g., Apache ICLA-style) are worded around granting rights to distribute "under the current or any future version of" a *named* license family, not an open-ended "whatever license the project later declares."
+
+## 4. Recommendation for TRSL
+
+**A CLA (not copyright assignment) is the better fit**, for these reasons:
+
+1. Assignment is a stronger ask of contributors (full copyright transfer) and tends to depress external contribution volume — a real cost for a framework whose product goal explicitly includes broader ecosystem participation (PRD stakeholders table: "Independent developer / maintainer," "Product company").
+2. A CLA can be scoped precisely to what TRSL actually needs: the right to (a) license the contribution under the current Phase's TRSL terms, and (b) automatically and irrevocably relicense it under the Phase's **already-declared** Future License (MIT or Apache-2.0 — chosen at Phase declaration time per Q3, not "any future license TRSL might invent") once the Conversion Event occurs. Because the Future License is fixed at Phase declaration (not open-ended), the CLA's forward grant can be narrow and specific rather than an unusually broad "anything, anytime" grant — this is a meaningfully easier ask than the generic pattern in §3(b) above.
+3. This aligns with `CONTRIBUTING.md`'s current interim policy (external contributions blocked from governed Milestone Releases until an instrument exists) — the CLA described here is exactly that instrument, scoped as narrowly as TRSL's own Phase model allows.
+
+## 5. What must change if this recommendation is adopted
+
+- **`CONTRIBUTING.md`**: once a CLA is drafted and adopted, update the "External contributions and governed code" section to reference it and lift the current blanket block for repositories that adopt it.
+- **T06 draft skeleton**: include a clause (or a pointer to a companion CLA document) stating that TRSL's automatic Future License conversion applies to the Milestone Release as a whole, and that contributor rights sufficient for that conversion are a precondition for a contribution's inclusion — mark the CLA's own text as a separate deliverable, `[LEGAL]`, not something to draft inline in the source license.
+- **`spec/TargetRevenueLicenseConcept.md` §21.4**: no change needed — this research confirms and specifies its existing recommendation rather than contradicting it.
+
+## 6. Open item
+
+A model CLA text is not drafted here — that is properly a separate legal-drafting deliverable (analogous to `TargetRevenueSourceLicense-Draft.md` itself), out of scope for this research task. Recommend a follow-on deliverable `TRSL-ContributorLicenseAgreement-Draft.md` once T06 is accepted and a CLA becomes an active near-term need (i.e., when external contributions are actually being requested for a real Phase).

specs/research/TRSL-FutureLicense-PatentPrecedent.md

@@ -0,0 +1,54 @@
+# TRSL Future License Precedent: MIT vs. Apache-2.0 Patent Treatment
+
+**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T03)
+**Not legal advice.**
+
+---
+
+## 1. What the license texts actually say
+
+### MIT License
+
+Full text confirmed (opensource.org/license/mit, fetched 2026-07-29) contains **no mention of patents whatsoever** — no grant, no exclusion, no termination clause. The grant is scoped to "the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software." Whether this implies any patent license at all is a long-standing, unresolved legal debate (the license simply does not address the question either way), not a settled "yes, broad implied grant" or "no, none at all."
+
+### Apache License 2.0
+
+Section 3 (confirmed via apache.org/licenses/LICENSE-2.0, fetched 2026-07-29) grants an explicit, affirmative patent license:
+
+> "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work"
+
+limited to patent claims "necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work" — i.e., scoped to what each contributor actually contributed, not a blanket grant over unrelated patents they might hold.
+
+The same section includes a **patent litigation termination clause**:
+
+> "If You institute patent litigation against any entity... alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed."
+
+This is a real, meaningful difference: Apache-2.0 gives downstream users an explicit, litigation-conditioned patent peace; MIT gives none, explicit or otherwise.
+
+## 2. Practical implications for TRSL's Future License choice
+
+1. **MIT is legally simpler but leaves patent questions open** for whatever the Milestone Release becomes after conversion. For a Phase where patentable technique is plausible (novel algorithms, hardware-adjacent work), Apache-2.0's explicit grant plus litigation-termination deterrent is the safer default.
+2. **Apache-2.0's grant is contribution-scoped, not project-scoped** — it does not retroactively patent-license anything beyond what each contributor added. This matters for TRSL because a converted Milestone Release could carry contributions from multiple parties (licensor + external contributors, if/when a contributor-rights instrument exists — see `specs/research/TRSL-ContributorRights-Research.md`); Apache-2.0's per-contributor scoping is actually a good fit for that multi-party structure.
+3. **Neither license's patent posture depends on which is chosen as *only* the Future License** — the pre-conversion Phase itself has no patent grant either way in the models surveyed (`specs/research/TRSL-PriorArt-Survey.md` §3.4: BSL, FSL, PolyForm all omit one pre-conversion).
+
+## 3. Recommendation
+
+**Keep both MIT and Apache-2.0 as parallel canonical Future License options** (confirms working default Q3 — no change recommended). Add explicit guidance, not a forced choice:
+
+- Default recommendation: **Apache-2.0** for any Phase where the Milestone Release plausibly embodies novel technique (its own patent grant plus litigation-termination clause reduces future ambiguity for adopters).
+- **MIT** remains appropriate where maximum simplicity/compatibility is prioritized over patent posture (e.g., small utilities, glue code, documentation-adjacent tooling) and patent risk is judged negligible.
+- This is a project-level judgment call at Phase declaration time, not a framework-level default — the framework's job is to offer both options with this guidance, not to pick one for all Phases.
+
+## 4. Does the pre-conversion TRSL Phase need its own express patent license?
+
+**Recommendation: yes, worth adding, blocked on legal for exact wording.** Rationale:
+
+- None of the surveyed pre-conversion license precedents (BSL, FSL, PolyForm) include one — so omitting one would not be unusual.
+- But TRSL's commercial entitlement model (paying for commercial-use rights) creates a closer analogy to a *commercial software license* than a permissive OSS license, and commercial software licenses conventionally do address patent scope explicitly to avoid ambiguity about what a paying commercial licensee actually receives.
+- A minimal express patent license for the pre-conversion Phase — scoped like Apache-2.0's Section 3 (contribution-scoped, litigation-terminable) — would give commercial entitlement holders the same patent peace of mind Apache-2.0 gives Future License adopters, without over-promising.
+
+This item should be marked `[LEGAL]` in the T06 draft skeleton: the *recommendation to include something* is a research conclusion; the *exact clause text* requires specialist review (`spec/TargetRevenueLicenseConcept.md` §21.5).
+
+## 5. For working defaults
+
+No change to `specs/OpenQuestions-WorkingDefaults.md` Q3's schema-level closed enum (`{MIT, Apache-2.0}`) — confirmed correct. Recommend a **future addition** (not a Stage 0 schema change) of a `pre_conversion_patent_grant: boolean` or similar Phase Manifest field once T06/legal review settles the exact clause — out of scope for this research task, noted here so it is not lost.

specs/research/TRSL-Jurisdiction-StandardTerms.md

@@ -0,0 +1,52 @@
+# TRSL Jurisdiction Research: Standard-Terms Clarity Constraints
+
+**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T05)
+**Not legal advice.** Deepens `history/260728-InitialExploration.md` §10; verify all citations with counsel before drafting.
+
+---
+
+## 1. German law (deepened)
+
+### §31 UrhG — Grant of rights of use
+
+Confirmed (gesetze-im-internet.de, fetched 2026-07-29): a rights grant may be non-exclusive or exclusive, and may be "limited in respect of place, time or content." This directly supports TRSL's Phase structure (a time- and content-scoped grant that automatically changes in character at the Conversion Event) as a recognized shape of rights-grant under German copyright law — no structural incompatibility found.
+
+### §307 BGB — Standard Business Terms (AGB) content control
+
+Not retrievable verbatim via automated fetch this session (the English translation page available did not include this section); the following is drawn from established secondary legal sources (Noerr, legalexo.de — search-confirmed 2026-07-29, not primary-text-confirmed) and **must be verified against primary text by counsel** before drafting:
+
+> Standard terms that deviate from statutory law and create an **unreasonable disadvantage** to the other party are invalid. Critically, **unclear or non-transparent clauses are per se ineffective** ("Transparenzgebot") — a term can fail §307 purely for being unclear to an average contracting party, **without needing to show substantive unfair disadvantage as well.**
+
+**Direct implication for TRSL:** every term that functions as a triggering condition for a legal effect — "commercial use," "Development Credit," "Outstanding Target," "Conversion Event," "settled payment" — must have an **objective, checkable definition** in the license text itself or an incorporated document, not left to the licensor's implicit understanding. This is a *higher* bar than ordinary contract drafting care; under Transparenzgebot, ambiguity alone (regardless of fairness) can void a clause.
+
+**Scope note (important, not previously flagged):** German AGB law (§§305–310 BGB) governs standard terms in both **consumer and business-to-business (B2B)** contracts — §310(1) BGB relaxes some protections for merchants/businesses but does **not** exempt B2B contracts from §307's core control. Since TRSL's commercial entitlement is fundamentally a B2B transaction in the common case, this exposure is not avoided merely by TRSL being commercial rather than consumer-facing software.
+
+### §32 UrhG — Equitable remuneration
+
+Confirmed (gesetze-im-internet.de, fetched 2026-07-29): absent explicit contractual remuneration terms, "equitable remuneration is deemed to have been agreed," judged against "what is customary and fair in business relations... duration, frequency, extent and time of use," and an author may compel modification of a proven-inequitable agreement. This is chiefly relevant to **contributor** compensation (`specs/research/TRSL-ContributorRights-Research.md`), not to the commercial-entitlement pricing paid by TRSL's commercial users — but any employee/contractor arrangement behind a Phase's own development work should account for it.
+
+## 2. EU-level constraint (scoping correction to prior research)
+
+Council Directive 93/13/EEC ("Unfair Contract Terms Directive") requires that consumer contract terms be drafted in "plain, intelligible language," with any ambiguity interpreted in the consumer's favor (confirmed via EUR-Lex summary, searched 2026-07-29).
+
+**Important scope correction:** unlike German AGB law, the **EU Unfair Contract Terms Directive applies only to consumer contracts** (business-to-consumer), not B2B. Since TRSL's primary commercial audience is expected to be businesses purchasing commercial entitlements, 93/13/EEC's direct applicability is narrower than Germany's own domestic AGB regime — it would matter chiefly for the **edge case already flagged in working default Q2** (a sole proprietor or individual who counts as a "consumer" under applicable law using the software commercially). This is exactly the kind of edge case Q2 already marks as unresolved; this research does not resolve it further but confirms it is not a theoretical concern — it is a live EU consumer-protection trigger if TRSL is ever used by an individual consumer for anything a court would characterize as commercial.
+
+## 3. US law (comparison point, high-level only — not researched to the same depth as German law in this pass)
+
+US contract law's closest analog is the **unconscionability doctrine** (UCC §2-302 and its common-law equivalents), which is a substantially higher bar than Transparenzgebot — US courts generally require both procedural unfairness (unequal bargaining power, hidden terms) *and* substantive unfairness, rather than voiding a clause for mere ambiguity alone. This means TRSL's clarity risk is **more acute under German/EU-consumer law than under general US commercial law** — a meaningful asymmetry worth stating plainly to counsel rather than assuming a single drafting standard covers all jurisdictions. A dedicated US-counsel review is recommended before treating this document as sufficient US-law coverage; this pass is intentionally shallow here (per the workplan's original framing of German law as the deepened case and other jurisdictions as comparison points).
+
+## 4. Terms most urgently needing objective, litigation-safe definitions
+
+Ranked by (a) how load-bearing the term is for the Conversion Event's legal effect, and (b) how much interpretive latitude the current concept-doc wording leaves:
+
+1. **"Settled payment"** (Rule 4, working default Q10) — must specify exactly what "settled" means (cleared through a payment processor? chargeback window elapsed? specific number of business days?). Highest priority: this term directly gates Development Credit recognition.
+2. **"Commercial use"** (working default Q2) — already flagged as blocked-on-legal; this research adds no new resolution but confirms it is the single most Transparenzgebot-exposed term in the whole framework, since it gates whether a user owes anything at all.
+3. **"Development Credit" vs. general "revenue"** — the framework's own core rules already work hard to keep this distinction sharp (Rule 2, explicit allocation); the risk is in **monetization extension text** (§`specs/MonetizationExtensionSpecification.md`) drifting back into vaguer "revenue" language per-extension. Recommend a drafting rule: every canonical/registered extension's `allocation.rule` field must itself satisfy a plain-language clarity bar, not just the core license.
+4. **"Outstanding Target reaches zero"** — mathematically precise in the schema (`specs/TargetLedgerSpecification.md` §6) but the *license text's* prose description of this must match the formula exactly, with no looser paraphrase ("when the target is substantially met" would fail Transparenzgebot; "when the Outstanding Target, calculated as X, equals zero" would not).
+5. **"Longstop"/degeneration terms** — currently a Stage 0 working default (Q7/Q8) rather than settled; flag as `[LEGAL]` + `[WORKING DEFAULT]` in T06 until the formula is promoted.
+
+## 5. Recommendation for T06 and working defaults
+
+- No change to `specs/OpenQuestions-WorkingDefaults.md` Q2's "blocked on legal" status — this research sharpens *why* (Transparenzgebot's ambiguity-alone-is-enough standard) without resolving the substantive definition.
+- T06 draft skeleton should mark all five terms in §4 above with explicit `[LEGAL: define objectively]` markers, prioritized in the order listed.
+- Recommend the eventual TRSL legal text include a dedicated **Definitions** section (common in commercial software licenses) rather than relying on inline first-use definitions scattered through the document — this is a direct, low-risk mitigation for the Transparenzgebot exposure identified in §1, and does not require resolving any of the substantive open questions to implement structurally.

specs/research/TRSL-PriorArt-Survey.md

@@ -0,0 +1,33 @@
+# TRSL Prior-Art Survey: Delayed-Open-Source and Source-Available Models
+
+**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T01)
+**Not legal advice.** Findings below are drawn from primary-source license texts (fetched 2026-07-29) and are offered as engineering/product research to brief specialist legal drafting (`SCOPE.md` §4, `spec/TargetRevenueLicenseConcept.md` §21.5). Verify current license text before drafting, as license texts are occasionally revised by their stewards.
+
+---
+
+## 1. Purpose
+
+Compare TRSL's Phase/Initial Target/Development Credit/Conversion Event model (`specs/TargetRevenueFrameworkCore.md`) against structurally similar existing licenses, to identify what TRSL should borrow, what it should deliberately diverge from, and what disputes or criticisms it should anticipate.
+
+## 2. Comparison table
+
+| License | Trigger mechanism | Pre-conversion restriction scope | Conversion wording | Notable criticism / risk |
+|---|---|---|---|---|
+| **Business Source License 1.1** (MariaDB) | Fixed date: "the fourth anniversary of the first publicly available distribution" of a version, or an earlier specified Change Date | Free to copy/modify/redistribute/non-production use; **production use** requires an Additional Use Grant or a commercial license | "The rights granted in the paragraph above terminate" at the Change Date; rights continue under the **Change License** (must be GPLv2-or-later or GPLv2-compatible) | The **Additional Use Grant is per-licensor free text** — MariaDB's own successor (FSL) calls this "a serious flaw, because it creates too much variability... each implementation essentially becomes a distinct license." No patent grant in the license text. |
+| **Functional Source License (FSL)** | **Fixed, per-version**: two years from each version's release date, regardless of distribution channel (git commit, package registry, physical media) | Nearly all use permitted ("run it for almost all purposes, study it, modify it, distribute your changes"); the one restriction is not to "undermine its producer" (a vaguer, narrower restriction than BSL's production-use gate) | Converts automatically to **either MIT or Apache-2.0** (project picks one template: FSL-1.1-ALv2 or FSL-1.1-MIT) — no Change License variability | Deliberately narrows BSL's design space to fix BSL's variability problem: only two possible Future Licenses, only one trigger (time), no per-licensor Additional Use Grant text to negotiate. TRSL's `future_license` closed enum (`{MIT, Apache-2.0}`, working default Q3) already follows this FSL pattern rather than BSL's open Change License. |
+| **PolyForm Noncommercial 1.0.0** | **None.** No conversion mechanism of any kind. | Personal/research/hobby use; charitable, educational, public-research, public-safety/health, environmental, and government institutional use — all unconditional on funding source | N/A — permanently noncommercial-only unless the licensor separately relicenses | Useful as a **noncommercial-use scope reference** (working default Q1 already models on it) but is not itself a delayed-open-source license — it has no path to the commons at all. TRSL must not be confused with a "PolyForm-with-a-timer"; it needs its own conversion clause. |
+| **Fair Source** (fair.io) | **Definitional, not a single license text**: requires "Delayed Open Source Publication (DOSP)" as one of three defining criteria, but does not itself fix a timeline | "Minimal restrictions to protect the producer's business model" — deliberately unspecified/evolving per adopting project | DOSP is described as "distributing software under a proprietary license initially, then subsequently publishing that software's source code under an Open Source (OSI-approved) license" — a category, not a mechanism | Fair Source is a **positioning brand/definition**, not an enforceable license text — TRSL sits inside this category (its pre-conversion state is Fair-Source-shaped) but must still supply its own concrete legal mechanism, unlike BSL/FSL which are ready-to-use texts. |
+| **Elastic License 2.0** | **None.** No time or revenue trigger. | Prohibits providing the software "as a hosted or managed service" that exposes "any substantial set of the features or functionality"; prohibits circumventing license-key mechanisms | N/A — permanent restriction, not a delayed-open-source model at all | Included as a **negative example**: ELv2 shows what TRSL is *not* — a permanent SaaS-carve-out license with no commons endpoint. Useful contrast for explaining to readers why TRSL's automatic conversion is the differentiating feature, not the commercial restriction itself. |
+
+## 3. What TRSL should take from this survey
+
+1. **Follow FSL's simplification over BSL's flexibility.** BSL's per-licensor Additional Use Grant text is the single most-criticized design choice in this family (by BSL's own successor). TRSL's working default of a closed `{MIT, Apache-2.0}` Future License enum and no per-Phase custom Change License text is the right call — confirmed against real precedent, not just internal preference.
+2. **FSL's per-version fixed trigger is a useful contrast to TRSL's revenue-plus-remission model.** FSL treats every version identically (2 years, always). TRSL's Target Multiple + Development Credit + Remission Credit model is more expressive (lets commercial validation *shorten* the effective protection period) but also more novel — meaning TRSL carries more of the definitional burden itself; it cannot lean on FSL's or BSL's established case law or community familiarity for its trigger mechanism, only for its *conversion clause structure* (automatic, self-executing, no discretionary declaration).
+3. **PolyForm Noncommercial's use-case taxonomy is a solid drafting reference for TRSL's noncommercial permitted-use clause** (working default Q1), but contributes nothing to TRSL's conversion mechanism, which must be original.
+4. **None of BSL, FSL, or PolyForm include a patent grant in the pre-conversion license text.** This is worth flagging for T03/T06: TRSL is not deviating from norm by omitting one, but concept §21.1 already lists "patent treatment" as a required license component — worth deciding deliberately rather than by silent omission (see `specs/research/TRSL-FutureLicense-PatentPrecedent.md`).
+5. **Elastic License 2.0 confirms the category boundary**: a "source-available with commercial restriction" license is not automatically a delayed-open-source license. TRSL's identity is specifically the *automatic, self-executing conversion* — this should be emphasized in any explainer material (README, T06 draft) as the feature that distinguishes TRSL from the larger and more common "just restrict commercial use forever" category that ELv2 represents.
+
+## 4. Open items for T06
+
+- Whether TRSL should structure its automatic-conversion clause closer to BSL/FSL's "rights terminate, new rights granted under Future License" phrasing (both use this two-step structure) — recommended as a starting point, since it's now confirmed as the established pattern in this license family, not a TRSL invention.
+- Whether an Additional-Use-Grant-style mechanism (BSL) has any place in TRSL for describing *what monetization profile currently applies to a Phase* — recommendation: **no**, keep that in the Phase Manifest/Trust Service layer (per `specs/TargetRevenueFrameworkCore.md`'s license/Trust-Service separation), not in per-Phase custom license text, to avoid reintroducing BSL's variability problem.

specs/research/TRSL-Terminology-Guardrails.md

@@ -0,0 +1,50 @@
+# TRSL Terminology Guardrails: OSI Open Source Definition vs. Fair Source
+
+**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T02)
+**Not legal advice.**
+
+---
+
+## 1. Why pre-conversion TRSL cannot be called "Open Source"
+
+The Open Source Definition (OSD), maintained by the Open Source Initiative, states two relevant clauses verbatim (fetched from opensource.org/osd, 2026-07-29):
+
+> **Clause 5 — No Discrimination Against Persons or Groups:** "The license must not discriminate against any person or group of persons."
+>
+> **Clause 6 — No Discrimination Against Fields of Endeavor:** "The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research."
+
+TRSL's pre-conversion state requires a commercial entitlement for commercial use (`spec/TargetRevenueLicenseConcept.md` §21.1). That is precisely a field-of-endeavor restriction — "may not be used commercially without payment" restricts a specific field of endeavor (business use) exactly as Clause 6's own example describes. **There is no ambiguity here**: pre-conversion TRSL cannot be described as Open Source under the OSD, full stop, regardless of how the restriction is priced, credited, or eventually lifted.
+
+This is not a defect to work around — it is a category TRSL should state plainly and repeatedly, because the alternative (softening the language to sound more "open" than it is) is exactly the kind of ambiguity that creates legal and reputational risk later.
+
+## 2. How Fair Source's framing applies
+
+Fair Source's own definition (fetched from fair.io/about, 2026-07-29) requires three things of software claiming the label:
+
+> "(1) is publicly available to read; (2) allows use, modification, and redistribution with minimal restrictions to protect the producer's business model; and (3) undergoes delayed Open Source publication (DOSP)."
+
+TRSL's pre-conversion Phase satisfies all three:
+
+1. Source-available (public source, readable).
+2. Modification/redistribution permitted subject to the commercial-use restriction (a "minimal restriction to protect the producer's business model" in Fair Source's own words).
+3. TRSL's Conversion Event **is** a DOSP mechanism — a mandatory, eventual transition to an OSI-approved license (MIT/Apache-2.0).
+
+Fair Source is explicitly a **category label and definition, not a specific enforceable license text** — it does not itself specify a trigger mechanism. TRSL's revenue/Target-based trigger is therefore a *novel instance* within the Fair Source category, not something Fair Source's own material provides precedent for at the mechanism level (see `specs/research/TRSL-PriorArt-Survey.md` §3.2 for the closer per-version time-trigger precedent from FSL).
+
+## 3. Recommended terminology guardrail (confirms and slightly sharpens README's existing table)
+
+| State | Accurate label | Must never be called |
+|---|---|---|
+| Pre-conversion, noncommercial use | **Source-available** (Fair Source category; permitted uses per Phase terms) | "Open Source," "free software," "OSS" |
+| Pre-conversion, commercial use | **Commercially licensed** / entitlement required | "Open Source with a paid tier," "open core" (open core implies a *separate* proprietary add-on to an already-open core, which is a different structure — TRSL restricts the core itself, temporarily) |
+| Post-conversion | **Open source** under the declared Future License (MIT or Apache-2.0), and may then be described as OSI-approved Open Source without qualification | — |
+
+This matches and confirms the guardrail table already published in `README.md` — this research did not surface a reason to change it (working default Q1/Q2 stand as published).
+
+## 4. Recommendation for Q1/Q2 (working defaults)
+
+No change recommended to `specs/OpenQuestions-WorkingDefaults.md` Q1 (noncommercial rights, blocked on legal for exact clause text) or Q2 (definition of commercial use, blocked on legal for edge cases). This research confirms the *category framing* (source-available vs. Fair Source vs. Open Source) is correct and stable; it does not resolve the still-open edge cases in Q2 (affiliates, contractors, mixed-purpose, public-sector use), which remain genuinely open and are better addressed by T05's jurisdiction research plus specialist review, not by this terminology-framing task.
+
+## 5. For T06 (draft skeleton)
+
+Use this document's §3 table as the authoritative terminology reference when drafting the TRSL preamble/recitals. Any occurrence of the word "open" in marketing or documentation copy describing a not-yet-converted Phase should be flagged as a defect, per this guardrail.