tegwick
f37f79192d
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>
50 lines
6.2 KiB
Markdown
50 lines
6.2 KiB
Markdown
# 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).
|