Archive WP-0001 research to history/; add TRSL V1C1 license candidate
Persists the five prior-art/legal research artifacts and the original draft skeleton as dated history/ records (260729- prefix, git mv to preserve history), consistent with this repo's convention that history/ holds dated non-normative artifacts rather than living working documents: - history/260729-TRSL-PriorArt-Survey.md - history/260729-TRSL-Terminology-Guardrails.md - history/260729-TRSL-FutureLicense-PatentPrecedent.md - history/260729-TRSL-ContributorRights-Research.md - history/260729-TRSL-Jurisdiction-StandardTerms.md - history/260729-TargetRevenueSourceLicense-Draft.md (superseded) Adds specs/TargetRevenueSourceLicense-V1C1.md: the first candidate written as actual operative license text (11 sections: definitions, noncommercial grant, commercial-use restriction, patent license, automatic conversion, successive phases, termination/cure, warranty/liability, trademarks, general provisions) rather than a bracket-annotated skeleton. Carries a prominent preliminary-status notice near the top and a non-normative Appendix A tracking the nine items still needing legal resolution before any candidate can become official Version 1.0. Updates all cross-references (README, PRD, TSD, SCOPE, workplan) to the new paths; the workplan's T06 human-accept gate now points at V1C1. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
parent
55a1756f7c
commit
f37f79192d
12 changed files with 223 additions and 44 deletions
|
|
@ -337,7 +337,7 @@ The MVP corresponds to the "Proposed Initial Deliverables" already identified in
|
|||
2. `PhaseManifestSpecification.md` / `TargetLedgerSpecification.md` — field tiers and fold rules — **WP-0003**.
|
||||
3. Machine-readable schemas + pure Outstanding Target fold + golden Phase package under `examples/` — **WP-0002**.
|
||||
4. `OpenQuestions-WorkingDefaults.md` — provisional defaults for conversion-critical open questions — **done (provisional)**.
|
||||
5. `TargetRevenueSourceLicense-Draft.md` — non-binding legal drafting basis — **WP-0001** (human accept gate).
|
||||
5. `TargetRevenueSourceLicense-V1C1.md` — first candidate operative license text (Version 1, Candidate 1), non-binding — **WP-0001** (human accept gate). Supersedes the earlier draft skeleton, archived at `history/260729-TargetRevenueSourceLicense-Draft.md`.
|
||||
6. `MonetizationExtensionSpecification.md` (or Stage 0 stub) + path to `CanonicalMonetizationProfiles.md`.
|
||||
|
||||
**Tier B — After Stage 0 package:**
|
||||
|
|
@ -394,8 +394,8 @@ Workplan mapping (see `workplans/`, `SCOPE.md` §4):
|
|||
|
||||
### Phase 2 — Legal drafting basis (active — WP-0001)
|
||||
|
||||
- Produce `TargetRevenueSourceLicense-Draft.md` for specialist legal review (automatic conditional grants, standard-terms law, contributor rights, cross-border enforceability — concept §21.5).
|
||||
- Human accept required before marking draft skeleton complete.
|
||||
- Produce `TargetRevenueSourceLicense-V1C1.md` for specialist legal review (automatic conditional grants, standard-terms law, contributor rights, cross-border enforceability — concept §21.5).
|
||||
- Human accept required before a future candidate can become official V1.0.
|
||||
|
||||
### Phase 3 — Extension and profile catalog
|
||||
|
||||
|
|
|
|||
|
|
@ -1,100 +0,0 @@
|
|||
# Target Revenue Source License — Draft Skeleton (Non-Binding)
|
||||
|
||||
**Document version:** TRSL-Draft-0.1
|
||||
**Status:** DRAFT SKELETON — NOT FINAL LEGAL TEXT — NOT FOR PRODUCTION USE
|
||||
**Prepared by:** Agent synthesis of `workplans/TREV-WP-0001-license-prior-art-research.md` T01–T05, for specialist legal review
|
||||
**Human accept gate:** This document is "ready for review," not "done." `workplans/TREV-WP-0001-license-prior-art-research.md` T06 must not be marked `done` until a human maintainer accepts it as adequate briefing material for counsel (`SCOPE.md` §4, `CONTRIBUTING.md`).
|
||||
|
||||
---
|
||||
|
||||
## 0. How to read this document
|
||||
|
||||
Every clause below is one of:
|
||||
|
||||
- **[CONFIRMED BY RESEARCH]** — structurally supported by prior-art precedent or statute text fetched during T01–T05; still not legal advice, but not a novel guess either.
|
||||
- **[LEGAL]** — requires specialist legal drafting; this document states only the intent, not enforceable text.
|
||||
- **[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 `specs/TargetRevenueLicenseConcept.md` §21.1, and incorporates the research findings in `specs/research/`.
|
||||
|
||||
---
|
||||
|
||||
## 1. Definitions [LEGAL, structural recommendation CONFIRMED BY RESEARCH]
|
||||
|
||||
Per `specs/research/TRSL-Jurisdiction-StandardTerms.md` §5, German AGB law's Transparenzgebot can void a clause for ambiguity alone, independent of substantive fairness. The final license **should** include a dedicated Definitions section, not scattered inline first-use definitions. At minimum, define objectively (priority order per `specs/research/TRSL-Jurisdiction-StandardTerms.md` §4):
|
||||
|
||||
1. **Settled Payment** [LEGAL] — exact settlement mechanics (processor clearance, chargeback window, business-day count).
|
||||
2. **Commercial Use** [LEGAL, working default scope in Q2] — objective test distinguishing personal/research/nonprofit/educational use (`specs/OpenQuestions-WorkingDefaults.md` Q1–Q2) from commercial use, including treatment of affiliates, contractors, mixed-purpose, and public-sector use.
|
||||
3. **Development Credit**, **Remission Credit**, **Outstanding Target**, **Conversion Event** — already precisely defined in `specs/TargetRevenueFrameworkCore.md` §1; the license text's prose **must** match those definitions exactly, not paraphrase them.
|
||||
4. **Phase**, **Milestone Release**, **Initial Target**, **Future License** — same source.
|
||||
|
||||
## 2. Permitted noncommercial use [WORKING DEFAULT / LEGAL]
|
||||
|
||||
**[WORKING DEFAULT, Q1]** During a protected Phase, noncommercial users may view source, evaluate, test, and use the software for personal, research, educational, and recognized non-profit purposes, in a scope similar to PolyForm Noncommercial 1.0.0's use-case taxonomy (`specs/research/TRSL-PriorArt-Survey.md` §3.3; confirmed structurally applicable, not a license text to copy verbatim).
|
||||
|
||||
**[LEGAL]** Exact clause text, including modification and redistribution rights during the protected Phase, requires specialist drafting.
|
||||
|
||||
## 3. Commercial-use restriction and entitlement requirement [CONFIRMED BY RESEARCH / LEGAL]
|
||||
|
||||
**[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 `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]
|
||||
|
||||
Not resolved by this research pass. Recommend drafting from the BSL 1.1 baseline ("copy, modify, create derivative works, redistribute, and make non-production use") since it is the closest confirmed precedent (`specs/research/TRSL-PriorArt-Survey.md` §2), adapted to TRSL's commercial-use gate rather than BSL's production-use gate. **[LEGAL]** for final wording.
|
||||
|
||||
## 5. Patent treatment [CONFIRMED BY RESEARCH, recommendation given / LEGAL for text]
|
||||
|
||||
**[CONFIRMED BY RESEARCH]** Neither BSL, FSL, nor PolyForm Noncommercial include a pre-conversion patent grant (`specs/research/TRSL-PriorArt-Survey.md` §3.4) — omitting one would not be unusual. However, `specs/research/TRSL-FutureLicense-PatentPrecedent.md` §4 recommends TRSL **include** a minimal express patent license for the pre-conversion Phase, scoped like Apache-2.0 Section 3 (contribution-scoped, litigation-terminable), because TRSL's commercial-entitlement model is closer to a paid commercial license than a permissive OSS grant, and commercial licenses conventionally address patent scope explicitly.
|
||||
|
||||
**[LEGAL]** Exact clause text for the pre-conversion patent grant.
|
||||
|
||||
## 6. Future License and automatic conversion [CONFIRMED BY RESEARCH]
|
||||
|
||||
**[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 `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.
|
||||
|
||||
## 7. Termination and cure [OPEN]
|
||||
|
||||
Not researched in this pass beyond confirming that BSL/FSL/ELv2 all include violation-cure mechanisms (typically a 30-day-scale remediation window before permanent termination, per `specs/research/TRSL-PriorArt-Survey.md` §2 Elastic License 2.0 entry). **[LEGAL]** for TRSL-specific text; **[OPEN]** whether TRSL's cure period should differ from this norm given its credit/ledger model (e.g., whether a cured violation should generate a compensating ledger entry rather than simply restoring rights).
|
||||
|
||||
## 8. Warranty and liability exclusions [LEGAL]
|
||||
|
||||
Standard boilerplate across all surveyed licenses (MIT's "AS IS... WITHOUT WARRANTY" language, confirmed verbatim in `specs/research/TRSL-FutureLicense-PatentPrecedent.md` §1, is the baseline pattern). **[LEGAL]** for TRSL-specific text; no structural research finding beyond confirming this is universal practice worth following, not deviating from.
|
||||
|
||||
## 9. Contributor rights [CONFIRMED BY RESEARCH — separate deliverable]
|
||||
|
||||
**[CONFIRMED BY RESEARCH]** A Developer Certificate of Origin alone is **not** sufficient for TRSL, because its certification is scoped to "the open source license indicated in the file" at time of contribution and does not extend to a future, different Future License (`specs/research/TRSL-ContributorRights-Research.md` §2). TRSL requires a **Contributor License Agreement** (not copyright assignment — assignment is a heavier ask and depresses contribution volume) scoped narrowly to: (a) the current Phase's TRSL terms, and (b) the Phase's **already-declared** Future License at the Conversion Event (`specs/research/TRSL-ContributorRights-Research.md` §4).
|
||||
|
||||
**[LEGAL, separate deliverable]** The CLA text itself is out of scope for this license draft — recommend a dedicated `TRSL-ContributorLicenseAgreement-Draft.md` once external contributions become an active near-term need. Until then, `CONTRIBUTING.md`'s current block on external contributions to governed Milestone Releases remains in effect.
|
||||
|
||||
## 10. Terminology guardrail (non-clause, drafting instruction)
|
||||
|
||||
Per `specs/research/TRSL-Terminology-Guardrails.md` §3: pre-conversion software under this license must never be described as "Open Source," "free software," or "open core" in any recital, preamble, or accompanying documentation — it is **source-available** (noncommercial use) or **commercially licensed** (commercial use). Post-conversion, the Milestone Release may be described as Open Source under its declared Future License without qualification. This guardrail applies to marketing and documentation copy as much as to the license text itself.
|
||||
|
||||
## 11. What this draft does not attempt
|
||||
|
||||
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 `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.
|
||||
|
||||
---
|
||||
|
||||
## Summary of research inputs
|
||||
|
||||
| Source | Contribution to this draft |
|
||||
|---|---|
|
||||
| `specs/research/TRSL-PriorArt-Survey.md` | §3–§4, §6 (conversion structure, restriction scope precedent) |
|
||||
| `specs/research/TRSL-Terminology-Guardrails.md` | §10 (terminology guardrail) |
|
||||
| `specs/research/TRSL-FutureLicense-PatentPrecedent.md` | §5, §6 (patent treatment, Future License guidance) |
|
||||
| `specs/research/TRSL-ContributorRights-Research.md` | §9 (contributor rights, CLA recommendation) |
|
||||
| `specs/research/TRSL-Jurisdiction-StandardTerms.md` | §1, §3 (definitions structure, priority terms) |
|
||||
|
||||
**Next step:** human review and accept per the T06 gate, then route to specialist counsel with this document and its five research inputs as the briefing package.
|
||||
159
specs/TargetRevenueSourceLicense-V1C1.md
Normal file
159
specs/TargetRevenueSourceLicense-V1C1.md
Normal file
|
|
@ -0,0 +1,159 @@
|
|||
# Target Revenue Source License
|
||||
|
||||
**Version 1.0, Candidate 1 (V1C1)**
|
||||
|
||||
---
|
||||
|
||||
> **PRELIMINARY CANDIDATE — SUBJECT TO CHANGE — NOT FINAL — DO NOT USE FOR PRODUCTION SOFTWARE OR REAL COMMERCIAL TRANSACTIONS**
|
||||
>
|
||||
> This is the first working candidate of the Target Revenue Source License, written as operative license text rather than a research outline. It is offered so that the license can be read, tested against real scenarios, and reviewed as a whole — **not** as a final, legally binding, or production-ready document.
|
||||
>
|
||||
> Before any candidate of this license can become the official **Version 1.0** release:
|
||||
>
|
||||
> 1. it must pass specialist legal review in every jurisdiction where it will be used (see `history/260729-TRSL-Jurisdiction-StandardTerms.md` for known exposure, particularly German AGB/Transparenzgebot clarity requirements);
|
||||
> 2. every item listed in **Appendix A — Candidate Notes** below must be resolved or explicitly and knowingly accepted by the Licensor;
|
||||
> 3. a human maintainer must explicitly accept it, per `workplans/TREV-WP-0001-license-prior-art-research.md` T06 and `CONTRIBUTING.md`'s human-decision-gate policy.
|
||||
>
|
||||
> Until all three conditions are met, this document is a **drafting candidate**, not a license anyone should rely on. Bracketed placeholders (e.g. `[Licensor Legal Name]`) must be filled in per deployment; they are normal template blanks, not indicators of incompleteness — the substantive incompleteness is tracked separately in Appendix A.
|
||||
|
||||
---
|
||||
|
||||
## Preamble
|
||||
|
||||
This Target Revenue Source License ("**License**") governs the Software identified in the applicable Phase Manifest. It implements the Target Revenue Framework: a defined development Phase accumulates Development Credit and Remission Credit against an immutable Initial Target until the Milestone Release automatically and irrevocably converts to a declared permissive Future License.
|
||||
|
||||
Commercial beneficiaries fund the creation and early availability of a software improvement; once the declared target is satisfied, the governed release becomes permissively open source.
|
||||
|
||||
## 1. Definitions
|
||||
|
||||
Capitalized terms used in this License have the meanings given below. Where a term is also defined in the Phase Manifest or Target Ledger for a specific Phase, the Phase Manifest and Target Ledger govern the *values* (amounts, dates, identifiers) and this License governs the *legal effect* of those values — the two must not be read as conflicting definitions of the same concept.
|
||||
|
||||
**"Commercial Entitlement"** means a right, purchased or otherwise granted under a Commercial Use Agreement, to make Commercial Use of the Software during a Phase.
|
||||
|
||||
**"Commercial Use"** means use of the Software by or for any person or organization other than in Noncommercial Use as defined below. [Candidate note: this is a working definition per `specs/OpenQuestions-WorkingDefaults.md` Q2 and is flagged in Appendix A as needing objective refinement for affiliates, contractors, mixed-purpose, and public-sector use before V1.0.]
|
||||
|
||||
**"Commercial Use Agreement"** means the separate agreement, referenced by the applicable Phase Manifest, under which a Commercial Entitlement is purchased or granted. This License does not itself set pricing, metering, or payment terms — those are governed by the Commercial Use Agreement.
|
||||
|
||||
**"Conversion Event"** means the moment the Outstanding Target for a Phase reaches zero, as computed from the Phase Manifest and Target Ledger per the Target Ledger Specification. The Conversion Event occurs automatically and is not conditioned on any declaration, attestation, or other act by the Licensor or any Trust Service.
|
||||
|
||||
**"Development Credit"** means the portion of a collected and settled payment explicitly allocated toward satisfying the Initial Target of a specific Phase, as recorded in that Phase's Target Ledger.
|
||||
|
||||
**"Future License"** means the permissive license identified in the applicable Phase Manifest, being either the MIT License or the Apache License, Version 2.0, which applies to the Milestone Release upon the Conversion Event.
|
||||
|
||||
**"Initial Target"** means the immutable monetary target declared for a Phase in its Phase Manifest.
|
||||
|
||||
**"Licensor"** means **[Licensor Legal Name]**, the party that publishes the Phase Manifest and holds the rights necessary to grant this License and the Future License for the Milestone Release.
|
||||
|
||||
**"Milestone Release"** means the precisely identified software release designated in the applicable Phase Manifest, identified by an immutable source revision, release artifact, or cryptographic digest.
|
||||
|
||||
**"Noncommercial Use"** means use of the Software for personal purposes, private study, hobby or amateur projects; use by any charitable organization, educational institution, public research organization, or government institution acting in a non-revenue-generating capacity; or other use of a materially similar character. [Candidate note: modeled on PolyForm Noncommercial 1.0.0's use-case taxonomy per `history/260729-TRSL-PriorArt-Survey.md` §3.3; exact scope flagged in Appendix A.]
|
||||
|
||||
**"Outstanding Target"** means, at any time, `max(0, Initial Target − cumulative Development Credit − cumulative Remission Credit)` for a Phase, as computed from that Phase's Target Ledger.
|
||||
|
||||
**"Phase"** means a bounded development undertaking governed by one Initial Target, one Milestone Release, one degeneration policy, and one Future License declaration, as declared in a Phase Manifest.
|
||||
|
||||
**"Phase Manifest"** means the published, immutable declaration identifying a Phase, its Milestone Release, Initial Target, Future License, degeneration policy, and Target Ledger location, as specified in the Phase Manifest Specification.
|
||||
|
||||
**"Remission Credit"** means a transparent, non-revenue reduction of a Phase's Outstanding Target, generated under that Phase's published degeneration policy and recorded in the Target Ledger.
|
||||
|
||||
**"Settled Payment"** means a payment that has cleared through its payment processor and is no longer subject to reversal in the ordinary course (chargeback, dispute, or equivalent), as further specified by the applicable Commercial Use Agreement or monetization extension. [Candidate note: exact settlement mechanics flagged in Appendix A as the highest-priority definition needing objective refinement.]
|
||||
|
||||
**"Software"** means the source code, object code, and associated documentation of the Milestone Release identified in the applicable Phase Manifest.
|
||||
|
||||
**"Target Ledger"** means the append-only record of Development Credit, Remission Credit, and correction entries for a Phase, as specified in the Target Ledger Specification.
|
||||
|
||||
**"You"** or **"Licensee"** means the individual or entity exercising rights under this License.
|
||||
|
||||
## 2. Grant of Rights for Noncommercial Use
|
||||
|
||||
Subject to the terms of this License, the Licensor grants You a worldwide, royalty-free, non-exclusive license, during the applicable Phase, to:
|
||||
|
||||
(a) use, reproduce, and study the Software for any Noncommercial Use;
|
||||
|
||||
(b) modify the Software and create derivative works of it for any Noncommercial Use; and
|
||||
|
||||
(c) redistribute the Software and Your modifications, in source or object form, for any Noncommercial Use, provided that You include this License, unmodified, with any such redistribution, and that You do not remove or alter any copyright, patent, trademark, or attribution notices contained in the Software.
|
||||
|
||||
This grant does not extend to Commercial Use. Commercial Use requires a Commercial Entitlement under Section 3.
|
||||
|
||||
## 3. Commercial Use
|
||||
|
||||
You may not make Commercial Use of the Software during the applicable Phase unless You hold a valid, current Commercial Entitlement under a Commercial Use Agreement with the Licensor covering the applicable Phase. A Commercial Entitlement granted under one Phase's Commercial Use Agreement does not extend to a later Phase's Milestone Release unless the Commercial Use Agreement expressly says so.
|
||||
|
||||
This Section 3 states the existence and boundary of the commercial-use restriction. It does not itself set pricing, invoicing, metering, audit rights, or payment terms — those are governed exclusively by the applicable Commercial Use Agreement.
|
||||
|
||||
## 4. Patent License
|
||||
|
||||
Subject to the terms of this License, each contributor to the Software grants You, during the applicable Phase and solely to the extent of rights granted under Sections 2 and 3, a perpetual (subject to the termination below), worldwide, non-exclusive, no-charge, royalty-free patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Software, limited to those patent claims licensable by that contributor that are necessarily infringed by their contribution(s) alone or by combination of their contribution(s) with the Software.
|
||||
|
||||
If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Software or a contribution incorporated within it constitutes direct or contributory patent infringement, then any patent licenses granted to You under this Section 4 for the Software shall terminate as of the date such litigation is filed.
|
||||
|
||||
[Candidate note: modeled on Apache License 2.0 §3, adapted to this License's Phase structure, per `history/260729-TRSL-FutureLicense-PatentPrecedent.md` §4. Flagged in Appendix A pending legal review.]
|
||||
|
||||
## 5. Automatic Conversion to the Future License
|
||||
|
||||
**5.1 Automatic effect.** Upon the Conversion Event for a Phase, the rights and restrictions in Sections 3 (Commercial Use) of this License, as they apply to that Phase's Milestone Release, terminate automatically. In their place, the Milestone Release is licensed under the Future License identified in that Phase's Phase Manifest, effective as of the Conversion Event, without any further act, declaration, or attestation required by the Licensor, any Trust Service, or any other party.
|
||||
|
||||
**5.2 Irrevocability.** Once a valid Conversion Event has occurred for a Phase, no subsequent refund, chargeback, accounting correction, dispute, or termination of this License for an unrelated breach shall revoke, suspend, or otherwise impair the Future License grant for that Phase's Milestone Release. Any shortfall or dispute arising after a Conversion Event is a commercial or accounting matter between the relevant parties and does not reinstate a commercial-use restriction over already-converted Software.
|
||||
|
||||
**5.3 Prior freedom preserved.** A later Phase covering subsequent improvements to the Software does not restrict, withdraw, or otherwise affect the rights granted under the Future License for an earlier Phase's already-converted Milestone Release.
|
||||
|
||||
**5.4 Evidence, not cause.** A Trust Service may publish a Conversion Attestation documenting a Conversion Event. Such an attestation is evidence that the Conversion Event occurred; it is not a condition of, and its absence or delay does not postpone, the automatic effect described in Section 5.1. Any person may independently verify whether a Conversion Event has occurred directly from the Phase Manifest and Target Ledger.
|
||||
|
||||
## 6. Successive Phases
|
||||
|
||||
The Licensor may declare a new Phase covering subsequent improvements to the Software following a Milestone Release's Conversion Event. Each Phase is independently governed by its own Phase Manifest, Initial Target, degeneration policy, and Target Ledger. Nothing in a later Phase's Phase Manifest may be construed to reduce or withdraw rights already granted under Section 5 for an earlier Phase's Milestone Release.
|
||||
|
||||
## 7. Term and Termination
|
||||
|
||||
**7.1 Term.** This License applies to the Software for the duration of the applicable Phase, and, for the Milestone Release, indefinitely following that Phase's Conversion Event under the Future License.
|
||||
|
||||
**7.2 Termination for breach.** If You breach Section 3 (Commercial Use) or Section 2(c) (redistribution notice requirement), the Licensor may terminate this License as to You. Before such termination becomes effective, the Licensor shall provide You written notice of the breach; if You cure the breach within thirty (30) days of that notice, this License continues in effect. A second breach of the same provision within twelve (12) months may be terminated immediately without a further cure opportunity.
|
||||
|
||||
**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.
|
||||
|
||||
[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
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. THE LICENSOR DOES NOT WARRANT THAT THE SOFTWARE WILL BE ERROR-FREE OR THAT ANY PHASE WILL REACH ITS CONVERSION EVENT.
|
||||
|
||||
## 9. Limitation of Liability
|
||||
|
||||
IN NO EVENT SHALL THE LICENSOR OR ANY CONTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE, EXCEPT TO THE EXTENT SUCH LIMITATION IS PROHIBITED BY APPLICABLE LAW.
|
||||
|
||||
## 10. Trademarks
|
||||
|
||||
This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary attribution.
|
||||
|
||||
## 11. General Provisions
|
||||
|
||||
**11.1 Governing law and venue.** [To be specified per deployment; see Appendix A — jurisdiction selection affects Section 1's "Commercial Use" and "Settled Payment" definitions and is not resolved by this candidate.]
|
||||
|
||||
**11.2 Severability.** If any provision of this License is held unenforceable, the remaining provisions remain in full force, and the unenforceable provision shall be reformed to the minimum extent necessary to make it enforceable.
|
||||
|
||||
**11.3 No waiver.** Failure to enforce any provision of this License is not a waiver of future enforcement of that or any other provision.
|
||||
|
||||
**11.4 Entire agreement (as to licensing).** This License, together with the applicable Phase Manifest and, where applicable, the Commercial Use Agreement, constitutes the entire agreement between You and the Licensor regarding the Software's licensing terms. Operations, service, and consulting arrangements are governed by separate agreements, if any, and are not part of this License.
|
||||
|
||||
**11.5 Definitions control.** Marketing materials, documentation, or other non-normative communications about the Software must not describe pre-Conversion-Event Software as "Open Source," "free software," or "open core." Pre-conversion Noncommercial Use is **source-available**; pre-conversion Commercial Use requires a **Commercial Entitlement**; only post-conversion Software may be described as Open Source, under the Future License.
|
||||
|
||||
---
|
||||
|
||||
## Appendix A — Candidate Notes (Non-Normative)
|
||||
|
||||
This appendix is not part of the operative license text. It tracks what must be resolved before this candidate can become official Version 1.0, and links each item to its research basis. Removing this appendix without resolving its items would not make the license more final — it would just make the gaps invisible.
|
||||
|
||||
| # | Section | Item | Status | Research basis |
|
||||
|---|---|---|---|---|
|
||||
| 1 | §1, §3 | Objective definition of "Commercial Use" (affiliates, contractors, mixed-purpose, public-sector edge cases) | **[LEGAL, OPEN]** | `history/260729-TRSL-Jurisdiction-StandardTerms.md` §4 item 2 |
|
||||
| 2 | §1 | Exact mechanics of "Settled Payment" (processor clearance, chargeback window, business-day count) | **[LEGAL, OPEN]** — highest priority | `history/260729-TRSL-Jurisdiction-StandardTerms.md` §4 item 1 |
|
||||
| 3 | §1, §2 | Exact scope of "Noncommercial Use" | **[LEGAL]** | `history/260729-TRSL-PriorArt-Survey.md` §3.3 |
|
||||
| 4 | §4 | Patent license clause text, review against local patent law | **[LEGAL]** | `history/260729-TRSL-FutureLicense-PatentPrecedent.md` §4 |
|
||||
| 5 | §7 | Whether a cured breach should generate a compensating Target Ledger entry | **[OPEN]** | — |
|
||||
| 6 | §11.1 | Governing law and venue selection | **[LEGAL, OPEN]** | `history/260729-TRSL-Jurisdiction-StandardTerms.md` §2–§3 |
|
||||
| 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 |
|
||||
|
||||
**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.
|
||||
|
|
@ -250,7 +250,13 @@ target-revenue/
|
|||
├── history/
|
||||
│ ├── 260728-InitialExploration.md
|
||||
│ ├── 260728-SWOT-Assessment.md
|
||||
│ └── 260728-SWOT-Followup-Spec-Workplan-Adaptations.md
|
||||
│ ├── 260728-SWOT-Followup-Spec-Workplan-Adaptations.md
|
||||
│ ├── 260729-TRSL-PriorArt-Survey.md # WP-0001 research, archived
|
||||
│ ├── 260729-TRSL-Terminology-Guardrails.md # WP-0001 research, archived
|
||||
│ ├── 260729-TRSL-FutureLicense-PatentPrecedent.md # WP-0001 research, archived
|
||||
│ ├── 260729-TRSL-ContributorRights-Research.md # WP-0001 research, archived
|
||||
│ ├── 260729-TRSL-Jurisdiction-StandardTerms.md # WP-0001 research, archived
|
||||
│ └── 260729-TargetRevenueSourceLicense-Draft.md # superseded by V1C1, archived
|
||||
├── docs/adr/
|
||||
│ └── ADR-0001-stage0-library-stack.md # accepted
|
||||
├── specs/
|
||||
|
|
@ -262,8 +268,7 @@ target-revenue/
|
|||
│ ├── 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
|
||||
│ ├── TargetRevenueSourceLicense-V1C1.md # WP-0001, ready for human review
|
||||
│ └── (not yet started:)
|
||||
│ ├── CanonicalMonetizationProfiles.md
|
||||
│ ├── TargetDegenerationPolicyResearch.md
|
||||
|
|
|
|||
|
|
@ -1,50 +0,0 @@
|
|||
# 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 `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
|
||||
|
||||
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.
|
||||
- **`specs/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).
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
# 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 (`specs/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.
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
# 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.
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
# 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, `specs/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.
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
# 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 (`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.
|
||||
|
||||
## 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue