target-revenue/history/260729-TRSL-ContributorRights-Research.md

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).