Add public breach/termination record to TRSL V1C1 §7 (Trust Service)

Per maintainer request after reviewing V1C1: breaches and their resolution
are transparently published via the Trust Service, giving the ecosystem a
conformity signal and creating reputational pressure toward compliance
alongside the existing commercial remedies.

- V1C1 §7.4 (new): Trust Service publishes the Licensor's breach notices,
  cure status, and termination determinations per Phase, distinguishing
  "alleged" from "determined" — a ministerial recording act, not a new
  discretionary authority (consistent with §5.4's evidence-not-cause
  principle). Named-by-default disclosure is the intended mechanism (the
  deterrent only works if the party is identifiable), flagged in Appendix A
  item 10 as the single most legally sensitive addition in this candidate:
  it touches Commercial Use Agreement confidentiality, defamation law, and
  data-protection law where the affected party is an individual.
- TSD §4.1: new Breach/Compliance Record Trust Service component, noted as
  license-driven and deferred to a future Trust Service PRD rather than
  retrofitted into WP-0002's already-finished Stage 0 scope.
- OpenQuestions-WorkingDefaults.md Q12: records the adopted default (publish
  alleged/determined breach status) and the still-open naming-policy question.
- PRD FR-10: cross-references the new public record without resolving the
  naming question.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-29 11:00:25 +02:00
parent f37f79192d
commit 236ebc2509
6 changed files with 29 additions and 0 deletions

2
.gitignore vendored
View file

@ -5,3 +5,5 @@ __pycache__/
build/
dist/
.venv/
*.swp
*.swo

View file

