coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge spec/ into specs/: one specs directory for the whole repo

Browse source 
Moves TargetRevenueLicenseConcept.md from the separate singular spec/
directory into specs/ (git mv, preserving history) and updates every live
cross-reference (README, CONTRIBUTING, all specs/*.md, workplans, schema
comments, source docstrings, test file) to the new path.

This resolves the spec/ vs specs/ split that history/260728-SWOT-Assessment.md
flagged as a "perpetual footgun" and recommended deciding on. The historical
record of that split and the recommendation itself are left unedited in
history/ (a dated assessment, not a living document) — only README and TSD
now document the merge as resolved, with a pointer back to that history file
for context.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-29 10:22:14 +02:00
parent 458d3a3b60
commit 55a1756f7c
20 changed files with 67 additions and 63 deletions
Download patch file Download diff file Expand all files Collapse all files

2
specs/MonetizationExtensionSpecification.md
View file

@ -2,7 +2,7 @@
**Document version:** TRF-Extension-0.1
**Status:** Normative extract, Stage 0
**Extracted from:** `spec/TargetRevenueLicenseConcept.md` §11–§12 and `specs/TechnicalSpecificationDocument.md` §3.3
**Extracted from:** `specs/TargetRevenueLicenseConcept.md` §11–§12 and `specs/TechnicalSpecificationDocument.md` §3.3
**Machine-readable counterpart:** `schemas/extension_contract.schema.json` — implemented and tested under `workplans/TREV-WP-0002-trust-service-foundation.md` T04 (`src/target_revenue/validation.py::validate_extension_contract`).
This is a complete short specification, not a stub — it freezes the extension contract and the registered/canonical distinction. It intentionally does **not** catalog all canonical profiles in depth; that remains a follow-on, `specs/CanonicalMonetizationProfiles.md` (planned).

2
specs/PhaseManifestSpecification.md
View file

@ -2,7 +2,7 @@
**Document version:** TRF-PhaseManifest-0.1
**Status:** Normative extract, Stage 0
**Extracted from:** `spec/TargetRevenueLicenseConcept.md` §16 and `specs/TechnicalSpecificationDocument.md` §3.1
**Extracted from:** `specs/TargetRevenueLicenseConcept.md` §16 and `specs/TechnicalSpecificationDocument.md` §3.1
**Machine-readable counterpart:** `schemas/phase_manifest.schema.json` — implemented and tested under `workplans/TREV-WP-0002-trust-service-foundation.md` T02 (`src/target_revenue/validation.py::validate_phase_manifest`). This document is the prose normative reference; the schema file is the authoritative machine-checkable definition. They must not drift — a change to one requires reviewing the other.
---

22
specs/ProductRequirementsDocument.md
View file

@ -3,10 +3,10 @@
Status: Draft v0.2
Date: 2026-07-28
Owner: target-revenue initiative
Primary artifacts: `INTENT.md`, `SCOPE.md`, `spec/TargetRevenueLicenseConcept.md`, `history/260728-InitialExploration.md`
Primary artifacts: `INTENT.md`, `SCOPE.md`, `specs/TargetRevenueLicenseConcept.md`, `history/260728-InitialExploration.md`
Living scope: `SCOPE.md` states Stage 0 in/out boundaries and workplan sequencing (normative extract + schemas/fold before hosted Trust Service).
Working defaults: `specs/OpenQuestions-WorkingDefaults.md` holds provisional answers to §14 items for Stage 0 unblocking; promotion into core requires human accept.
Terminology alignment: This document does not redefine terms already normatively defined in `spec/TargetRevenueLicenseConcept.md`. Where a definitive formula, rule, or schema already exists there, this PRD references it rather than restating it with variation.
Terminology alignment: This document does not redefine terms already normatively defined in `specs/TargetRevenueLicenseConcept.md`. Where a definitive formula, rule, or schema already exists there, this PRD references it rather than restating it with variation.
---
@ -26,7 +26,7 @@ The framework is intended to become a **monetization canon for exploratory softw
## 2. Problem statement
Exploratory product development creates a coordination problem (INTENT.md, `spec/TargetRevenueLicenseConcept.md` §2):
Exploratory product development creates a coordination problem (INTENT.md, `specs/TargetRevenueLicenseConcept.md` §2):
- new software capabilities require up-front work and risk-taking;
- fully proprietary licensing restricts adoption, inspection, and ecosystem participation;
@ -42,7 +42,7 @@ Without a shared framework, every project reinvents ad hoc answers to: which pay
### G1 — Minimal constitutional core
The normative kernel (Phase, Milestone Release, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, Future License) shall remain small enough to explain in one paragraph and apply consistently across projects (`spec/TargetRevenueLicenseConcept.md` §7, §22).
The normative kernel (Phase, Milestone Release, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, Future License) shall remain small enough to explain in one paragraph and apply consistently across projects (`specs/TargetRevenueLicenseConcept.md` §7, §22).
### G2 — Automatic, irrevocable conversion
@ -76,7 +76,7 @@ A later Phase may govern new development but must never withdraw or restrict rig
## 4. Non-goals
Per `INTENT.md` "Strategic Boundaries" and `spec/TargetRevenueLicenseConcept.md` §5, the framework shall not:
Per `INTENT.md` "Strategic Boundaries" and `specs/TargetRevenueLicenseConcept.md` §5, the framework shall not:
1. Govern the products or software releases of individual TRSL Phases beyond the framework's own reference material.
2. Define customer-specific commercial, hosting, support, consulting, or service agreements.
@ -111,7 +111,7 @@ Per `INTENT.md` "Strategic Boundaries" and `spec/TargetRevenueLicenseConcept.md`
### 6.1 Core entities
The seven core terms and their relationships are normatively defined in `spec/TargetRevenueLicenseConcept.md` §7 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §1, WP-0003 extract) and must not be restated with variant meaning elsewhere in the framework:
The seven core terms and their relationships are normatively defined in `specs/TargetRevenueLicenseConcept.md` §7 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §1, WP-0003 extract) and must not be restated with variant meaning elsewhere in the framework:
| Entity | Summary |
|---|---|
@ -129,7 +129,7 @@ The seven core terms and their relationships are normatively defined in `spec/Ta
### 6.2 Core lifecycle
Five verbs (§9): **Define → Allocate → Credit / Remit → Convert**. See the state diagram and rule set in `spec/TargetRevenueLicenseConcept.md` §9–§10 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §3–§4) for the authoritative lifecycle and the nine core rules (immutable phase definition, explicit allocation, no duplicate credit, settled-payment recognition, separate remission, automatic conversion, permanent prior freedom, correction without erasure, conversion irreversibility).
Five verbs (§9): **Define → Allocate → Credit / Remit → Convert**. See the state diagram and rule set in `specs/TargetRevenueLicenseConcept.md` §9–§10 (day-to-day reference: `specs/TargetRevenueFrameworkCore.md` §3–§4) for the authoritative lifecycle and the nine core rules (immutable phase definition, explicit allocation, no duplicate credit, settled-payment recognition, separate remission, automatic conversion, permanent prior freedom, correction without erasure, conversion irreversibility).
### 6.3 Monetization architecture
@ -298,7 +298,7 @@ A proposed addition to the normative core must pass three tests — universal, i
## 10. Architecture proposal
The framework is organized into four layers (`spec/TargetRevenueLicenseConcept.md` §6, mermaid diagram):
The framework is organized into four layers (`specs/TargetRevenueLicenseConcept.md` §6, mermaid diagram):
```text
Target Revenue Framework
@ -329,7 +329,7 @@ The architectural invariant governing every layer: **the license establishes leg
### 11.1 MVP scope
The MVP corresponds to the "Proposed Initial Deliverables" already identified in `spec/TargetRevenueLicenseConcept.md` §25, sequenced so that **runnable offline specification** lands before a hosted Trust Service:
The MVP corresponds to the "Proposed Initial Deliverables" already identified in `specs/TargetRevenueLicenseConcept.md` §25, sequenced so that **runnable offline specification** lands before a hosted Trust Service:
**Tier A — Stage 0 package (current delivery focus; `SCOPE.md` §5):**
@ -384,7 +384,7 @@ Workplan mapping (see `workplans/`, `SCOPE.md` §4):
### Phase 0 — Concept consolidation (largely complete)
- `INTENT.md`, `SCOPE.md`, and `spec/TargetRevenueLicenseConcept.md` established.
- `INTENT.md`, `SCOPE.md`, and `specs/TargetRevenueLicenseConcept.md` established.
- This PRD and TSD translate the concept into product goals, requirements, and schema orientation.
- Stage 0 working defaults published; SWOT assessment under `history/260728-SWOT-Assessment.md`.
@ -445,7 +445,7 @@ Workplan mapping (see `workplans/`, `SCOPE.md` §4):
## 14. Open questions
Carried forward from `spec/TargetRevenueLicenseConcept.md` §24. **Provisional Stage 0 answers** live in `specs/OpenQuestions-WorkingDefaults.md` and do not close these questions permanently.
Carried forward from `specs/TargetRevenueLicenseConcept.md` §24. **Provisional Stage 0 answers** live in `specs/OpenQuestions-WorkingDefaults.md` and do not close these questions permanently.
| # | Question | Stage 0 working default (summary) |
| --- | --- | --- |

2
specs/TargetLedgerSpecification.md
View file

@ -2,7 +2,7 @@
**Document version:** TRF-Ledger-0.1
**Status:** Normative extract, Stage 0
**Extracted from:** `spec/TargetRevenueLicenseConcept.md` §17 and `specs/TechnicalSpecificationDocument.md` §3.2
**Extracted from:** `specs/TargetRevenueLicenseConcept.md` §17 and `specs/TechnicalSpecificationDocument.md` §3.2
**Machine-readable counterpart:** `schemas/ledger_entry.schema.json` — implemented and tested under `workplans/TREV-WP-0002-trust-service-foundation.md` T03 (`src/target_revenue/hashing.py`, `src/target_revenue/fold.py`). This document is the prose normative reference; the schema and library are the authoritative machine-checkable implementation.
---

2
specs/TargetRevenueFrameworkCore.md
View file

@ -2,7 +2,7 @@
**Document version:** TRF-Core-0.1
**Status:** Normative extract, Stage 0
**Extracted from:** `spec/TargetRevenueLicenseConcept.md` §7–§10, §18, §22 (concept draft remains the source; this document freezes day-to-day terminology per `workplans/TREV-WP-0003-normative-core-extraction.md`)
**Extracted from:** `specs/TargetRevenueLicenseConcept.md` §7–§10, §18, §22 (concept draft remains the source; this document freezes day-to-day terminology per `workplans/TREV-WP-0003-normative-core-extraction.md`)
**Authority:** This is the day-to-day normative reference for terminology, formulas, lifecycle, and rules. It does not invent meaning beyond the concept document — where the two ever appear to diverge, the concept document governs and this extract must be corrected, not reinterpreted.
**Working defaults:** Several fields below are marked **Stage 0 working default** — provisional per `specs/OpenQuestions-WorkingDefaults.md`, not yet promoted to permanent norm. Everything else in this document reflects concept §24 open questions that remain genuinely open; this extract does not resolve them by omission.

1188
specs/TargetRevenueLicenseConcept.md Normal file
View file

File diff suppressed because it is too large Load diff

10
specs/TargetRevenueSourceLicense-Draft.md
View file

@ -16,7 +16,7 @@ Every clause below is one of:
- **[WORKING DEFAULT]** — reflects a Stage 0 provisional answer from `specs/OpenQuestions-WorkingDefaults.md`; not yet promoted to permanent norm.
- **[OPEN]** — genuinely undecided; concept §24 or PRD §14 question not yet resolved by any research task.
This skeleton follows the component list already identified in `spec/TargetRevenueLicenseConcept.md` §21.1, and incorporates the research findings in `specs/research/`.
This skeleton follows the component list already identified in `specs/TargetRevenueLicenseConcept.md` §21.1, and incorporates the research findings in `specs/research/`.
---
@ -39,7 +39,7 @@ Per `specs/research/TRSL-Jurisdiction-StandardTerms.md` §5, German AGB law's Tr
**[CONFIRMED BY RESEARCH]** Restricting commercial use for a protected period, while permitting broader noncommercial use, is a well-established license category (Fair Source's "minimal restrictions to protect the producer's business model," `specs/research/TRSL-Terminology-Guardrails.md` §2) with direct precedent in BSL 1.1's production-use gate and FSL's narrower "do not undermine the producer" restriction (`specs/research/TRSL-PriorArt-Survey.md` §2).
**[LEGAL]** The commercial-use gate itself (requiring a Commercial Use Agreement per `spec/TargetRevenueLicenseConcept.md` §21.2) needs drafted text; the **definition** of "commercial use" that triggers it is the single highest Transparenzgebot-exposure term in the framework (`specs/research/TRSL-Jurisdiction-StandardTerms.md` §4 item 2) and is explicitly **[OPEN]** pending legal input.
**[LEGAL]** The commercial-use gate itself (requiring a Commercial Use Agreement per `specs/TargetRevenueLicenseConcept.md` §21.2) needs drafted text; the **definition** of "commercial use" that triggers it is the single highest Transparenzgebot-exposure term in the framework (`specs/research/TRSL-Jurisdiction-StandardTerms.md` §4 item 2) and is explicitly **[OPEN]** pending legal input.
## 4. Modification and redistribution during the protected Phase [LEGAL]
@ -55,7 +55,7 @@ Not resolved by this research pass. Recommend drafting from the BSL 1.1 baseline
**[WORKING DEFAULT, Q3]** `future_license` ∈ {MIT, Apache-2.0}, chosen per Phase at declaration time. See `specs/research/TRSL-FutureLicense-PatentPrecedent.md` §3 for a project-level recommendation (Apache-2.0 default where patentable technique is plausible; MIT where simplicity is prioritized and patent risk is judged negligible) — this is Phase-author guidance, not a framework-level forced default.
**[CONFIRMED BY RESEARCH]** The conversion mechanism should follow the established two-step structure confirmed across both BSL 1.1 and FSL (`specs/research/TRSL-PriorArt-Survey.md` §2, §4): the restricted rights **terminate**, and rights under the Future License are granted **in their place**, automatically, at the Conversion Event — not a discretionary re-licensing act. This matches `spec/TargetRevenueLicenseConcept.md` Rule 6 and Rule 9 exactly and requires no structural invention; only legal wording.
**[CONFIRMED BY RESEARCH]** The conversion mechanism should follow the established two-step structure confirmed across both BSL 1.1 and FSL (`specs/research/TRSL-PriorArt-Survey.md` §2, §4): the restricted rights **terminate**, and rights under the Future License are granted **in their place**, automatically, at the Conversion Event — not a discretionary re-licensing act. This matches `specs/TargetRevenueLicenseConcept.md` Rule 6 and Rule 9 exactly and requires no structural invention; only legal wording.
**[LEGAL]** Final clause text. Recommend phrasing anchored on: "The Conversion Event occurs automatically when [Outstanding Target, as defined in §1, equals zero]. Upon the Conversion Event, the rights granted under §3 of this License terminate, and the Future License identified in the applicable Phase Manifest is granted in their place, without further act by either party." Precise legal phrasing per counsel.
@ -79,11 +79,11 @@ Per `specs/research/TRSL-Terminology-Guardrails.md` §3: pre-conversion software
## 11. What this draft does not attempt
Per `spec/TargetRevenueLicenseConcept.md` §21.3 and `SCOPE.md` §3: this draft does not attempt Commercial Use Agreement terms, Operations/Service Agreement terms, or any monetization-extension-specific pricing language — those are governed separately (`specs/MonetizationExtensionSpecification.md`).
Per `specs/TargetRevenueLicenseConcept.md` §21.3 and `SCOPE.md` §3: this draft does not attempt Commercial Use Agreement terms, Operations/Service Agreement terms, or any monetization-extension-specific pricing language — those are governed separately (`specs/MonetizationExtensionSpecification.md`).
## 12. Legal review requirement
This document is a product/engineering research synthesis, not legal advice or final license text. Per `spec/TargetRevenueLicenseConcept.md` §21.5, final drafting requires specialist review covering (at minimum): automatic conditional license grants, standard-terms law (Transparenzgebot and equivalents — `specs/research/TRSL-Jurisdiction-StandardTerms.md`), copyright and patent rights, contributor rights (`specs/research/TRSL-ContributorRights-Research.md`), audit and evidence provisions, international enforceability, consumer/business distinctions (`specs/research/TRSL-Jurisdiction-StandardTerms.md` §2's EU consumer-law scoping), and insolvency/service-discontinuity scenarios.
This document is a product/engineering research synthesis, not legal advice or final license text. Per `specs/TargetRevenueLicenseConcept.md` §21.5, final drafting requires specialist review covering (at minimum): automatic conditional license grants, standard-terms law (Transparenzgebot and equivalents — `specs/research/TRSL-Jurisdiction-StandardTerms.md`), copyright and patent rights, contributor rights (`specs/research/TRSL-ContributorRights-Research.md`), audit and evidence provisions, international enforceability, consumer/business distinctions (`specs/research/TRSL-Jurisdiction-StandardTerms.md` §2's EU consumer-law scoping), and insolvency/service-discontinuity scenarios.
---

41
specs/TechnicalSpecificationDocument.md
View file

@ -20,7 +20,7 @@ It:
* makes explicit what is **normative now**, what is **deferred to later specification work**, and what is **intentionally left open**;
* avoids encoding legal text, pricing decisions, or a fixed technology stack — those belong to the Legal Layer, canonical profiles, and future ADRs respectively.
Where a term, formula, or rule is already normatively defined in `spec/TargetRevenueLicenseConcept.md`, this document references it rather than restating it with variation. Where the PRD leaves a question open (PRD §14), this TSD does not resolve it by implication unless `specs/OpenQuestions-WorkingDefaults.md` states a **Stage 0 working default** for schema unblocking (those defaults remain provisional until human promotion into core specs).
Where a term, formula, or rule is already normatively defined in `specs/TargetRevenueLicenseConcept.md`, this document references it rather than restating it with variation. Where the PRD leaves a question open (PRD §14), this TSD does not resolve it by implication unless `specs/OpenQuestions-WorkingDefaults.md` states a **Stage 0 working default** for schema unblocking (those defaults remain provisional until human promotion into core specs).
**Normative documents (WP-0003 extract, done 2026-07-29):** day-to-day terminology, formulas, lifecycle, and rules now live in `specs/TargetRevenueFrameworkCore.md`, `specs/PhaseManifestSpecification.md`, `specs/TargetLedgerSpecification.md`, and `specs/MonetizationExtensionSpecification.md`. These extracts are stabilized references; the concept document remains the ultimate source and governs if the two ever appear to diverge.
@ -36,7 +36,7 @@ The Target Revenue Framework, as it exists in this repository, is **currently a
* `INTENT.md` — durable purpose and strategic boundaries.
* `SCOPE.md` — living Stage 0 in/out scope and sequencing rules.
* `spec/TargetRevenueLicenseConcept.md` — normative concept: terminology, formulas, rules, lifecycle.
* `specs/TargetRevenueLicenseConcept.md` — normative concept: terminology, formulas, rules, lifecycle.
* `specs/ProductRequirementsDocument.md` — product goals, scope, functional/non-functional requirements.
* `specs/TechnicalSpecificationDocument.md` (this document) — schema and component-boundary orientation.
* `specs/OpenQuestions-WorkingDefaults.md` — provisional Stage 0 defaults for open questions.
@ -51,7 +51,7 @@ JSON Schema validators, a pure Outstanding Target fold, offline conformance chec
### 1.3 Later target — reference Trust Service (PRD Phase 4b)
A centralized reference implementation providing the Phase Registry, Extension Registry, Target Ledger, Metrics, and Conversion Attestation responsibilities defined in `spec/TargetRevenueLicenseConcept.md` §14. This TSD specifies the **data model and component boundaries** that implementation must satisfy; it does not select a language, storage engine, or hosting model. Hosted implementation is **out of scope for WP-0002**.
A centralized reference implementation providing the Phase Registry, Extension Registry, Target Ledger, Metrics, and Conversion Attestation responsibilities defined in `specs/TargetRevenueLicenseConcept.md` §14. This TSD specifies the **data model and component boundaries** that implementation must satisfy; it does not select a language, storage engine, or hosting model. Hosted implementation is **out of scope for WP-0002**.
---
@ -81,7 +81,7 @@ The following constraints are **non-negotiable** and shape all downstream schema
## 3. Data Model Specifications
The following schemas formalize the YAML sketches already present in `spec/TargetRevenueLicenseConcept.md` (§16, §17, §12, §18) into typed field tables. Field names and semantics are authoritative from that document; this section adds required/recommended/optional tiering and type constraints per PRD FR-1.
The following schemas formalize the YAML sketches already present in `specs/TargetRevenueLicenseConcept.md` (§16, §17, §12, §18) into typed field tables. Field names and semantics are authoritative from that document; this section adds required/recommended/optional tiering and type constraints per PRD FR-1.
### 3.1 Phase Manifest
@ -197,7 +197,7 @@ Federation Layer → Export/verification tooling, replication protocol, s
### 4.1 Trust Service internal responsibility boundary
Per `spec/TargetRevenueLicenseConcept.md` §14.2, every Trust Service component is limited to: **observe, record, validate conformance, calculate, publish, attest.** None may **decide** whether a conversion occurs — that is a pure function of Manifest + Ledger, computable by any conformant external tool.
Per `specs/TargetRevenueLicenseConcept.md` §14.2, every Trust Service component is limited to: **observe, record, validate conformance, calculate, publish, attest.** None may **decide** whether a conversion occurs — that is a pure function of Manifest + Ledger, computable by any conformant external tool.
| Component | Responsibility | Forbidden |
|---|---|---|
@ -249,19 +249,22 @@ target-revenue/
├── LICENSE
├── history/
│ ├── 260728-InitialExploration.md
│ └── 260728-SWOT-Assessment.md
├── spec/
│ └── TargetRevenueLicenseConcept.md # normative concept (singular path, stable)
│ ├── 260728-SWOT-Assessment.md
│ └── 260728-SWOT-Followup-Spec-Workplan-Adaptations.md
├── docs/adr/
│ └── ADR-0001-stage0-library-stack.md # accepted
├── specs/
│ ├── TargetRevenueLicenseConcept.md # normative concept (ultimate source)
│ ├── ProductRequirementsDocument.md
│ ├── TechnicalSpecificationDocument.md # this document
│ ├── OpenQuestions-WorkingDefaults.md
│ └── (near-term extracts / drafts:)
│ ├── TargetRevenueFrameworkCore.md # WP-0003
│ ├── PhaseManifestSpecification.md # WP-0003
│ ├── TargetLedgerSpecification.md # WP-0003
│ ├── MonetizationExtensionSpecification.md
│ ├── TargetRevenueSourceLicense-Draft.md # WP-0001
│ ├── TargetRevenueFrameworkCore.md # WP-0003
│ ├── PhaseManifestSpecification.md # WP-0003
│ ├── TargetLedgerSpecification.md # WP-0003
│ ├── MonetizationExtensionSpecification.md # WP-0003
│ ├── TargetRevenueSourceLicense-Draft.md # WP-0001, ready for human review
│ ├── research/ # WP-0001 prior-art / legal research
│ └── (not yet started:)
│ ├── CanonicalMonetizationProfiles.md
│ ├── TargetDegenerationPolicyResearch.md
│ ├── TrustServiceProductRequirementsDocument.md # before hosted service
@ -271,11 +274,13 @@ target-revenue/
│ ├── TREV-WP-0001-license-prior-art-research.md
│ ├── TREV-WP-0002-trust-service-foundation.md
│ └── TREV-WP-0003-normative-core-extraction.md
├── schemas/ # planned — WP-0002
└── examples/ # planned — WP-0002 golden Phase package
├── schemas/ # delivered — WP-0002
├── src/target_revenue/ # delivered — WP-0002
├── examples/phase-001/ # delivered — WP-0002 golden Phase package
└── tests/ # delivered — WP-0002, 36 passing
```
**`spec/` vs `specs/` policy:** The concept document remains under singular `spec/` so git history and existing citations stay valid. New product, technical, research, and extracted normative artifacts go under plural `specs/`. Do not relocate the concept file without an explicit migration note in README and this section.
**`spec/` vs `specs/` (resolved 2026-07-29):** the concept document previously lived under a separate singular `spec/` directory; it has been merged into `specs/` so the whole repository has one specs directory. See README § `spec/` vs `specs/` for the migration note; the historical split remains visible, unedited, in `history/260728-SWOT-Assessment.md`.
---
@ -318,7 +323,7 @@ This TSD is intentionally **non-binding** with respect to:
* specific cryptographic signature algorithms;
* UI or API surface design for registry/ledger access.
Its sole purpose is to ensure that any future implementation, extension author, or federated operator can validate their work against the same schemas and boundary rules, keeping technical choices aligned with the product intent defined in `specs/ProductRequirementsDocument.md` and the normative concept in `spec/TargetRevenueLicenseConcept.md`.
Its sole purpose is to ensure that any future implementation, extension author, or federated operator can validate their work against the same schemas and boundary rules, keeping technical choices aligned with the product intent defined in `specs/ProductRequirementsDocument.md` and the normative concept in `specs/TargetRevenueLicenseConcept.md`.
---

4
specs/research/TRSL-ContributorRights-Research.md
View file

@ -12,7 +12,7 @@ A typical open-source project only needs contributors to grant rights sufficient
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").
This is the specific gap `specs/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
@ -43,7 +43,7 @@ BSL and FSL projects (MariaDB and successors) are typically **single-copyright-h
- **`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.
- **`specs/TargetRevenueLicenseConcept.md` §21.4**: no change needed — this research confirms and specifies its existing recommendation rather than contradicting it.
## 6. Open item

2
specs/research/TRSL-FutureLicense-PatentPrecedent.md
View file

@ -47,7 +47,7 @@ This is a real, meaningful difference: Apache-2.0 gives downstream users an expl
- 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).
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 (`specs/TargetRevenueLicenseConcept.md` §21.5).
## 5. For working defaults

2
specs/research/TRSL-PriorArt-Survey.md
View file

@ -1,7 +1,7 @@
# 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.
**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, `specs/TargetRevenueLicenseConcept.md` §21.5). Verify current license text before drafting, as license texts are occasionally revised by their stewards.
---

2
specs/research/TRSL-Terminology-Guardrails.md
View file

@ -13,7 +13,7 @@ The Open Source Definition (OSD), maintained by the Open Source Initiative, stat
>
> **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.
TRSL's pre-conversion state requires a commercial entitlement for commercial use (`specs/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.