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>
7.4 KiB
7.4 KiB
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
- 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. - 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).
- 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.
- 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
history/260729-TRSL-FutureLicense-PatentPrecedent.md). - 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.