@ -164,6 +164,8 @@ Status `canonical` requires documented review; Stage 0 may ship them as `registe
1. Ledger is append-only; disputes create compensating entries, not silent edits.
2. Conversion already triggered remains irrevocable (Rule 9) even if a later dispute reduces Development Credit — shortfall is a commercial/audit matter, not re-restriction.
3. When the Trust Service operator is also a Phase licensor, attestations must be independently re-computable offline; public metrics must not depend on private operator judgment.
4. **(Added 2026-07-29, TRSL V1C1 §7.4)** Breach notices, cure status, and termination determinations for a Phase are published by the Trust Service as a public conformity signal, distinguishing `alleged` from `determined`. Publication is a ministerial record of the Licensor's (or a dispute process's) determination — the Trust Service does not itself decide whether a breach occurred.
5. **(Added 2026-07-29, TRSL V1C1 Appendix A item 10 — blocked on legal)** Whether the published breach record names the affected party by default (the mechanism's intended deterrent effect) or falls back to an anonymized Phase-and-category record, and how that interacts with Commercial Use Agreement confidentiality, defamation law, and data-protection law. This is the single most legally sensitive open item introduced by V1C1.
**Blocked on governance:** Full dispute SLA and third-party auditor program (PRD Phase 7).

View file

@ -253,6 +253,7 @@ The Trust Service's five core responsibilities — Phase Registry, Extension Reg
- Public records expose aggregate Development/Remission Credit, Outstanding Target, applicable extensions, and conversion status without customer-identifying detail.
- Confidential evidence (contracts, invoices, receipts) is accessible only to authorized audit/dispute parties.
- Private commercial data is never required to be uploaded to the Trust Service.
- **(Added 2026-07-29)** Breach and termination determinations under `specs/TargetRevenueSourceLicense-V1C1.md` §7.4 are published as a distinct public conformity signal; whether the affected party is named by default is an open, legally sensitive question (`specs/OpenQuestions-WorkingDefaults.md` Q12 item 5) and is not resolved by this requirement.
### FR-11 — Successive Phases

View file

@ -112,6 +112,12 @@ The Licensor may declare a new Phase covering subsequent improvements to the Sof
**7.3 Effect of termination.** Termination under this Section 7 affects only Your rights under Sections 2 and 3 for the Phase in which the breach occurred. It does not affect any rights already vested under Section 5 (Automatic Conversion) for a Milestone Release whose Conversion Event has already occurred, per Section 5.2.
**7.4 Public record of breach and resolution.** The Licensor shall cause the Trust Service to publish, as part of the public record for the affected Phase, notice of: (a) any breach notice issued under Section 7.2, stating the general nature of the breach and the date of notice; (b) whether the breach was cured within the applicable cure period, and the date of cure; and (c) any termination determination made under this Section 7, including its effective date and scope. This public record exists to give the ecosystem a transparent, verifiable conformity signal for the Phase, distinct from and in addition to the Development Credit and Remission Credit facts already published under Section 5.4 and the Target Ledger Specification.
A breach that You dispute, and that has not been finally determined, shall be recorded as **alleged**; it shall be recorded as **determined** only once the cure period has run without cure, or the dispute has been resolved against You under the applicable Commercial Use Agreement's dispute process, if any. The Trust Service shall update the record promptly upon resolution in either direction. Recording an alleged or determined breach under this Section 7.4 is a ministerial act of publishing the Licensor's determination (or a dispute process's outcome); it does not give the Trust Service discretionary authority to decide whether a breach occurred, consistent with Section 5.4's evidence-not-cause principle.
Where the affected party is a Commercial Entitlement holder, the public record identifies that party by name, unless the applicable Commercial Use Agreement or applicable law requires otherwise, in which case the record states the Phase and breach category without naming the party. [Candidate note: this naming default is the specific mechanism the Licensor intends for ecosystem accountability — see Appendix A item 10, flagged **[LEGAL, OPEN]** as the most legally sensitive item in this candidate: it interacts with confidentiality terms in Commercial Use Agreements, defamation law, and data-protection law where the affected party is an individual.]
[Candidate note: cure-period length and structure modeled on the norm observed across BSL 1.1, FSL, and Elastic License 2.0 in `history/260729-TRSL-PriorArt-Survey.md` §2; whether a cured violation should also generate a Target Ledger entry is flagged **[OPEN]** in Appendix A.]
## 8. Disclaimer of Warranty
@ -155,5 +161,8 @@ This appendix is not part of the operative license text. It tracks what must be
| 7 | (all) | Full review under German AGB law (Transparenzgebot) and, where applicable, EU consumer-protection law | **[LEGAL]** | `history/260729-TRSL-Jurisdiction-StandardTerms.md` §1§2 |
| 8 | (all) | Contributor rights sufficient to grant this License and the Future License (CLA) | **[LEGAL]**, separate deliverable | `history/260729-TRSL-ContributorRights-Research.md` §4 |
| 9 | (all) | Full specialist legal review in every jurisdiction of intended use | **[LEGAL]** | `specs/TargetRevenueLicenseConcept.md` §21.5 |
| 10 | §7.4 | Naming-by-default policy for published breach records: interaction with Commercial Use Agreement confidentiality terms, defamation law, and data-protection law where the affected party is an individual. Added 2026-07-29 at maintainer request, specifically to provide reputational/ecosystem-signal pressure toward conformity — this is a deliberate design choice, not an oversight, but its exact mechanics are the newest and least-reviewed clause in this candidate. | **[LEGAL, OPEN]** — highest priority among new items | This document §7.4; no prior research task covered public breach disclosure specifically |
**On item 10:** this is the one place in the candidate where the Licensor has chosen a specific mechanism (named public disclosure by default) ahead of dedicated legal research, because the mechanism's *value* — ecosystem trust signal and conformity pressure — depends on the party being identifiable, not merely on a breach existing in the abstract. Before V1.0, confirm at minimum: (a) whether Commercial Use Agreements can lawfully waive confidentiality for this specific purpose; (b) whether a "determined" breach (cure period lapsed, or dispute resolved) provides sufficient factual basis to avoid defamation exposure across the jurisdictions in scope; (c) whether the affected party's status as an individual (sole proprietor, contractor) triggers data-protection obligations (e.g., GDPR) that the anonymized fallback in §7.4 must handle by default rather than by exception.
**Promotion path:** per `SCOPE.md` §4 and `workplans/TREV-WP-0001-license-prior-art-research.md` T06, this candidate requires explicit human acceptance before being treated as adequate briefing material for counsel, and specialist legal sign-off on every item above before any candidate may be published as official Version 1.0.

View file

@ -206,6 +206,9 @@ Per `specs/TargetRevenueLicenseConcept.md` §14.2, every Trust Service component
| Target Ledger | Append entries; serve the entry chain per Phase | Editing, deleting, or reordering settled entries |
| Metrics | Calculate and label facts/calculations/forecasts/recommendations distinctly | Presenting a forecast as if it were a ledger fact |
| Attestation | Publish a signed statement once the ledger fold reaches zero | Requiring its own publication as a condition of conversion |
| Breach/Compliance Record | Publish the Licensor's breach notices, cure status, and termination determinations for a Phase, distinguishing `alleged` from `determined` (`specs/TargetRevenueSourceLicense-V1C1.md` §7.4) | Independently deciding whether a breach occurred — that determination is the Licensor's, or a dispute process's, never the Trust Service's own judgment |
**New in V1C1 (2026-07-29):** the Breach/Compliance Record component is a license-driven addition, not yet reflected in a Stage 0 schema — WP-0002 shipped before this clause existed. Schema and pure-fold treatment (if any is needed; this is a record-publication concern, not a Target-Ledger fold input) are deferred to the Trust Service PRD (`specs/ProductRequirementsDocument.md` §11.1 item 8), not added retroactively to WP-0002's scope. The naming-policy question in V1C1 Appendix A item 10 must be resolved before this component's public/confidential evidence tiering (§14.5) can be finalized.
---

View file

@ -234,3 +234,15 @@ ready for human review, not accepted.** Task should be marked `done` only
after a maintainer confirms V1C1 is adequate briefing material for counsel
(the deliverable this task now points to; the archived skeleton is
superseded, not the current target of the human-accept gate).
Result 2026-07-29 (maintainer review): maintainer reviewed V1C1 ("quite
strong") and requested one addition to §7 — public Trust Service
publication of breach notices, cure status, and termination
determinations, for ecosystem-signal/conformity-pressure purposes. Added as
new §7.4, with a naming-by-default mechanism (identifies the affected
party unless confidentiality/legal constraints require otherwise) flagged
as the single most legally sensitive open item in the candidate (Appendix
A item 10; `OpenQuestions-WorkingDefaults.md` Q12 item 5). Propagated to
`specs/TechnicalSpecificationDocument.md` §4.1 (new Breach/Compliance
Record Trust Service component) and `specs/ProductRequirementsDocument.md`
FR-10. Still `todo` — ready for continued human review.