tegwick
d3353fc22c
Five research artifacts under specs/research/, grounded in primary-source
license text fetched live rather than relying on training-data recall:
- TRSL-PriorArt-Survey.md: BSL 1.1, FSL, PolyForm Noncommercial, Fair
Source, Elastic License 2.0. Confirms TRSL's closed {MIT, Apache-2.0}
Future License enum and no per-Phase custom license text follows FSL's
deliberate fix for BSL's "Additional Use Grant" variability problem.
- TRSL-Terminology-Guardrails.md: confirms via OSI OSD Clause 6 that
pre-conversion TRSL cannot be Open Source; confirms README's existing
guardrail table without change.
- TRSL-FutureLicense-PatentPrecedent.md: MIT has no patent language; Apache
2.0 has an explicit contribution-scoped grant + litigation termination.
Recommends TRSL's pre-conversion phase also carry an express patent grant.
- TRSL-ContributorRights-Research.md: confirms via DCO 1.1 text that a DCO
alone is insufficient for TRSL's dual-future-license promise; recommends
a narrowly-scoped CLA over copyright assignment.
- TRSL-Jurisdiction-StandardTerms.md: deepens German §31/§32 UrhG (primary-
confirmed) and §307 BGB Transparenzgebot (secondary-confirmed, flagged
for counsel verification); corrects scope re: EU UCTD 93/13/EEC being
consumer-only vs. German AGB law covering B2B too. Ranks five terms most
needing objective definitions.
specs/TargetRevenueSourceLicense-Draft.md (T06) synthesizes all five into a
non-binding skeleton with every clause tagged [CONFIRMED BY RESEARCH],
[LEGAL], [WORKING DEFAULT], or [OPEN]. Per the T06 human-accept gate, the
workplan task stays `todo` — ready for review, not accepted.
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 `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).
|