diff --git a/README.md b/README.md index 4d07bc2..98b3498 100644 --- a/README.md +++ b/README.md @@ -54,7 +54,8 @@ Extracted and stabilized from the concept draft under `workplans/TREV-WP-0003-no | `examples/` | Golden Phase packages (`phase-001`, from WP-0002) | | `schemas/` | Machine-readable JSON Schemas (WP-0002) | | `src/target_revenue/` | Pure Python validators, hash chain, Outstanding Target fold, conversion detection (WP-0002) | -| `docs/adr/` | Architecture decisions; ADR-0001 (Stage 0 library stack) is **proposed**, pending human accept | +| `docs/adr/` | Architecture decisions; ADR-0001 (Stage 0 library stack) **accepted** 2026-07-29 | +| `specs/research/` | TRSL prior-art and legal-adjacent research (WP-0001) briefing `specs/TargetRevenueSourceLicense-Draft.md` | **`spec/` vs `specs/`:** The concept document predates the plural `specs/` directory and remains under `spec/` so history and cross-references stay stable. New product/tech artifacts go under `specs/`. Do not move the concept file without a deliberate migration note. @@ -62,7 +63,7 @@ Extracted and stabilized from the concept draft under `workplans/TREV-WP-0003-no | Workplan | Focus | | --- | --- | -| [TREV-WP-0001](workplans/TREV-WP-0001-license-prior-art-research.md) | Prior-art research → non-binding TRSL draft skeleton (open) | +| [TREV-WP-0001](workplans/TREV-WP-0001-license-prior-art-research.md) | Prior-art research (T01–T05 done) → non-binding TRSL draft skeleton (T06 ready for human review) | | [TREV-WP-0002](workplans/TREV-WP-0002-trust-service-foundation.md) | Schemas, pure Outstanding Target fold, golden fixture — **finished** | | [TREV-WP-0003](workplans/TREV-WP-0003-normative-core-extraction.md) | Extract stable normative core docs — T01–T05 done, T06 human review open | diff --git a/specs/TargetRevenueSourceLicense-Draft.md b/specs/TargetRevenueSourceLicense-Draft.md new file mode 100644 index 0000000..78e3fa2 --- /dev/null +++ b/specs/TargetRevenueSourceLicense-Draft.md @@ -0,0 +1,100 @@ +# 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 `spec/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 `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. + +## 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 `spec/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 `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`). + +## 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. + +--- + +## 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. diff --git a/specs/research/TRSL-ContributorRights-Research.md b/specs/research/TRSL-ContributorRights-Research.md new file mode 100644 index 0000000..b464249 --- /dev/null +++ b/specs/research/TRSL-ContributorRights-Research.md @@ -0,0 +1,50 @@ +# TRSL Contributor-Rights Research: DCO vs. CLA for Dual-Future Licensing + +**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T04) +**Not legal advice.** + +--- + +## 1. The problem TRSL creates that ordinary OSS projects don't have + +A typical open-source project only needs contributors to grant rights sufficient for **one** license (the project's current license). TRSL needs a contributor's grant to cover rights sufficient for **two** sequential states: + +1. the restricted TRSL Phase license (commercial-use-gated, source-available), and +2. the eventual, automatic, irrevocable Future License (MIT or Apache-2.0) at conversion — which the licensor must be able to promise **today**, before conversion has happened, on behalf of every contribution folded into that Milestone Release. + +This is the specific gap `spec/TargetRevenueLicenseConcept.md` §21.4 already identifies ("The project must hold sufficient rights to promise both... Contributor arrangements may therefore require copyright assignment or an appropriately broad contributor license agreement"). + +## 2. What the Developer Certificate of Origin actually certifies + +Full DCO 1.1 text (confirmed via developercertificate.org, fetched 2026-07-29) has the contributor certify one of: + +> "(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that... is covered under an appropriate open source license and I have the right under that license to submit that work..." + +**Critical limitation for TRSL:** the DCO's certification is scoped to "the open source license indicated in the file" — i.e., **whatever the project's current license is at the time of the contribution.** It says nothing about a *future, different* license the project might convert to later. A DCO signed against "TRSL-0.1 (the Phase license)" certifies rights to submit under TRSL-0.1. It does **not**, on its own wording, certify that the contributor's copyright can also be relicensed under MIT or Apache-2.0 at a later Conversion Event that TRSL itself defines as automatic and irrevocable. + +**Conclusion: a DCO alone is not sufficient for TRSL.** This confirms the concept document's own instinct (§21.4) with a specific textual reason, not just a general caution. + +## 3. What CLA/assignment patterns from comparable dual-future-license projects would need to cover + +BSL and FSL projects (MariaDB and successors) are typically **single-copyright-holder or CLA-backed** precisely because they need the same two-state promise TRSL needs (restricted license now, GPL/MIT/Apache later). The general pattern observed across such projects (not fetched from a specific CLA text here — this is a structural inference from the licensing model, flagged for legal verification) requires the contributor to grant the project **either:** + +- **(a) Copyright assignment** — the contributor transfers copyright to the project entity, which then holds unencumbered rights to license the combined work under any license it chooses, including a not-yet-determined future one; or +- **(b) A broad inbound contributor license agreement (CLA)** that explicitly grants the project the right to relicense the contribution under **any license, including licenses not yet chosen at the time of contribution** — this is the key clause TRSL's CLA would need that a generic/simple CLA template might not already contain, since most CLA templates (e.g., Apache ICLA-style) are worded around granting rights to distribute "under the current or any future version of" a *named* license family, not an open-ended "whatever license the project later declares." + +## 4. Recommendation for TRSL + +**A CLA (not copyright assignment) is the better fit**, for these reasons: + +1. Assignment is a stronger ask of contributors (full copyright transfer) and tends to depress external contribution volume — a real cost for a framework whose product goal explicitly includes broader ecosystem participation (PRD stakeholders table: "Independent developer / maintainer," "Product company"). +2. A CLA can be scoped precisely to what TRSL actually needs: the right to (a) license the contribution under the current Phase's TRSL terms, and (b) automatically and irrevocably relicense it under the Phase's **already-declared** Future License (MIT or Apache-2.0 — chosen at Phase declaration time per Q3, not "any future license TRSL might invent") once the Conversion Event occurs. Because the Future License is fixed at Phase declaration (not open-ended), the CLA's forward grant can be narrow and specific rather than an unusually broad "anything, anytime" grant — this is a meaningfully easier ask than the generic pattern in §3(b) above. +3. This aligns with `CONTRIBUTING.md`'s current interim policy (external contributions blocked from governed Milestone Releases until an instrument exists) — the CLA described here is exactly that instrument, scoped as narrowly as TRSL's own Phase model allows. + +## 5. What must change if this recommendation is adopted + +- **`CONTRIBUTING.md`**: once a CLA is drafted and adopted, update the "External contributions and governed code" section to reference it and lift the current blanket block for repositories that adopt it. +- **T06 draft skeleton**: include a clause (or a pointer to a companion CLA document) stating that TRSL's automatic Future License conversion applies to the Milestone Release as a whole, and that contributor rights sufficient for that conversion are a precondition for a contribution's inclusion — mark the CLA's own text as a separate deliverable, `[LEGAL]`, not something to draft inline in the source license. +- **`spec/TargetRevenueLicenseConcept.md` §21.4**: no change needed — this research confirms and specifies its existing recommendation rather than contradicting it. + +## 6. Open item + +A model CLA text is not drafted here — that is properly a separate legal-drafting deliverable (analogous to `TargetRevenueSourceLicense-Draft.md` itself), out of scope for this research task. Recommend a follow-on deliverable `TRSL-ContributorLicenseAgreement-Draft.md` once T06 is accepted and a CLA becomes an active near-term need (i.e., when external contributions are actually being requested for a real Phase). diff --git a/specs/research/TRSL-FutureLicense-PatentPrecedent.md b/specs/research/TRSL-FutureLicense-PatentPrecedent.md new file mode 100644 index 0000000..647c342 --- /dev/null +++ b/specs/research/TRSL-FutureLicense-PatentPrecedent.md @@ -0,0 +1,54 @@ +# TRSL Future License Precedent: MIT vs. Apache-2.0 Patent Treatment + +**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T03) +**Not legal advice.** + +--- + +## 1. What the license texts actually say + +### MIT License + +Full text confirmed (opensource.org/license/mit, fetched 2026-07-29) contains **no mention of patents whatsoever** — no grant, no exclusion, no termination clause. The grant is scoped to "the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software." Whether this implies any patent license at all is a long-standing, unresolved legal debate (the license simply does not address the question either way), not a settled "yes, broad implied grant" or "no, none at all." + +### Apache License 2.0 + +Section 3 (confirmed via apache.org/licenses/LICENSE-2.0, fetched 2026-07-29) grants an explicit, affirmative patent license: + +> "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work" + +limited to patent claims "necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work" — i.e., scoped to what each contributor actually contributed, not a blanket grant over unrelated patents they might hold. + +The same section includes a **patent litigation termination clause**: + +> "If You institute patent litigation against any entity... alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed." + +This is a real, meaningful difference: Apache-2.0 gives downstream users an explicit, litigation-conditioned patent peace; MIT gives none, explicit or otherwise. + +## 2. Practical implications for TRSL's Future License choice + +1. **MIT is legally simpler but leaves patent questions open** for whatever the Milestone Release becomes after conversion. For a Phase where patentable technique is plausible (novel algorithms, hardware-adjacent work), Apache-2.0's explicit grant plus litigation-termination deterrent is the safer default. +2. **Apache-2.0's grant is contribution-scoped, not project-scoped** — it does not retroactively patent-license anything beyond what each contributor added. This matters for TRSL because a converted Milestone Release could carry contributions from multiple parties (licensor + external contributors, if/when a contributor-rights instrument exists — see `specs/research/TRSL-ContributorRights-Research.md`); Apache-2.0's per-contributor scoping is actually a good fit for that multi-party structure. +3. **Neither license's patent posture depends on which is chosen as *only* the Future License** — the pre-conversion Phase itself has no patent grant either way in the models surveyed (`specs/research/TRSL-PriorArt-Survey.md` §3.4: BSL, FSL, PolyForm all omit one pre-conversion). + +## 3. Recommendation + +**Keep both MIT and Apache-2.0 as parallel canonical Future License options** (confirms working default Q3 — no change recommended). Add explicit guidance, not a forced choice: + +- Default recommendation: **Apache-2.0** for any Phase where the Milestone Release plausibly embodies novel technique (its own patent grant plus litigation-termination clause reduces future ambiguity for adopters). +- **MIT** remains appropriate where maximum simplicity/compatibility is prioritized over patent posture (e.g., small utilities, glue code, documentation-adjacent tooling) and patent risk is judged negligible. +- This is a project-level judgment call at Phase declaration time, not a framework-level default — the framework's job is to offer both options with this guidance, not to pick one for all Phases. + +## 4. Does the pre-conversion TRSL Phase need its own express patent license? + +**Recommendation: yes, worth adding, blocked on legal for exact wording.** Rationale: + +- None of the surveyed pre-conversion license precedents (BSL, FSL, PolyForm) include one — so omitting one would not be unusual. +- But TRSL's commercial entitlement model (paying for commercial-use rights) creates a closer analogy to a *commercial software license* than a permissive OSS license, and commercial software licenses conventionally do address patent scope explicitly to avoid ambiguity about what a paying commercial licensee actually receives. +- A minimal express patent license for the pre-conversion Phase — scoped like Apache-2.0's Section 3 (contribution-scoped, litigation-terminable) — would give commercial entitlement holders the same patent peace of mind Apache-2.0 gives Future License adopters, without over-promising. + +This item should be marked `[LEGAL]` in the T06 draft skeleton: the *recommendation to include something* is a research conclusion; the *exact clause text* requires specialist review (`spec/TargetRevenueLicenseConcept.md` §21.5). + +## 5. For working defaults + +No change to `specs/OpenQuestions-WorkingDefaults.md` Q3's schema-level closed enum (`{MIT, Apache-2.0}`) — confirmed correct. Recommend a **future addition** (not a Stage 0 schema change) of a `pre_conversion_patent_grant: boolean` or similar Phase Manifest field once T06/legal review settles the exact clause — out of scope for this research task, noted here so it is not lost. diff --git a/specs/research/TRSL-Jurisdiction-StandardTerms.md b/specs/research/TRSL-Jurisdiction-StandardTerms.md new file mode 100644 index 0000000..a6143f4 --- /dev/null +++ b/specs/research/TRSL-Jurisdiction-StandardTerms.md @@ -0,0 +1,52 @@ +# TRSL Jurisdiction Research: Standard-Terms Clarity Constraints + +**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T05) +**Not legal advice.** Deepens `history/260728-InitialExploration.md` §10; verify all citations with counsel before drafting. + +--- + +## 1. German law (deepened) + +### §31 UrhG — Grant of rights of use + +Confirmed (gesetze-im-internet.de, fetched 2026-07-29): a rights grant may be non-exclusive or exclusive, and may be "limited in respect of place, time or content." This directly supports TRSL's Phase structure (a time- and content-scoped grant that automatically changes in character at the Conversion Event) as a recognized shape of rights-grant under German copyright law — no structural incompatibility found. + +### §307 BGB — Standard Business Terms (AGB) content control + +Not retrievable verbatim via automated fetch this session (the English translation page available did not include this section); the following is drawn from established secondary legal sources (Noerr, legalexo.de — search-confirmed 2026-07-29, not primary-text-confirmed) and **must be verified against primary text by counsel** before drafting: + +> Standard terms that deviate from statutory law and create an **unreasonable disadvantage** to the other party are invalid. Critically, **unclear or non-transparent clauses are per se ineffective** ("Transparenzgebot") — a term can fail §307 purely for being unclear to an average contracting party, **without needing to show substantive unfair disadvantage as well.** + +**Direct implication for TRSL:** every term that functions as a triggering condition for a legal effect — "commercial use," "Development Credit," "Outstanding Target," "Conversion Event," "settled payment" — must have an **objective, checkable definition** in the license text itself or an incorporated document, not left to the licensor's implicit understanding. This is a *higher* bar than ordinary contract drafting care; under Transparenzgebot, ambiguity alone (regardless of fairness) can void a clause. + +**Scope note (important, not previously flagged):** German AGB law (§§305–310 BGB) governs standard terms in both **consumer and business-to-business (B2B)** contracts — §310(1) BGB relaxes some protections for merchants/businesses but does **not** exempt B2B contracts from §307's core control. Since TRSL's commercial entitlement is fundamentally a B2B transaction in the common case, this exposure is not avoided merely by TRSL being commercial rather than consumer-facing software. + +### §32 UrhG — Equitable remuneration + +Confirmed (gesetze-im-internet.de, fetched 2026-07-29): absent explicit contractual remuneration terms, "equitable remuneration is deemed to have been agreed," judged against "what is customary and fair in business relations... duration, frequency, extent and time of use," and an author may compel modification of a proven-inequitable agreement. This is chiefly relevant to **contributor** compensation (`specs/research/TRSL-ContributorRights-Research.md`), not to the commercial-entitlement pricing paid by TRSL's commercial users — but any employee/contractor arrangement behind a Phase's own development work should account for it. + +## 2. EU-level constraint (scoping correction to prior research) + +Council Directive 93/13/EEC ("Unfair Contract Terms Directive") requires that consumer contract terms be drafted in "plain, intelligible language," with any ambiguity interpreted in the consumer's favor (confirmed via EUR-Lex summary, searched 2026-07-29). + +**Important scope correction:** unlike German AGB law, the **EU Unfair Contract Terms Directive applies only to consumer contracts** (business-to-consumer), not B2B. Since TRSL's primary commercial audience is expected to be businesses purchasing commercial entitlements, 93/13/EEC's direct applicability is narrower than Germany's own domestic AGB regime — it would matter chiefly for the **edge case already flagged in working default Q2** (a sole proprietor or individual who counts as a "consumer" under applicable law using the software commercially). This is exactly the kind of edge case Q2 already marks as unresolved; this research does not resolve it further but confirms it is not a theoretical concern — it is a live EU consumer-protection trigger if TRSL is ever used by an individual consumer for anything a court would characterize as commercial. + +## 3. US law (comparison point, high-level only — not researched to the same depth as German law in this pass) + +US contract law's closest analog is the **unconscionability doctrine** (UCC §2-302 and its common-law equivalents), which is a substantially higher bar than Transparenzgebot — US courts generally require both procedural unfairness (unequal bargaining power, hidden terms) *and* substantive unfairness, rather than voiding a clause for mere ambiguity alone. This means TRSL's clarity risk is **more acute under German/EU-consumer law than under general US commercial law** — a meaningful asymmetry worth stating plainly to counsel rather than assuming a single drafting standard covers all jurisdictions. A dedicated US-counsel review is recommended before treating this document as sufficient US-law coverage; this pass is intentionally shallow here (per the workplan's original framing of German law as the deepened case and other jurisdictions as comparison points). + +## 4. Terms most urgently needing objective, litigation-safe definitions + +Ranked by (a) how load-bearing the term is for the Conversion Event's legal effect, and (b) how much interpretive latitude the current concept-doc wording leaves: + +1. **"Settled payment"** (Rule 4, working default Q10) — must specify exactly what "settled" means (cleared through a payment processor? chargeback window elapsed? specific number of business days?). Highest priority: this term directly gates Development Credit recognition. +2. **"Commercial use"** (working default Q2) — already flagged as blocked-on-legal; this research adds no new resolution but confirms it is the single most Transparenzgebot-exposed term in the whole framework, since it gates whether a user owes anything at all. +3. **"Development Credit" vs. general "revenue"** — the framework's own core rules already work hard to keep this distinction sharp (Rule 2, explicit allocation); the risk is in **monetization extension text** (§`specs/MonetizationExtensionSpecification.md`) drifting back into vaguer "revenue" language per-extension. Recommend a drafting rule: every canonical/registered extension's `allocation.rule` field must itself satisfy a plain-language clarity bar, not just the core license. +4. **"Outstanding Target reaches zero"** — mathematically precise in the schema (`specs/TargetLedgerSpecification.md` §6) but the *license text's* prose description of this must match the formula exactly, with no looser paraphrase ("when the target is substantially met" would fail Transparenzgebot; "when the Outstanding Target, calculated as X, equals zero" would not). +5. **"Longstop"/degeneration terms** — currently a Stage 0 working default (Q7/Q8) rather than settled; flag as `[LEGAL]` + `[WORKING DEFAULT]` in T06 until the formula is promoted. + +## 5. Recommendation for T06 and working defaults + +- No change to `specs/OpenQuestions-WorkingDefaults.md` Q2's "blocked on legal" status — this research sharpens *why* (Transparenzgebot's ambiguity-alone-is-enough standard) without resolving the substantive definition. +- T06 draft skeleton should mark all five terms in §4 above with explicit `[LEGAL: define objectively]` markers, prioritized in the order listed. +- Recommend the eventual TRSL legal text include a dedicated **Definitions** section (common in commercial software licenses) rather than relying on inline first-use definitions scattered through the document — this is a direct, low-risk mitigation for the Transparenzgebot exposure identified in §1, and does not require resolving any of the substantive open questions to implement structurally. diff --git a/specs/research/TRSL-PriorArt-Survey.md b/specs/research/TRSL-PriorArt-Survey.md new file mode 100644 index 0000000..0890fb1 --- /dev/null +++ b/specs/research/TRSL-PriorArt-Survey.md @@ -0,0 +1,33 @@ +# TRSL Prior-Art Survey: Delayed-Open-Source and Source-Available Models + +**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T01) +**Not legal advice.** Findings below are drawn from primary-source license texts (fetched 2026-07-29) and are offered as engineering/product research to brief specialist legal drafting (`SCOPE.md` §4, `spec/TargetRevenueLicenseConcept.md` §21.5). Verify current license text before drafting, as license texts are occasionally revised by their stewards. + +--- + +## 1. Purpose + +Compare TRSL's Phase/Initial Target/Development Credit/Conversion Event model (`specs/TargetRevenueFrameworkCore.md`) against structurally similar existing licenses, to identify what TRSL should borrow, what it should deliberately diverge from, and what disputes or criticisms it should anticipate. + +## 2. Comparison table + +| License | Trigger mechanism | Pre-conversion restriction scope | Conversion wording | Notable criticism / risk | +|---|---|---|---|---| +| **Business Source License 1.1** (MariaDB) | Fixed date: "the fourth anniversary of the first publicly available distribution" of a version, or an earlier specified Change Date | Free to copy/modify/redistribute/non-production use; **production use** requires an Additional Use Grant or a commercial license | "The rights granted in the paragraph above terminate" at the Change Date; rights continue under the **Change License** (must be GPLv2-or-later or GPLv2-compatible) | The **Additional Use Grant is per-licensor free text** — MariaDB's own successor (FSL) calls this "a serious flaw, because it creates too much variability... each implementation essentially becomes a distinct license." No patent grant in the license text. | +| **Functional Source License (FSL)** | **Fixed, per-version**: two years from each version's release date, regardless of distribution channel (git commit, package registry, physical media) | Nearly all use permitted ("run it for almost all purposes, study it, modify it, distribute your changes"); the one restriction is not to "undermine its producer" (a vaguer, narrower restriction than BSL's production-use gate) | Converts automatically to **either MIT or Apache-2.0** (project picks one template: FSL-1.1-ALv2 or FSL-1.1-MIT) — no Change License variability | Deliberately narrows BSL's design space to fix BSL's variability problem: only two possible Future Licenses, only one trigger (time), no per-licensor Additional Use Grant text to negotiate. TRSL's `future_license` closed enum (`{MIT, Apache-2.0}`, working default Q3) already follows this FSL pattern rather than BSL's open Change License. | +| **PolyForm Noncommercial 1.0.0** | **None.** No conversion mechanism of any kind. | Personal/research/hobby use; charitable, educational, public-research, public-safety/health, environmental, and government institutional use — all unconditional on funding source | N/A — permanently noncommercial-only unless the licensor separately relicenses | Useful as a **noncommercial-use scope reference** (working default Q1 already models on it) but is not itself a delayed-open-source license — it has no path to the commons at all. TRSL must not be confused with a "PolyForm-with-a-timer"; it needs its own conversion clause. | +| **Fair Source** (fair.io) | **Definitional, not a single license text**: requires "Delayed Open Source Publication (DOSP)" as one of three defining criteria, but does not itself fix a timeline | "Minimal restrictions to protect the producer's business model" — deliberately unspecified/evolving per adopting project | DOSP is described as "distributing software under a proprietary license initially, then subsequently publishing that software's source code under an Open Source (OSI-approved) license" — a category, not a mechanism | Fair Source is a **positioning brand/definition**, not an enforceable license text — TRSL sits inside this category (its pre-conversion state is Fair-Source-shaped) but must still supply its own concrete legal mechanism, unlike BSL/FSL which are ready-to-use texts. | +| **Elastic License 2.0** | **None.** No time or revenue trigger. | Prohibits providing the software "as a hosted or managed service" that exposes "any substantial set of the features or functionality"; prohibits circumventing license-key mechanisms | N/A — permanent restriction, not a delayed-open-source model at all | Included as a **negative example**: ELv2 shows what TRSL is *not* — a permanent SaaS-carve-out license with no commons endpoint. Useful contrast for explaining to readers why TRSL's automatic conversion is the differentiating feature, not the commercial restriction itself. | + +## 3. What TRSL should take from this survey + +1. **Follow FSL's simplification over BSL's flexibility.** BSL's per-licensor Additional Use Grant text is the single most-criticized design choice in this family (by BSL's own successor). TRSL's working default of a closed `{MIT, Apache-2.0}` Future License enum and no per-Phase custom Change License text is the right call — confirmed against real precedent, not just internal preference. +2. **FSL's per-version fixed trigger is a useful contrast to TRSL's revenue-plus-remission model.** FSL treats every version identically (2 years, always). TRSL's Target Multiple + Development Credit + Remission Credit model is more expressive (lets commercial validation *shorten* the effective protection period) but also more novel — meaning TRSL carries more of the definitional burden itself; it cannot lean on FSL's or BSL's established case law or community familiarity for its trigger mechanism, only for its *conversion clause structure* (automatic, self-executing, no discretionary declaration). +3. **PolyForm Noncommercial's use-case taxonomy is a solid drafting reference for TRSL's noncommercial permitted-use clause** (working default Q1), but contributes nothing to TRSL's conversion mechanism, which must be original. +4. **None of BSL, FSL, or PolyForm include a patent grant in the pre-conversion license text.** This is worth flagging for T03/T06: TRSL is not deviating from norm by omitting one, but concept §21.1 already lists "patent treatment" as a required license component — worth deciding deliberately rather than by silent omission (see `specs/research/TRSL-FutureLicense-PatentPrecedent.md`). +5. **Elastic License 2.0 confirms the category boundary**: a "source-available with commercial restriction" license is not automatically a delayed-open-source license. TRSL's identity is specifically the *automatic, self-executing conversion* — this should be emphasized in any explainer material (README, T06 draft) as the feature that distinguishes TRSL from the larger and more common "just restrict commercial use forever" category that ELv2 represents. + +## 4. Open items for T06 + +- Whether TRSL should structure its automatic-conversion clause closer to BSL/FSL's "rights terminate, new rights granted under Future License" phrasing (both use this two-step structure) — recommended as a starting point, since it's now confirmed as the established pattern in this license family, not a TRSL invention. +- Whether an Additional-Use-Grant-style mechanism (BSL) has any place in TRSL for describing *what monetization profile currently applies to a Phase* — recommendation: **no**, keep that in the Phase Manifest/Trust Service layer (per `specs/TargetRevenueFrameworkCore.md`'s license/Trust-Service separation), not in per-Phase custom license text, to avoid reintroducing BSL's variability problem. diff --git a/specs/research/TRSL-Terminology-Guardrails.md b/specs/research/TRSL-Terminology-Guardrails.md new file mode 100644 index 0000000..d3f31c3 --- /dev/null +++ b/specs/research/TRSL-Terminology-Guardrails.md @@ -0,0 +1,50 @@ +# TRSL Terminology Guardrails: OSI Open Source Definition vs. Fair Source + +**Document status:** Research artifact, Stage 0 (`workplans/TREV-WP-0001-license-prior-art-research.md` T02) +**Not legal advice.** + +--- + +## 1. Why pre-conversion TRSL cannot be called "Open Source" + +The Open Source Definition (OSD), maintained by the Open Source Initiative, states two relevant clauses verbatim (fetched from opensource.org/osd, 2026-07-29): + +> **Clause 5 — No Discrimination Against Persons or Groups:** "The license must not discriminate against any person or group of persons." +> +> **Clause 6 — No Discrimination Against Fields of Endeavor:** "The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research." + +TRSL's pre-conversion state requires a commercial entitlement for commercial use (`spec/TargetRevenueLicenseConcept.md` §21.1). That is precisely a field-of-endeavor restriction — "may not be used commercially without payment" restricts a specific field of endeavor (business use) exactly as Clause 6's own example describes. **There is no ambiguity here**: pre-conversion TRSL cannot be described as Open Source under the OSD, full stop, regardless of how the restriction is priced, credited, or eventually lifted. + +This is not a defect to work around — it is a category TRSL should state plainly and repeatedly, because the alternative (softening the language to sound more "open" than it is) is exactly the kind of ambiguity that creates legal and reputational risk later. + +## 2. How Fair Source's framing applies + +Fair Source's own definition (fetched from fair.io/about, 2026-07-29) requires three things of software claiming the label: + +> "(1) is publicly available to read; (2) allows use, modification, and redistribution with minimal restrictions to protect the producer's business model; and (3) undergoes delayed Open Source publication (DOSP)." + +TRSL's pre-conversion Phase satisfies all three: + +1. Source-available (public source, readable). +2. Modification/redistribution permitted subject to the commercial-use restriction (a "minimal restriction to protect the producer's business model" in Fair Source's own words). +3. TRSL's Conversion Event **is** a DOSP mechanism — a mandatory, eventual transition to an OSI-approved license (MIT/Apache-2.0). + +Fair Source is explicitly a **category label and definition, not a specific enforceable license text** — it does not itself specify a trigger mechanism. TRSL's revenue/Target-based trigger is therefore a *novel instance* within the Fair Source category, not something Fair Source's own material provides precedent for at the mechanism level (see `specs/research/TRSL-PriorArt-Survey.md` §3.2 for the closer per-version time-trigger precedent from FSL). + +## 3. Recommended terminology guardrail (confirms and slightly sharpens README's existing table) + +| State | Accurate label | Must never be called | +|---|---|---| +| Pre-conversion, noncommercial use | **Source-available** (Fair Source category; permitted uses per Phase terms) | "Open Source," "free software," "OSS" | +| Pre-conversion, commercial use | **Commercially licensed** / entitlement required | "Open Source with a paid tier," "open core" (open core implies a *separate* proprietary add-on to an already-open core, which is a different structure — TRSL restricts the core itself, temporarily) | +| Post-conversion | **Open source** under the declared Future License (MIT or Apache-2.0), and may then be described as OSI-approved Open Source without qualification | — | + +This matches and confirms the guardrail table already published in `README.md` — this research did not surface a reason to change it (working default Q1/Q2 stand as published). + +## 4. Recommendation for Q1/Q2 (working defaults) + +No change recommended to `specs/OpenQuestions-WorkingDefaults.md` Q1 (noncommercial rights, blocked on legal for exact clause text) or Q2 (definition of commercial use, blocked on legal for edge cases). This research confirms the *category framing* (source-available vs. Fair Source vs. Open Source) is correct and stable; it does not resolve the still-open edge cases in Q2 (affiliates, contractors, mixed-purpose, public-sector use), which remain genuinely open and are better addressed by T05's jurisdiction research plus specialist review, not by this terminology-framing task. + +## 5. For T06 (draft skeleton) + +Use this document's §3 table as the authoritative terminology reference when drafting the TRSL preamble/recitals. Any occurrence of the word "open" in marketing or documentation copy describing a not-yet-converted Phase should be flagged as a defect, per this guardrail. diff --git a/workplans/TREV-WP-0001-license-prior-art-research.md b/workplans/TREV-WP-0001-license-prior-art-research.md index c282195..9a9bf8a 100644 --- a/workplans/TREV-WP-0001-license-prior-art-research.md +++ b/workplans/TREV-WP-0001-license-prior-art-research.md @@ -43,11 +43,19 @@ prepare the draft and leave status `todo` or note “ready for human accept.” ```task id: TREV-WP-0001-T01 -status: todo +status: done priority: high state_hub_task_id: "d2953e5a-7831-4593-93fd-3bd8faaec48d" ``` +Result 2026-07-29: `specs/research/TRSL-PriorArt-Survey.md` produced, +grounded in primary-source license text fetched live (BSL 1.1, FSL, +PolyForm Noncommercial, Fair Source, Elastic License 2.0, OSI OSD). Key +finding: FSL's fixed two-license, single-trigger design was created +specifically to fix BSL's "Additional Use Grant" variability problem — +confirms TRSL's closed `{MIT, Apache-2.0}` enum and no per-Phase custom +license text is the right call, not just an internal preference. + Survey and compare structurally similar models: Business Source License 1.1 (MariaDB), Functional Source License (FSL), PolyForm Noncommercial / PolyForm Shield, Fair Source (fair.io), Elastic License 2.0, Sentry's SSPL- @@ -64,11 +72,19 @@ diffed directly against TRSL's Phase/Target/Conversion model in ```task id: TREV-WP-0001-T02 -status: todo +status: done priority: high state_hub_task_id: "3f6166cd-d8a3-4f2e-a52e-28ecd08a8cf1" ``` +Result 2026-07-29: `specs/research/TRSL-Terminology-Guardrails.md` produced. +Confirmed via primary OSD text (Clause 6, field-of-endeavor +non-discrimination) that pre-conversion TRSL cannot be Open Source, no +ambiguity. Confirmed Fair Source's three-part DOSP definition applies +cleanly to TRSL's structure. No change recommended to README's existing +guardrail table or to working defaults Q1/Q2 — this research confirms the +category framing rather than changing it. + Confirm and document precisely why TRSL's pre-conversion state cannot be described as "Open Source" under the OSI Open Source Definition (field-of-endeavour non-discrimination), and how Fair Source's "source @@ -85,11 +101,20 @@ improves the wording (human accept if changing published working defaults). ```task id: TREV-WP-0001-T03 -status: todo +status: done priority: medium state_hub_task_id: "0df9125d-0bbb-4e21-8b04-8a5dda02d140" ``` +Result 2026-07-29: `specs/research/TRSL-FutureLicense-PatentPrecedent.md` +produced. Confirmed via primary text: MIT has zero patent language (implied +grant legally unsettled); Apache-2.0 has an explicit, contribution-scoped +patent grant plus litigation-termination clause. No change to working +default Q3 (both remain canonical options); added Phase-author guidance +(Apache-2.0 default where patentable technique is plausible). Recommends +TRSL's pre-conversion Phase also carry a minimal express patent license +(Apache-2.0-shaped) — new item, marked `[LEGAL]` in the T06 draft. + Research the practical and legal tradeoffs between MIT and Apache-2.0 as canonical Future Licenses, focusing on: the extent and legal certainty of any implied patent grant under MIT, Apache-2.0's explicit patent grant and @@ -106,11 +131,24 @@ Working default already allows both Future Licenses in schemas ```task id: TREV-WP-0001-T04 -status: todo +status: done priority: medium state_hub_task_id: "25fbf15c-60c4-4284-af84-49d109b74cf8" ``` +Result 2026-07-29: `specs/research/TRSL-ContributorRights-Research.md` +produced. Confirmed via primary DCO 1.1 text that its certification is +scoped to "the open source license indicated in the file" at time of +contribution — it does not extend to a future, different Future License, +so a DCO alone is insufficient (concept §21.4's instinct confirmed with a +specific textual reason). Recommends a CLA (not copyright assignment, +to preserve contribution volume), scoped narrowly to the current Phase's +TRSL terms plus the Phase's already-declared Future License. `CONTRIBUTING.md` +interim policy (external contributions blocked pending an instrument) +left unchanged — this research specifies the eventual instrument's shape +but does not itself create it; recommends a future dedicated +`TRSL-ContributorLicenseAgreement-Draft.md` deliverable when needed. + Research contributor license agreement (CLA) and copyright assignment patterns used by projects that must promise two future states (a restricted phase license plus an eventual permissive license) — e.g. how BSL/FSL-based @@ -128,11 +166,23 @@ instrument exists). ```task id: TREV-WP-0001-T05 -status: todo +status: done priority: medium state_hub_task_id: "1fe4b444-90b0-49d0-8d2a-9e3a99d2822a" ``` +Result 2026-07-29: `specs/research/TRSL-Jurisdiction-StandardTerms.md` +produced. Confirmed §31/§32 UrhG text via primary source; §307 BGB +Transparenzgebot confirmed via secondary legal sources (not primary-text- +verified this session — flagged for counsel verification). Important +scoping correction surfaced: German AGB law applies to B2B contracts too +(not just consumer), while the EU Unfair Contract Terms Directive 93/13/EEC +is consumer-only — a real asymmetry not previously distinguished. Ranked +five terms most needing objective definitions (settled payment first; +commercial use second). No change to working default Q2's "blocked on +legal" status; recommends a dedicated Definitions section in the eventual +license text. + Deepen the German-law groundwork already sketched in `history/260728-InitialExploration.md` §10 (§31 UrhG scoped rights of use, §307 BGB standard-terms clarity requirement, §32 UrhG author remuneration) @@ -167,3 +217,10 @@ mark every clause requiring specialist legal review before use, per **Human accept gate:** Do not set this task to `done` until a human maintainer explicitly accepts the skeleton as adequate briefing material for counsel. Agent completion of the file is “ready for review,” not done. + +Result 2026-07-29: `specs/TargetRevenueSourceLicense-Draft.md` produced, +synthesizing T01–T05. Every clause tagged `[CONFIRMED BY RESEARCH]`, +`[LEGAL]`, `[WORKING DEFAULT]`, or `[OPEN]` per §0's reading key. **Status +remains `todo` — ready for human review, not accepted.** Task should be +marked `done` only after a maintainer confirms the skeleton is adequate +briefing material for counsel.