diff --git a/INTENT.md b/INTENT.md new file mode 100755 index 0000000..d5d7433 --- /dev/null +++ b/INTENT.md @@ -0,0 +1,130 @@ +# Target Revenue Framework — INTENT + +## Purpose + +This repository exists to establish the **Target Revenue Framework (TRF)** as a practical, trustworthy, and extensible foundation for financing exploratory product-driven software development while creating a transparent path into the permissive software commons. + +The framework combines a **Target Revenue Source License (TRSL)** with a **Trust Service**. A defined software development phase may be monetized until its declared target has been satisfied through Development Credits and Remission Credits. At that point, the governed Milestone Release automatically and irrevocably becomes available under its declared permissive Future License. + +## Primary Utility + +The primary utility of the repository is to provide a canonical mechanism through which software producers can: + +- declare a bounded development Phase and Milestone Release; +- define an immutable Initial Target for that Phase; +- distinguish development monetization from operations and other monetization activities; +- allocate qualifying payments transparently as Development Credits; +- reduce an unsatisfied target over time through a published remission policy; +- publish extensions, ledger states, metrics, and conversion evidence through a Trust Service; +- convert the Milestone Release automatically when its Outstanding Target reaches zero. + +The framework should make the central bargain easy to understand: + +> Commercial beneficiaries fund the creation and early availability of a software improvement; once the declared target is satisfied, the governed release becomes permissively open source. + +## Intended Users + +The framework is intended for: + +- independent developers and maintainers exploring product opportunities; +- open-source and source-available projects seeking transparent development monetization; +- product companies financing reusable software capabilities; +- commercial users willing to fund early access or development rights; +- sponsors, service providers, operators, auditors, and ecosystem participants; +- Trust Service providers and future federation operators; +- legal, financial, and technical practitioners implementing or evaluating the framework. + +## Strategic Role in the System + +The Target Revenue Framework is intended to become a **monetization canon for exploratory software products**. + +It should provide a small stable kernel that separates: + +- legal rights from commercial offers; +- development monetization from operations monetization; +- captured Development Credit from time-based Remission Credit; +- automatic license conversion from discretionary Trust Service attestation; +- canonical framework rules from extensible monetization profiles. + +The initial Trust Service should be centrally operated so the framework can evolve coherently through practical use. Its data formats, calculations, identifiers, signatures, and evidence structures should nevertheless be designed for independent verification, replication, and eventual federation. + +## Strategic Boundaries + +This repository owns: + +- the durable concepts and terminology of the Target Revenue Framework; +- the Target Revenue Source License model and future legal drafts; +- the Phase, target, credit, remission, and conversion lifecycle; +- the canonical rules for payment allocation and target satisfaction; +- the extension contract for monetization profiles; +- the Trust Service protocol, schemas, registries, metrics, and attestation model; +- the governance and federation path of the framework; +- reference documentation, examples, and conformance guidance. + +This repository does not own: + +- the products or software releases governed by individual TRSL Phases; +- customer-specific commercial, hosting, support, consulting, or service agreements; +- general tax, bookkeeping, or statutory revenue-recognition rules; +- a universal pricing model for every product or market; +- the operational implementation of every future Trust Service provider; +- guarantees that a Phase will reach its commercial target or become profitable; +- restrictions on services or hosted operations after a release converts to a permissive license. + +## Design Principles + +### Minimal constitutional core + +The normative kernel should remain small enough to explain and apply consistently. A new rule belongs in the core only when it is universal, interoperability-critical, and necessary to preserve trust. + +### Automatic and irreversible conversion + +The Milestone Release converts when the Outstanding Target reaches zero. Conversion must not depend on discretionary approval and must not be revoked by later corrections, refunds, policy changes, or new Phases. + +### Explicit economic allocation + +Payments contribute to a development target only through an explicit Development Credit allocation. Operations, services, consulting, ideation, sponsorship, and other revenue remain independent unless a published rule allocates part of them to a Phase. + +### Transparent remission + +Degeneration of the commercial protection opportunity is represented as Remission Credit, not as captured revenue. The Initial Target remains immutable and historically visible. + +### License and Trust Service separation + +The license establishes legal rights and the Conversion Event. The Trust Service publishes declarations, extensions, ledger facts, metrics, evidence, and attestations. It provides factual certainty without becoming a discretionary licensing authority. + +### Extensibility without fragmentation + +New monetization ideas should be expressible as registered or canonical profiles through a constrained extension interface. Extensions may define value, pricing, allocation, recognition, reversal, and evidence rules, but may not redefine the core concepts or conversion mechanism. + +### Open verification and federation readiness + +Authoritative records should be signed, append-only, exportable, and calculable through open deterministic rules. Centralized operation is an initial learning strategy, not a permanent dependency. + +### Permanent prior freedom + +A later Phase may govern new development but must never withdraw rights already granted for an earlier Milestone Release. + +## Maturity Target + +The repository should mature from a concept and experimental legal-economic model into a dependable framework that provides: + +1. a coherent and legally reviewed Target Revenue Source License; +2. stable normative terminology and phase semantics; +3. canonical Phase Manifest, ledger, extension, metrics, and attestation schemas; +4. a reference centralized Trust Service suitable for real projects and transactions; +5. auditable rules for Development Credits, Remission Credits, corrections, and conversion; +6. a maintained catalog of canonical and registered monetization extensions; +7. independent verification tools and portable phase evidence packages; +8. a protocol and governance model supporting multiple interoperable Trust Service providers; +9. a federated ecosystem in which records can be replicated, verified, challenged, preserved, and discovered without dependence on a single operator. + +The mature framework should be understandable enough for small projects, rigorous enough for commercial adoption, and open enough to evolve into shared infrastructure for software development monetization. + +## Stability Note + +This document defines the durable purpose and intended direction of the Target Revenue Framework repository. + +**INTENT is stable and aspirational.** `SCOPE.md`, specifications, workplans, and implementation documents should describe what is actually being designed or built at a particular time. A gap between INTENT and current SCOPE is expected while the framework matures and should be treated as a visible maturity signal rather than resolved by weakening this document. + +Changes to this file should represent a deliberate shift in what the Target Revenue Framework is meant to become, not ordinary scope evolution, implementation learning, or release planning. diff --git a/history/260728-InitialExploration.md b/history/260728-InitialExploration.md new file mode 100644 index 0000000..d947322 --- /dev/null +++ b/history/260728-InitialExploration.md @@ -0,0 +1,1959 @@ +# Initial Exploration of the Target Revenue Idea + +## Prompt 1 - Idea + +I want to discuss how to set up a license that serves as a foundation for a monetization framework of explorative product driven business models. My working title for the license is TargetRevenueLicense. The core idea is that based on a timephase that leads to a milestone defined release of the software governed by the license the license grants access as opensource software for non commercial use while commercial users need to pay tracked license and workload fees until the defined TargetRevenue amount has been captured. When the TargetRevenue has been reached the milestone defined release becomes available under permissive MIT license. The software then might or might not evolve in a next phase by definition of a next milestone governed phase of improvement. The improvement might be a bugfix, a refactoring for performance improvement, a new feature etc. and shall be classified as a 0x, 1x, 10x, 100x, 1000x improvement which in turn determines the TargetRevenue based on the estimated cost (time & material) and a fixed daily-rate for the improvement. So if you propose a 100x feature that you inspect to be implemented with 1 day with 8 businesshours billable at $1000/day the TargetRevenue will be $100000. + +## Overall assessment + +The concept is coherent and potentially powerful. I would describe it as a **revenue-triggered delayed-open-source model**: + +> A defined software improvement is temporarily protected for commercial monetization. Commercial users collectively fund a published revenue target. Once that target is reached, the corresponding milestone release automatically enters the permissive software commons. + +This creates an interesting exchange: commercial users receive early commercial access, while every payment accelerates the release becoming freely available to everyone. + +However, it should be implemented as a **framework of several coordinated instruments**, not as one monolithic license. + +## 1. Correct the “open source” terminology + +Before the conversion event, the software would not be Open Source in the OSI sense. An Open Source license may not prohibit or disadvantage commercial use; the Open Source Definition explicitly prohibits discrimination against fields of endeavour, including business use. ([Open Source Initiative][1]) + +The accurate description would therefore be: + +* **Source-available software for permitted noncommercial use** +* **Commercially licensed software for commercial use** +* **Open Source software after the Target Revenue event** + +This is similar in spirit to Fair Source and delayed open-source publication. Fair Source describes software that is publicly readable, permits use and modification subject to limited business-protection restrictions, and subsequently converts to an OSI-approved license. ([Fair][2]) + +I would therefore call the legal instrument something like: + +**Target Revenue Source License — TRSL** + +rather than abbreviating it merely as TRL. + +## 2. The basic economic formula + +Your intended formula appears to be: + +[ +\text{Base Development Cost} +============================ + +\text{Estimated Effort Days} +\times +\text{Published Daily Rate} ++ +\text{Approved Direct Costs} +] + +[ +\text{Target Revenue} +===================== + +\text{Base Development Cost} +\times +\text{Target Multiple} +] + +Your example is correct: + +[ +1\text{ day} \times $1{,}000/\text{day} \times 100 +================================================== + +$100{,}000 +] + +I would call the second factor the **Target Multiple**, not the “improvement factor.” Calling something a “100x improvement” implies that the resulting software is objectively one hundred times better, which will usually be impossible to substantiate. The actual claim is more modest: + +> We believe this improvement justifies a revenue opportunity equal to one hundred times its estimated implementation cost. + +That makes the classification explicitly a product and business hypothesis. + +A preliminary interpretation of the classes might be: + +| Class | Target | Suggested meaning | +| ----- | -------------------: | --------------------------------------------------------------- | +| 0x | Immediate conversion | Commons contribution, mandatory maintenance, trivial correction | +| 1x | Cost recovery | Implementation cost should be recovered | +| 10x | Incremental value | Material enhancement of an existing use case | +| 100x | Product-defining | Creates a significant differentiator or commercial use case | +| 1000x | Platform-defining | Enables a new platform, market, or major ecosystem capability | + +For 100x and especially 1000x classifications, I would require an accompanying **Value Hypothesis** explaining expected users, willingness to pay, avoided replacement cost, strategic leverage, and competing alternatives. + +## 3. Separate the framework into five components + +### A. Target Revenue Source License + +This is the public copyright and patent license attached to the source code. It should define: + +* permitted noncommercial uses; +* evaluation and testing rights; +* modification and redistribution rights; +* prohibited commercial use without a commercial entitlement; +* treatment of derivative works; +* the automatic future-license grant; +* termination and cure; +* warranty and liability exclusions; +* patent and trademark treatment. + +PolyForm Noncommercial offers a useful reference structure for defining personal, research, educational and noncommercial organizational uses, but it contains no automatic Open Source conversion. ([PolyForm Project][3]) + +### B. Commercial Use Agreement + +Commercial users should not purchase rights by interpreting a complicated fee formula embedded in the source license. They should enter into a separate commercial agreement covering: + +* license fees; +* workload and usage fees; +* metering and reporting; +* payment terms; +* support and service levels; +* data processing; +* audit rights; +* affiliates and contractors; +* liability and indemnification; +* allocation of payments to Target Revenue phases. + +This separation allows the public source license to remain stable while pricing models evolve. + +### C. Phase and Milestone Manifest + +Each development phase needs an immutable, machine-readable manifest. For example: + +```yaml +phase_id: config-atlas-phase-003 +milestone: dependency-graph-release +phase_start: 2026-08-01 +milestone_definition: milestone.md +included_commits: + from: abc123 + through: def456 +release_artifact_sha256: "..." +estimated_effort_days: 1 +daily_rate_usd: 1000 +approved_direct_costs_usd: 0 +target_multiple: 100 +target_revenue_usd: 100000 +future_license: MIT +longstop_date: 2030-08-01 +revenue_policy: revenue-policy-v1 +``` + +The manifest prevents the licensor from moving the milestone, changing the multiplier or increasing the target after commercial users have started contributing. + +Reductions of the target could be permitted. Increases should normally require a new phase. + +### D. Target Revenue Ledger + +A public aggregate ledger should show: + +* Target Revenue; +* cumulative eligible revenue; +* remaining target; +* last reconciliation date; +* currency conversion method; +* corrections, refunds and chargebacks; +* signed attestations; +* conversion status. + +Customer identities and commercially confidential data need not be public. The public needs enough information to verify progress, not a customer list. + +### E. Conversion Attestation + +When the trigger occurs, a signed attestation should be issued, a permanent release tag created and the relevant license metadata changed to MIT. + +Crucially, the attestation should be **evidence of the conversion, not the legal cause of conversion**. Otherwise, the licensor could delay the transition by simply declining to publish the declaration. + +The legal mechanism should instead resemble: + +> The Future License grant takes effect automatically, without further declaration or action by the Licensor, upon occurrence of the Conversion Event. + +## 4. Define the Conversion Event carefully + +I strongly recommend: + +[ +\text{Conversion Event} +======================= + +\text{earlier of} +\begin{cases} +\text{Target Revenue Achievement Date}\ +\text{Longstop Date} +\end{cases} +] + +Business Source License 1.1 already uses an automatic per-version conversion mechanism, based on a Change Date or a maximum four-year period. It also makes clear that the restricted license is not itself Open Source. ([MariaDB][4]) + +FSL similarly applies its two-year conversion independently to each software version. ([FSL][5]) + +A pure revenue trigger without a longstop creates several problems: + +* an unsuccessful project might remain restricted forever; +* users cannot know whether Open Source conversion will ever occur; +* insolvency or abandonment could strand the software; +* an unrealistically high multiple could function as permanent proprietary licensing. + +A longstop does not have to be short. It could be phase-dependent. But a credible outside date materially strengthens the social bargain. + +## 5. “Revenue” must be defined more precisely + +The greatest source of future disputes will probably be the meaning of “Target Revenue captured.” + +I would introduce a defined metric called **Revenue Credit**: + +[ +\text{Revenue Credit} +===================== + +\text{Collected License Fees} ++ +\text{Eligible Workload Margin} ++ +\text{Allocated Sponsorship} +---------------------------- + +## \text{Refunds} + +## \text{Chargebacks} + +\text{Indirect Taxes} +] + +The conversion occurs when cumulative Revenue Credit reaches the Target Revenue. + +### License fees + +Normally, 100% of settled software license fees should count. + +### Workload fees + +Counting gross workload fees can distort the mechanism. Suppose a customer pays $100 for LLM or cloud workload that costs you $90. Counting the full $100 toward development recovery would unlock the software even though only $10 was available to fund development. + +A more economically meaningful rule would count either: + +* the actual contribution margin; or +* a predefined percentage of workload revenue. + +### Services and consulting + +Implementation, customization, support and consulting should be included only when explicitly designated. Otherwise a large unrelated consulting engagement might accidentally convert the software. + +### Payment timing + +Revenue should count when received and sufficiently settled, not merely when invoiced. + +The policy must also define: + +* VAT and sales taxes; +* payment-processing fees; +* refunds and credits; +* foreign-exchange rates; +* bad debt; +* bundled products; +* related-party transactions; +* customer prepayments; +* overpayments beyond the target. + +## 6. Software fees and service fees diverge after conversion + +Releasing the milestone under MIT should end the commercial restriction on the software. It does **not** mean that hosted operation, support, compute or managed services become free. + +After conversion: + +* anyone may self-host, modify and commercially use the MIT release; +* you may continue selling the hosted product; +* workload fees may continue; +* support and operational guarantees may continue; +* subsequent improvements may enter a new Target Revenue phase. + +MIT permits use, modification, redistribution, sublicensing and selling copies, subject primarily to preservation of the license and copyright notice. ([Open Source Initiative][6]) + +This distinction is central: **the software becomes free; the operational capability does not become costless.** + +## 7. Successive phases should work like geological layers + +Assume release M1 reaches its target and becomes MIT. + +Development can then proceed as follows: + +```text +M1 — MIT + | + +-- Phase 2 restricted development + | + +-- M2 — Target Revenue Source License +``` + +M1 remains permissively available permanently. M2 may contain M1 plus new modifications under a new phase arrangement, but users must always remain able to obtain and use the earlier M1 release under MIT. + +Each phase should therefore define: + +* the exact base release; +* the included change set; +* the milestone acceptance criteria; +* the Target Multiple; +* the Target Revenue; +* the conversion event; +* the future license. + +Repository tags and release artifacts should be immutable. A moving `main` branch is not a sufficient legal identification of the licensed work. + +## 8. Contributor rights must anticipate conversion + +You can only promise a future MIT release if you hold the necessary rights to all included contributions. + +The contribution model should therefore require either: + +* copyright assignment; +* a contributor license agreement granting the project broad relicensing rights; or +* an inbound contribution grant that expressly covers both the Target Revenue phase and the automatic future license. + +A simple Developer Certificate of Origin may establish provenance but will not necessarily give the central licensor all rights needed for alternative commercial licensing. + +The project should also distinguish third-party dependencies from its own licensed work. A custom license can initially be represented using an SPDX `LicenseRef-...` identifier, provided the corresponding license text is made available. ([SPDX][7]) + +## 9. MIT versus Apache 2.0 + +MIT is a reasonable Future License when maximum simplicity and compatibility are the priority. + +For a commercially developed platform with outside contributors, Apache 2.0 may be safer because it contains an express contributor patent grant and patent-litigation termination mechanism. ([Apache Software Foundation][8]) + +MIT does not contain an explicit patent clause, and the extent of any implied patent grant remains legally debated. ([Open Source Initiative][9]) + +A practical license family could therefore provide two profiles: + +* `TRSL-1.0-MIT` +* `TRSL-1.0-ALv2` + +The restricted phase itself should also include an express patent license for permitted uses. + +## 10. German legal considerations + +The general structure is compatible in principle with German copyright law because §31 UrhG permits rights of use to be granted with temporal, territorial and substantive limitations. ([Gesetze im Internet][10]) + +The dangerous area is ambiguity. Where the license is used as pre-formulated standard terms, §307 BGB requires provisions to be clear and understandable. Terms such as “commercial,” “captured,” “workload,” “improvement,” “release” and “Target Revenue” therefore need objective definitions. ([Gesetze im Internet][11]) + +The company must also secure an appropriate chain of title from employees, contractors and contributors. German author-remuneration rules, including §32 UrhG, should be considered in contributor and contractor arrangements. ([Gesetze im Internet][12]) + +A specialist software-licensing lawyer should review the final text, especially the automatic conversion mechanism, AGB treatment, audit provisions, patent language and cross-border enforcement. + +## Recommended conceptual formulation + +> **Target Revenue Source Licensing** is a phased software monetization model under which an identified body of software is made publicly available for permitted noncommercial use while commercial use requires payment. Each development phase defines an immutable milestone, estimated development cost, Target Multiple and Target Revenue. Commercial Revenue Credits are transparently accumulated against that target. Upon the earlier of achievement of the Target Revenue or a defined Longstop Date, the milestone release automatically and irrevocably becomes available under the specified permissive Open Source license. Subsequent improvements may establish new, independently governed Target Revenue phases without restricting rights previously granted for earlier releases. + +The strongest version of the idea is therefore not simply “commercial until enough money was earned.” It is a transparent **temporary exclusivity contract between the producer, early commercial beneficiaries and the future commons**. + +The next sensible artifact is a `TargetRevenueLicenseConcept.md` defining the terminology, phase lifecycle, revenue-credit rules, multiplier governance, conversion mechanism and separation between the public license and commercial agreements. + +[1]: https://opensource.org/osd?utm_source=chatgpt.com "The Open Source Definition" +[2]: https://fair.io/about/ "About Fair Source | Fair.io" +[3]: https://polyformproject.org/licenses/noncommercial/1.0.0 "NonCommercial 1.0.0" +[4]: https://mariadb.com/bsl11/ "Business Source License 1.1 | MariaDB" +[5]: https://fsl.software/ "FSL - Functional Source License" +[6]: https://opensource.org/license/mit?utm_source=chatgpt.com "The MIT License" +[7]: https://spdx.github.io/spdx-spec/v2.3/using-SPDX-short-identifiers-in-source-files/?utm_source=chatgpt.com "Annex E: Using SPDX short identifiers in Source Files" +[8]: https://www.apache.org/licenses/LICENSE-2.0?utm_source=chatgpt.com "Apache License, Version 2.0" +[9]: https://opensource.org/blog/patents-and-open-source-understanding-the-risks-and-available-solutions-2?utm_source=chatgpt.com "Patents and Open Source: Understanding the Risks ..." +[10]: https://www.gesetze-im-internet.de/urhg/__31.html?utm_source=chatgpt.com "§ 31 UrhG - Einzelnorm" +[11]: https://www.gesetze-im-internet.de/bgb/__307.html?utm_source=chatgpt.com "§ 307 BGB - Einzelnorm" +[12]: https://www.gesetze-im-internet.de/urhg/__32.html?utm_source=chatgpt.com "§ 32 UrhG - Einzelnorm" + +## Prompt 2 - Separation of Dev & Ops Monetization + +Good characterization and sensible ideas to cover some boundries. I think the longstop should get some attention and i would like the target to degenerate over time if there is no substantial progress towards the target revenue. Before designing those details we need to adress that the license framework in my opinion should differenciate development monetization (by some form of license) and operations monetization (by some cost+ pricing like hosting&operations cost with 50% surcharge). This is necessary to define the revenue and minimize disputes about "Target Revenue Captured". Refinements could and maybe should be ideation monetization, service monetization, consulting monetization, sponsoring monetization. My basic premise is the TRSL should provide a solid canonical monetization framework but allow for monetization extensions so that creative ideas to monetize can find their home in the framework and provide for optimization of the monetization canon over time. + +Yes. This separation is foundational. Otherwise TRSL risks confusing several economically distinct transactions: + +* payment for the right to use newly developed software commercially; +* payment for compute, hosting and operational responsibility; +* payment for human work; +* payment to influence what gets developed; +* payment made primarily to support the project. + +Only some of these should satisfy the development Target Revenue. + +## 1. TRSL should be one component of a larger framework + +I would now distinguish: + +### Target Revenue Monetization Framework + +The umbrella framework defining: + +* monetization categories; +* cost and pricing models; +* revenue allocation; +* phase accounting; +* target degeneration; +* evidence and auditing; +* extension mechanisms; +* conversion into the Future License. + +### Target Revenue Source License + +The legal instrument governing: + +* noncommercial source availability; +* commercial-use restrictions; +* commercial-use entitlements; +* the software covered by a phase; +* automatic conversion to MIT or another Future License. + +This produces a cleaner structure: + +```text +Target Revenue Monetization Framework +│ +├── Target Revenue Source License +├── Commercial Use Agreement +├── Phase Manifest +├── Monetization Type Registry +├── Revenue Allocation Policy +├── Target Ledger +├── Target Degeneration Policy +└── Conversion Protocol +``` + +The license should not attempt to encode hosting prices, consulting rates or every future monetization idea. It should refer to the phase and conversion mechanism defined by the framework. + +## 2. The central distinction: revenue versus Target Credit + +The framework should not ask: + +> How much revenue has the project earned? + +It should ask: + +> How much value has been validly credited toward satisfying this development target? + +I would therefore introduce **Development Revenue Credit**. + +A payment may create several allocations: + +```text +Customer payment +│ +├── taxes and transaction costs +├── operational cost recovery +├── operations surcharge +├── service compensation +├── development revenue credit +└── other explicitly defined allocations +``` + +Only the amount allocated as Development Revenue Credit contributes toward unlocking the milestone release. + +That gives us: + +[ +\text{Outstanding Development Target} +===================================== + +## \text{Initial Development Target} + +## \text{Development Revenue Credits} + +\text{Target Remission Credits} +] + +The milestone converts when the outstanding amount reaches zero. + +This is substantially clearer than defining all project income as “Target Revenue Captured.” + +## 3. Canonical monetization classes + +The framework could begin with six canonical classes. + +| Monetization class | Value being sold | Default Target Credit | +| ------------------ | ------------------------------------------------------------------- | --------------------: | +| Development | Commercial access to protected development | 100% | +| Operations | Hosting, compute and operational responsibility | 0% | +| Ideation | Discovery, prioritization and product conception | Configurable | +| Service | Implementation, integration, support or training | 0% | +| Consulting | Advice, analysis and customer-specific expertise | 0% | +| Sponsoring | Financial support or influence without ordinary usage consideration | Configurable | + +The important principle is: + +> A monetization class describes what the customer is paying for. A separate allocation rule determines whether and to what extent the payment satisfies a development target. + +This allows new monetization models to be added without corrupting the core accounting model. + +## 4. Development monetization + +Development monetization is the canonical mechanism for satisfying the Target Revenue. + +The payer receives something related to the temporarily protected development, such as: + +* commercial-use rights; +* early commercial access; +* access to milestone builds; +* access to protected features; +* enterprise distribution rights; +* phase-specific commercial entitlements. + +The basic rule could be: + +[ +\text{Development Revenue Credit} +================================= + +## \text{Collected Development Fee} + +## \text{Taxes} + +## \text{Refunds} + +\text{Chargebacks} +] + +Payment-processing fees could either be excluded or treated as a cost of the licensor. The framework should choose one canonical treatment. + +Development monetization should normally be credited entirely to exactly one phase. A payment may be split between phases, but the split must be declared when the transaction is created. + +### Conservation of credit + +A useful canonical rule would be: + +> One monetary unit may create no more than one monetary unit of Development Revenue Credit. + +The same payment must not count toward two phases, both as license revenue and sponsorship, or through any other duplicate classification. + +## 5. Operations monetization + +Operations monetization should be explicitly independent of the software licensing state. + +It covers things such as: + +* compute; +* storage; +* network traffic; +* external APIs; +* monitoring; +* backups; +* security operations; +* availability management; +* deployment maintenance; +* incident handling; +* operational labor; +* capacity and operational risk. + +Your proposed default pricing rule can be expressed as: + +[ +\text{Operations Price} +======================= + +\text{Eligible Operations Cost} +\times 1.50 +] + +For example: + +```text +Compute and infrastructure cost: $70 +Allocated operational labor: $20 +Monitoring and external services: $10 + ---- +Eligible Operations Cost: $100 +Operations surcharge, 50%: $50 + ---- +Customer Operations Price: $150 +``` + +Under the canonical default: + +```text +Operations revenue: $150 +Development Revenue Credit: $0 +``` + +This remains true before and after MIT conversion. The customer is paying for an operated capability, not merely permission to use the software. + +### Optional development allocation + +A particular offer could explicitly allocate part of the operations surcharge toward the development target: + +```text +Eligible Operations Cost: $100 +Operations surcharge: $50 +Development allocation: 40% +Development Revenue Credit: $20 +Retained operations contribution: $30 +``` + +Only the declared $20 counts toward the target—not the full $150 and not even the full $50 surcharge. + +This enables statements such as: + +> Twenty percent of the hosted-service price contributes to releasing this version under MIT. + +But the framework default should remain zero allocation. Otherwise every disagreement over hosting costs becomes a disagreement over license conversion. + +## 6. Ideation monetization + +Ideation is economically distinct from implementation. It may include: + +* problem exploration; +* opportunity research; +* feature conception; +* requirements development; +* architecture exploration; +* prototype proposals; +* voting or prioritization rights; +* access to design workshops; +* commissioned product hypotheses. + +Ideation monetization can relate to a future phase without necessarily guaranteeing implementation. + +Possible instruments include: + +* paid feature proposals; +* discovery subscriptions; +* prioritization credits; +* design patronage; +* commissioned feasibility studies; +* markets or auctions for development attention. + +The framework should distinguish at least two cases. + +### Customer-specific ideation + +The result primarily belongs to the customer or addresses its individual situation. This should normally not count toward a public development target. + +### Product-directed ideation + +The result contributes directly to defining a public phase or milestone. A declared portion may count toward that phase. + +For example: + +```text +Paid product discovery: $10,000 +Customer-specific analysis: $4,000 +Reusable milestone definition: $6,000 + +Development Revenue Credit: $6,000 +``` + +This supports the broader product lifecycle logic of adaptive pricing: monetization can begin at the inception of an idea, rather than only after implementation. + +## 7. Service monetization + +Service monetization covers repeatable or customer-specific human work such as: + +* installation; +* migration; +* configuration; +* integration; +* customization; +* support; +* training; +* certification; +* managed onboarding. + +The canonical default should be zero Target Credit because the customer receives the service itself. + +However, a service engagement may produce reusable development that enters the governed milestone. That reusable portion can be explicitly reclassified or allocated as development monetization. + +For example: + +```text +Integration engagement: $20,000 + +Customer-specific configuration: $12,000 +Reusable connector development: $8,000 + +Service revenue: $12,000 +Development Revenue Credit: $8,000 +``` + +The reusable connector must then actually become part of the defined milestone. Merely calling consulting work “product development” must not be enough. + +## 8. Consulting monetization + +Consulting monetizes knowledge and judgment: + +* strategic advice; +* architecture assessment; +* organizational analysis; +* security review; +* product strategy; +* implementation planning; +* operational improvement. + +Its default Target Credit should be zero. + +Consulting may generate product ideas, specifications or reusable artifacts, but those should only count when: + +1. the reusable deliverable is identified; +2. the relevant phase is identified; +3. the allocation is agreed; +4. the deliverable becomes part of the phase evidence. + +Keeping consulting separate is particularly important for your intended ecosystem company. The company may sell advisory services around ConfigAtlas, NetKingdom, Coulomb or other products without accidentally causing software releases to convert. + +## 9. Sponsoring monetization + +Sponsoring needs subcategories because the intention behind sponsorship varies considerably. + +### Phase sponsorship + +Funding is explicitly directed at a particular milestone. The eligible amount should normally count toward that phase. + +### Feature sponsorship + +Funding requests a particular feature. Credit depends on whether the feature is accepted into the phase manifest. + +### General project sponsorship + +Funding supports the project broadly. It should not count until allocated to a phase. + +### Infrastructure sponsorship + +Funding pays hosting, events, documentation or community infrastructure. It should normally not count toward a development target. + +### Promotional sponsorship + +The sponsor receives visibility, naming rights or marketing consideration. This should normally be treated independently unless part of the payment is explicitly allocated to development. + +This prevents an unrestricted donation from being silently assigned to whichever phase the licensor prefers. + +## 10. Monetization extensions + +The framework should provide an extension mechanism rather than trying to anticipate every business model. + +Possible future extensions could include: + +* marketplace monetization; +* transaction fees; +* certification fees; +* data products; +* model inference; +* outcome-based pricing; +* savings participation; +* revenue sharing; +* insurance-like guarantees; +* priority-response rights; +* development auctions; +* community memberships; +* capability subscriptions; +* security-tier surcharges; +* agent workload pricing. + +Every extension should implement the same minimal contract. + +### Monetization extension contract + +A monetization type should define: + +1. **Value object** + What is being sold? + +2. **Entitlement** + What does the payer receive? + +3. **Pricing basis** + How is the price calculated? + +4. **Cost basis** + Which costs are attributable to the transaction? + +5. **Target allocation** + What portion may become Development Revenue Credit? + +6. **Phase association** + To which phase or phases may the credit apply? + +7. **Recognition event** + When does the amount become eligible—order, invoice, settlement or delivery? + +8. **Reversal policy** + How are refunds, credits and chargebacks handled? + +9. **Evidence requirements** + What records prove the allocation? + +10. **Public disclosure** + Which aggregate information appears in the Target Ledger? + +A simple representation might look like: + +```yaml +monetization_type: hosted-operation +extension_version: "1.0" + +value_object: + type: operated-capability + description: Hosted and monitored operation of the software + +pricing: + method: cost-plus + surcharge_rate: 0.50 + +target_allocation: + default_rate: 0 + allocation_base: surcharge + maximum_rate: 1.0 + phase_required: true + +recognition: + event: payment-settled + +reversals: + refunds: reverse-proportionally + chargebacks: reverse-fully +``` + +The extension adds a monetization mechanism without changing the license terms. + +## 11. The target should remain historically immutable + +Your idea that the target degenerates over time is sensible, especially where the market does not validate the original commercial hypothesis. + +However, I would not literally rewrite the original Target Revenue. The initial target is an important historical statement: + +```text +Estimated development cost: $1,000 +Target Multiple: 100x +Initial Development Target: $100,000 +``` + +Changing it later to $70,000 would obscure the original hypothesis and complicate auditability. + +Instead, model degeneration as **Target Remission Credit**: + +```text +Initial Development Target: $100,000 +Development Revenue Credits: $35,000 +Time-based Target Remission: $20,000 +Outstanding Development Target: $45,000 +``` + +Thus: + +[ +\text{Outstanding Target}(t) +============================ + +\max\left( +0, +T_0 +--- + +## R(t) + +D(t) +\right) +] + +where: + +* (T_0) is the immutable initial target; +* (R(t)) is cumulative Development Revenue Credit; +* (D(t)) is cumulative degeneration or remission credit. + +This also corrects the conversion terminology. The software may convert either because: + +* enough Development Revenue was captured; or +* the remaining commercial protection was remitted over time; or +* both mechanisms together satisfied the target. + +The overarching event should therefore be called the **Target Satisfaction Event**, rather than the Target Revenue Achievement Event. + +## 12. Progress-sensitive degeneration + +The eventual degeneration mechanism can assess progress strictly within the development pool. + +Operations revenue should not suspend degeneration merely because the hosted service is expensive or successful. Otherwise a profitable operations business could keep a release restricted indefinitely without making progress toward its declared development target. + +The relevant progress indicators could include: + +* Development Revenue Credit during a measurement period; +* percentage of the initial target satisfied; +* rate of target satisfaction; +* number or diversity of paying commercial users; +* elapsed time since the last material development payment; +* phase activity and maintenance status. + +This creates an important conceptual distinction: + +> Operations success demonstrates demand for the operated capability. Development Revenue progress demonstrates market validation of the protected improvement. + +The two may be correlated, but they are not identical. + +## 13. Proposed canonical axioms + +The framework could be grounded in the following principles. + +### Purpose-bound revenue + +Every payment must be classified according to the value received by the payer. + +### Explicit target allocation + +No payment contributes to a development target unless an allocation rule says that it does. + +### Immutable initial target + +The original cost basis, Target Multiple and Initial Development Target remain historically visible. + +### Transparent remission + +Time-based degeneration is recorded as remission, not misrepresented as earned revenue. + +### Separation of software and operations + +Permissive release of the software does not eliminate the price of operating it. + +### No duplicate credit + +The same economic value cannot be credited more than once. + +### Settled-value recognition + +Credits normally arise from collected and settled payments, not invoices or promises. + +### Phase specificity + +Every Development Revenue Credit must be associated with a defined phase. + +### Permanent prior freedoms + +A new phase may create new restrictions but may never withdraw freedoms already granted for an earlier release. + +### Extensible monetization + +New monetization mechanisms may be registered without rewriting the core license. + +## 14. Refined conceptual model + +The resulting framework can be summarized as: + +> The Target Revenue Monetization Framework provides a canonical and extensible system for monetizing product exploration, software development, operation, services, consulting, sponsorship and other value-producing activities. Each payment is classified by the value supplied and allocated between defined economic purposes. Only explicitly recognized Development Revenue Credits contribute toward satisfying the immutable Initial Development Target of a governed software phase. Independently recorded Target Remission Credits may reduce the outstanding target over time when commercial validation does not progress sufficiently. Once the combination of Development Revenue Credits and Target Remission Credits satisfies the target, the milestone release automatically converts to its defined permissive Future License. Operations and other services may continue to be monetized independently after conversion. + +This turns TRSL from a special-purpose license into the rights-management component of a broader **product monetization canon**. Its most important architectural element is not the license restriction itself, but the explicit allocation boundary between what funds development, what pays for operations, and what purchases other forms of value. + +## Prompt 3 - Terminology and Extensibility + +This is well put. The challenge is to provide a minimal core of terminology and rules to keep the concept easy to understand and use while at the same time providing enough rules and guidance to allow for extensibility that provides flexibility without driving complexity. + +I agree. The framework needs a **small constitutional core**, not a complete taxonomy of every possible business model. + +The simplest mental model could be: + +> **Define a development target, credit qualifying payments against it, remit part of it over time, and convert the release when the target is satisfied. Everything else is a monetization profile.** + +That gives TRSL a stable center while allowing experimentation around it. + +## 1. Separate the kernel from the catalog + +The framework should have three layers: + +```text +TRSL Core + ↓ +Canonical Monetization Profiles + ↓ +Project-Specific Extensions +``` + +### TRSL Core + +Mandatory and stable. It defines only: + +* what software phase is governed; +* what target must be satisfied; +* what counts toward the target; +* how the target may degenerate; +* when conversion occurs; +* which future license applies. + +### Canonical profiles + +Recommended standard mechanisms: + +* development licensing; +* hosted operations; +* services; +* consulting; +* sponsorship; +* ideation. + +These profiles make common use cases easy, but they do not change the core. + +### Extensions + +Project-specific or experimental monetization mechanisms: + +* auctions; +* outcome-based pricing; +* memberships; +* marketplace fees; +* transaction participation; +* shared savings; +* data products; +* certification; +* priority access. + +Extensions must conform to the core accounting rules. + +## 2. The five core verbs + +The entire framework can be explained through five actions: + +### Define + +Define a phase, milestone release, initial target and future license. + +### Allocate + +Allocate each payment according to what the payer receives. + +### Credit + +Credit the eligible development allocation toward the target. + +### Remit + +Reduce the unsatisfied target according to a published degeneration rule. + +### Convert + +Automatically release the milestone under the future license when the target is satisfied. + +This provides a compact lifecycle: + +```text +Define → Allocate → Credit or Remit → Convert +``` + +Every more detailed mechanism should fit somewhere within these verbs. + +## 3. Minimal core terminology + +I would limit the normative vocabulary to seven concepts. + +### Phase + +A bounded period of product development governed by one target. + +### Milestone Release + +The precisely identified software release that will convert to the Future License. + +### Initial Target + +The immutable monetary amount associated with the phase. + +[ +T_0 = \text{Estimated Development Cost} \times \text{Target Multiple} +] + +### Development Credit + +The portion of collected payments explicitly allocated toward satisfying the Initial Target. + +### Remission Credit + +A transparent, non-revenue reduction of the target under the degeneration policy. + +### Outstanding Target + +The remaining amount required for conversion. + +[ +T_{\text{outstanding}} +====================== + +\max(0,T_0-C-R) +] + +where: + +* (T_0) = Initial Target; +* (C) = cumulative Development Credit; +* (R) = cumulative Remission Credit. + +### Conversion Event + +The moment the Outstanding Target reaches zero and the Milestone Release automatically becomes available under the Future License. + +This vocabulary is enough to describe the fundamental mechanism. + +## 4. Only two economic distinctions belong in the core + +The core does not need to understand consulting, ideation, hosting, sponsorship or marketplace revenue individually. + +It only needs to distinguish: + +### Target-relevant allocation + +The portion of a payment that becomes Development Credit. + +### Non-target allocation + +Everything else. + +This gives every transaction a simple accounting envelope: + +```yaml +payment: + collected_amount: 1500 + development_allocation: 500 + non_target_allocation: 1000 +``` + +The framework does not need to know why the remaining $1,000 is non-target revenue. A profile may describe it as operations, support, consulting or something else. + +For transparency, the transaction can carry a monetization label: + +```yaml +monetization_type: hosted-operations +``` + +But the label does not control the target. The explicit allocation does. + +That is an important simplification: + +> **Monetization categories explain the business transaction. Allocation determines the legal conversion effect.** + +## 5. Operations should be the first canonical profile + +Although operations does not need to be a core accounting concept, it should be a first-class standard profile because its separation from development is fundamental to understanding the framework. + +The canonical operations profile could state: + +[ +\text{Operations Price} +======================= + +\text{Eligible Operations Cost} +\times +(1+\text{Operations Surcharge}) +] + +Default: + +```yaml +operations_profile: + pricing_method: cost-plus + default_surcharge: 0.50 + default_development_allocation: 0 +``` + +For example: + +```text +Infrastructure and operational cost $100 +Operations surcharge $50 +Customer price $150 + +Development Credit $0 +``` + +A project could deliberately allocate some of the surcharge to development: + +```text +Operations cost $100 +Operations surcharge $50 +Development allocation $10 + +Development Credit $10 +Non-target allocation $140 +``` + +But that exception must be explicit. + +## 6. Canonical profiles should be guidance, not ontology + +The framework should resist building an elaborate classification tree. + +A small initial catalog is sufficient: + +| Profile | Default Development Credit | +| ------------------- | -------------------------: | +| Development license | 100% | +| Operations | 0% | +| Service | 0% | +| Consulting | 0% | +| Ideation | 0% or declared allocation | +| Sponsorship | Declared allocation | + +These defaults answer the common cases without preventing alternatives. + +For example, reusable work from a service engagement may receive an explicit development allocation. A sponsorship may be fully allocated to a phase. A product workshop may be partially allocated if it directly produces the milestone definition. + +The profile provides the presumption. The transaction allocation provides the actual answer. + +## 7. Seven core rules + +The normative core could be limited to seven rules. + +### 1. Immutable definition + +The Phase, Milestone Release, Initial Target, Target Multiple and Future License must be published before Development Credits are accepted. + +They may be corrected for manifest error, but not silently changed for commercial convenience. + +### 2. Explicit allocation + +No payment creates Development Credit unless its development allocation is explicitly defined. + +### 3. No duplicate credit + +The same monetary value may not be credited more than once, whether against one phase or several phases. + +### 4. Settled-payment recognition + +Development Credit normally arises only when payment has been collected and settled. + +Refunds and chargebacks reverse the associated credit. + +### 5. Separate remission + +Target degeneration must be recorded as Remission Credit, never as revenue or Development Credit. + +### 6. Automatic conversion + +When the Outstanding Target reaches zero, conversion occurs automatically and irrevocably without requiring further discretionary action by the licensor. + +### 7. Permanent prior freedom + +Conversion rights already granted to an earlier Milestone Release cannot be withdrawn or restricted by a later phase. + +These rules create the necessary trust boundary without regulating every commercial detail. + +## 8. A constrained extension contract + +Extensions should be easy to create, but their powers should be limited. + +Each extension should answer only six questions: + +```yaml +extension: + name: outcome-based-pricing + version: "1.0" + + value: + description: What does the customer receive? + + pricing: + method: How is the payment calculated? + + allocation: + rule: What portion becomes Development Credit? + + recognition: + event: When is the allocation recognized? + + reversal: + rule: How are refunds or corrections handled? + + evidence: + requirement: What proves the transaction and allocation? +``` + +An extension may define pricing and allocation logic. + +It must not redefine: + +* Phase; +* Initial Target; +* Development Credit; +* Remission Credit; +* Outstanding Target; +* Conversion Event; +* Future License. + +That is the constitutional boundary between flexibility and complexity. + +## 9. Use profiles rather than license variants + +Ideally, there should not be separate licenses such as: + +* TRSL Hosting Edition; +* TRSL Sponsorship Edition; +* TRSL Consulting Edition; +* TRSL Marketplace Edition. + +That would fragment understanding and compatibility. + +Instead: + +```text +One TRSL legal core ++ +One phase manifest ++ +Zero or more monetization profiles +``` + +The license governs rights. Profiles govern commercial offers. + +A project might therefore publish: + +```yaml +license: TRSL-1.0 + +phase: + id: phase-003 + target: 100000 + future_license: MIT + +profiles: + - development-license-v1 + - cost-plus-operations-v1 + - phase-sponsorship-v1 +``` + +A different project could use the same license with different profiles. + +## 10. Keep the phase manifest minimal + +A mandatory phase declaration may require only: + +```yaml +phase: phase-003 +milestone_release: release-3.0 +initial_target: 100000 +currency: USD +future_license: MIT +degeneration_policy: standard-degeneration-v1 +ledger: https://example.invalid/phases/phase-003 +``` + +Optional metadata can include: + +* estimated effort; +* daily rate; +* Target Multiple; +* value hypothesis; +* acceptance criteria; +* supported monetization profiles; +* audit arrangements. + +The framework should distinguish: + +* **required for legal determinacy**; +* **recommended for transparency**; +* **optional for business analysis**. + +Not every good practice must become a license condition. + +## 11. Apply a complexity budget + +A useful governance principle would be: + +> A new rule enters the core only when interoperability or trust cannot be achieved without it. + +Otherwise, it belongs in: + +1. a canonical profile; +2. implementation guidance; +3. an optional extension; +4. a project policy. + +A proposed addition to the core should pass three tests: + +### Universal + +Does nearly every TRSL phase need it? + +### Interoperable + +Would differing implementations create incompatible interpretations? + +### Trust-critical + +Could omitting it allow manipulation of the conversion bargain? + +If the answer is not substantially yes to all three, it should remain outside the core. + +## 12. The resulting minimal architecture + +```text +TRSL Core +│ +├── Seven terms +│ ├── Phase +│ ├── Milestone Release +│ ├── Initial Target +│ ├── Development Credit +│ ├── Remission Credit +│ ├── Outstanding Target +│ └── Conversion Event +│ +├── Seven rules +│ ├── Immutable definition +│ ├── Explicit allocation +│ ├── No duplicate credit +│ ├── Settled-payment recognition +│ ├── Separate remission +│ ├── Automatic conversion +│ └── Permanent prior freedom +│ +├── Phase Manifest +├── Target Ledger +│ +└── Extension Interface + ├── Value + ├── Pricing + ├── Allocation + ├── Recognition + ├── Reversal + └── Evidence +``` + +Everything else becomes a profile, policy or implementation choice. + +## Core formulation + +> The Target Revenue Source License governs a defined software Phase leading to a Milestone Release. The Phase declares an immutable Initial Target and a permissive Future License. Collected payments contribute to the target only through explicitly declared Development Credits. A published degeneration policy may additionally create Remission Credits. The remaining Outstanding Target equals the Initial Target minus cumulative Development Credits and Remission Credits. When the Outstanding Target reaches zero, the Milestone Release automatically and irrevocably converts to the Future License. Monetization profiles and extensions may define how value is offered, priced and allocated, but may not alter the meaning of the core terms or the conversion mechanism. + +This is probably close to the appropriate conceptual minimum: **one target, two kinds of credit, one conversion event, and a constrained extension interface.** + +# Prompt 4 - Central Service and Federation + +Good, i like that and my hunch is, that we need the License and a Trustservice for the publication of extenstions and metrics to make this work. The Trustservice will be centralized as that helps to evolve it to the point where the framework actually works. Later on i would like to pivot into a federated Trustservice architecture as i think that will help robustness, adoption and distribution. + +Yes. The natural architecture is: + +```text +TRSL License +defines the rights and automatic conversion mechanism + + + + +TRSL Trust Service +publishes authoritative phase records, extensions, +credits, remission, metrics, and conversion evidence +``` + +The license creates the legal effect. The Trust Service creates the **shared factual basis** needed to determine when that effect occurs. + +The essential design principle should be: + +> **The Trust Service observes, records, calculates and attests. It does not have discretion over whether a conversion occurs.** + +## 1. Why the Trust Service is necessary + +Without a trusted service, every TRSL project would need to establish its own answers to questions such as: + +* Which phase declaration is authoritative? +* Was the Initial Target changed? +* Which monetization extensions apply? +* Which payments created Development Credit? +* How much Remission Credit has accumulated? +* Has the Outstanding Target reached zero? +* Which release converted, and when? +* Can historical records still be inspected? + +The license text alone cannot answer these operational questions. Embedding all of them into the license would make it too complicated. + +The Trust Service therefore allows the legal core to remain small: + +[ +\text{Outstanding Target} +========================= + +## \text{Initial Target} + +## \text{Development Credit} + +\text{Remission Credit} +] + +while the service maintains the evidence behind each term. + +## 2. The minimal responsibility boundary + +The Trust Service should initially have five core responsibilities. + +### Phase Registry + +It publishes immutable or versioned records for: + +* the governed Phase; +* the Milestone Release; +* the Initial Target; +* the Future License; +* the degeneration policy; +* the responsible licensor; +* the applicable monetization profiles and extensions. + +### Extension Registry + +It publishes canonical and project-specific monetization extensions, including: + +* extension identifier; +* version; +* pricing and allocation rules; +* recognition and reversal rules; +* evidence requirements; +* compatibility with the current TRSL core. + +### Target Ledger + +It records aggregate movements affecting the target: + +```text ++ Development Credit ++ Remission Credit +- Credit reversal +- Remission correction += Current Outstanding Target +``` + +### Metrics Service + +It calculates and publishes comprehensible phase metrics such as: + +* Initial Target; +* Development Credit captured; +* Remission Credit accumulated; +* Outstanding Target; +* percentage satisfied; +* current satisfaction velocity; +* time since last material progress; +* projected conversion under the current degeneration policy. + +### Conversion Attestation + +When the Outstanding Target reaches zero, it publishes a signed statement identifying: + +* the phase; +* the milestone release; +* the conversion time; +* the Future License; +* the final ledger state; +* the evidence record supporting conversion. + +Again, the attestation confirms the conversion. It should not cause it. + +## 3. The Trust Service must not become a licensing authority + +A centralized service creates a practical risk: users might understand the software as converted only when the service operator approves it. + +That would undermine the automatic nature of the framework. + +The legal wording should therefore establish something like: + +> The Conversion Event occurs automatically when the published and verifiable Development Credits and Remission Credits equal or exceed the Initial Target. A Trust Service attestation is authoritative evidence of the event but is not a condition for its occurrence. + +This distinction matters if the service: + +* becomes unavailable; +* refuses to issue an attestation; +* is operated by the licensor and has a conflict of interest; +* is acquired; +* becomes insolvent; +* contains an error; +* is replaced by another operator. + +A user should be able to prove conversion from the signed phase record and ledger evidence even if the original service disappears. + +## 4. Centralized first is the correct development strategy + +A centralized first version has substantial benefits: + +* one canonical interpretation of terms; +* one extension review process; +* consistent metrics; +* easier correction of early design mistakes; +* lower integration cost; +* stronger product feedback; +* clearer user experience; +* simpler dispute resolution; +* faster evolution of the framework. + +Federating too early would fossilize immature concepts and create incompatible interpretations. + +The initial service can therefore be deliberately centralized in governance while already being **federation-ready in data architecture**. + +That means: + +```text +Central operation now +Open formats from the beginning +Federated verification later +``` + +## 5. Centralized does not need to mean opaque + +The first Trust Service should already include safeguards that reduce dependence on the operator. + +### Public phase records + +Every material phase declaration should be publicly inspectable and permanently addressable. + +### Signed records + +Phase manifests, extension versions, ledger checkpoints and conversion attestations should be digitally signed. + +### Append-only history + +Changes should create new records rather than overwriting history. + +### Exportability + +A complete phase evidence package should be downloadable in an open format. + +### Deterministic calculations + +Given the same phase manifest and ledger entries, another implementation should calculate the same Outstanding Target. + +### Open schemas + +The record formats and calculation rules should be publicly documented. + +### Stable identifiers + +Phases, extensions, entries and attestations should have globally unique identifiers independent of a particular website URL. + +These properties prepare federation without requiring federation in the first implementation. + +## 6. Separate public metrics from confidential evidence + +Commercial payments can contain sensitive information. The Trust Service should not require all commercial transaction details to become public. + +It can instead maintain three evidence levels. + +### Public record + +Visible to everyone: + +* aggregated Development Credit; +* aggregated Remission Credit; +* outstanding amount; +* dates and ledger entry identifiers; +* applied extension and allocation rule; +* signed checkpoints. + +### Confidential evidence + +Available only to authorized auditors or dispute-resolution bodies: + +* customer contracts; +* invoices; +* payment receipts; +* allocation calculations; +* refunds and chargebacks; +* relevant cost records. + +### Private commercial data + +Retained by the operator and not ordinarily uploaded: + +* customer names; +* user-level consumption; +* unrelated contract provisions; +* operational secrets; +* personal data. + +The public needs to verify the target state without learning every customer relationship. + +## 7. A simple Trust Service data model + +The service can be built around a few record types. + +```text +Project + └── Phase + ├── Phase Manifest + ├── Extension References + ├── Ledger Entries + ├── Metric Checkpoints + └── Conversion Attestation +``` + +A ledger entry might look like: + +```yaml +entry_id: trsl:entry:01K... +phase_id: trsl:phase:config-atlas-003 +entry_type: development-credit +amount: 2500 +currency: EUR +recognized_at: 2026-10-15T09:30:00Z +extension: + id: trsl:extension:development-license + version: "1.0" +evidence_reference: confidential:evidence:... +previous_entry_hash: "..." +signature: "..." +``` + +A remission entry would use the same structure: + +```yaml +entry_type: remission-credit +amount: 500 +policy: + id: trsl:policy:progress-sensitive-decay + version: "1.0" +measurement_period: 2026-Q4 +``` + +This unified ledger model keeps the calculation simple. + +## 8. Extensions need two forms of publication + +It would be useful to distinguish: + +### Registered extensions + +Any conforming extension published through the Trust Service. + +A registered extension must satisfy the extension interface but does not necessarily represent a recommended practice. + +### Canonical extensions + +Extensions reviewed and maintained as part of the standard framework. + +Examples might include: + +* `development-license`; +* `cost-plus-operations`; +* `phase-sponsorship`; +* `service-with-development-allocation`; +* `product-ideation`; +* `general-consulting`. + +This allows innovation without implying that every experimental model is endorsed. + +A project can use: + +```yaml +extensions: + - id: trsl:extension:cost-plus-operations + version: "1.0" + status: canonical + + - id: trsl:extension:shared-savings + version: "0.2" + status: registered +``` + +## 9. Extension publication should not create core complexity + +The Trust Service should validate extensions against a small conformance contract. + +An extension may define: + +* the value sold; +* the pricing method; +* the allocation method; +* the recognition event; +* reversal handling; +* evidence requirements. + +An extension may not redefine: + +* Initial Target; +* Development Credit; +* Remission Credit; +* Outstanding Target; +* Conversion Event; +* Future License. + +The Trust Service can reject an extension as **non-conforming** when it attempts to change those meanings. + +This gives the service a standards role without giving it authority over individual commercial decisions. + +## 10. Metrics should be explanatory, not legally creative + +The Trust Service will probably become valuable partly because it can provide richer analytics. + +For example: + +```text +Initial Target €100,000 +Development Credit €31,000 +Remission Credit €14,000 +Outstanding Target €55,000 +Target satisfaction 45% +Development Credit, last 90 days €2,500 +Current remission rate €1,000/month +``` + +It may also display forecasts: + +```text +Projected conversion from remission only: June 2031 +Projected conversion at current revenue rate: October 2028 +``` + +But a forecast must remain informational. It should not alter the target or the conversion event. + +The service should distinguish clearly between: + +* **ledger facts**; +* **calculated metrics**; +* **forecasts**; +* **recommendations**. + +## 11. The path toward federation + +The later federated model could involve multiple Trust Service operators. + +```text +Project Trust Service + | + +── publishes signed phase records + | +Regional or ecosystem Trust Services + | + +── replicate and verify records + | +Independent auditors and observers + | + +── publish confirmations or challenges + | +Global discovery registry + | + +── locates authoritative and replicated records +``` + +Federation should not initially mean that every service can alter every phase. Instead, each phase would identify one or more authoritative issuers. + +Other services can: + +* replicate records; +* verify signatures; +* independently calculate metrics; +* challenge inconsistencies; +* mirror conversion attestations; +* preserve records if the primary operator disappears. + +## 12. Possible federation maturity stages + +### Stage 0 — Centralized authority + +One service registers phases, extensions, ledger entries and attestations. + +### Stage 1 — Public verification + +Third parties can independently verify exported records and calculations. + +### Stage 2 — Read federation + +Other services mirror and index authoritative records. + +### Stage 3 — Attestation federation + +Independent auditors can countersign ledger checkpoints and conversion events. + +### Stage 4 — Operator federation + +Projects may choose among compatible Trust Service providers. + +### Stage 5 — Multi-authority phases + +A phase may require or accept attestations from several independent operators. + +### Stage 6 — Protocol-governed ecosystem + +No single service owns the framework; governance, discovery and compatibility operate through an open federation. + +This creates a controlled progression from practical centralization to institutional robustness. + +## 13. Disputes and corrections + +A Trust Service also needs a correction model. + +Records should not generally be deleted or silently modified. Corrections should be represented through compensating entries: + +```text +Original Development Credit +€5,000 +Refund reversal -€1,000 +Corrected cumulative effect +€4,000 +``` + +Disputes could have statuses such as: + +* submitted; +* under review; +* provisionally accepted; +* rejected; +* corrected; +* externally arbitrated. + +The service should be able to flag a metric as disputed without retroactively pretending that the disputed entry never existed. + +A particularly important rule will be: + +> Once a valid Conversion Event has occurred, later reversals must not revoke the Future License. + +The permissive grant must be irrevocable. A late refund or accounting correction cannot make already-open software proprietary again. + +## 14. Governance of the centralized service + +Because the initial Trust Service will have considerable influence over the evolution of the framework, its governance should be transparent. + +At minimum it should publish: + +* current TRSL core version; +* extension review criteria; +* change process; +* compatibility policy; +* deprecation policy; +* conflict-of-interest policy; +* dispute procedure; +* operator identity; +* signing keys and key-rotation history; +* service continuity and archival policy. + +The operator can retain decision-making control during the exploratory stage while making the process observable. + +That supports your intention: centralization as a means of learning, not as an attempt to create permanent control. + +## 15. Refined architecture + +```text +TRSL Ecosystem +│ +├── Legal Layer +│ ├── Target Revenue Source License +│ └── Commercial Agreements +│ +├── Declarative Layer +│ ├── Phase Manifest +│ ├── Degeneration Policy +│ └── Monetization Extensions +│ +├── Trust Layer +│ ├── Phase Registry +│ ├── Extension Registry +│ ├── Target Ledger +│ ├── Metrics +│ ├── Evidence Management +│ └── Conversion Attestations +│ +└── Federation Layer + ├── Open schemas + ├── Signed records + ├── Replication + ├── Independent verification + ├── Auditor attestations + └── Provider discovery +``` + +## Core formulation + +> The TRSL Trust Service is the canonical publication, accounting and attestation infrastructure for Target Revenue phases. It registers immutable phase definitions and monetization extensions, records Development and Remission Credits, calculates public metrics and publishes signed Conversion Attestations. Its records provide authoritative evidence, but the legal conversion of a Milestone Release occurs automatically according to the license and does not depend on discretionary approval by the Trust Service. The initial service may be centrally operated to support consistent evolution of the framework, while using open schemas, signed append-only records and deterministic calculations that enable later replication, independent verification and federation. + +This gives the framework a useful dual structure: + +> **The license supplies legal certainty. The Trust Service supplies factual certainty.** + +## Prompt 5 - One Line Description + +Good, i want to set up the framework. Can you provide me with a oneline description. + +The Target Revenue Framework combines a source license and trust service to monetize software development transparently until a defined revenue target is satisfied and the governed release automatically becomes permissively open source. + + +xxx diff --git a/spec/TargetRevenueLicenseConcept.md b/spec/TargetRevenueLicenseConcept.md new file mode 100644 index 0000000..6c174ea --- /dev/null +++ b/spec/TargetRevenueLicenseConcept.md @@ -0,0 +1,1188 @@ +# Target Revenue License Concept + +**Working name:** Target Revenue Source License (TRSL) +**Framework name:** Target Revenue Framework (TRF) +**Document status:** Concept draft +**Purpose:** Define the conceptual foundation for a revenue-triggered software licensing and monetization framework. + +> The Target Revenue Framework combines a source license and trust service to monetize software development transparently until a defined target is satisfied and the governed release automatically becomes permissively open source. + +--- + +## 1. Executive Summary + +The Target Revenue Framework is a phased approach to financing exploratory, product-driven software development. + +For each development phase, a clearly identified software improvement leads to a defined **Milestone Release**. The phase declares an immutable **Initial Target** representing the intended commercial return for that development. During the phase: + +- noncommercial use may be permitted under a source-available license; +- commercial use requires an appropriate commercial entitlement; +- qualifying payments create **Development Credits** against the Initial Target; +- a published degeneration policy may create **Remission Credits** when market validation does not progress sufficiently; +- operations, services, consulting, ideation, sponsorship, and other activities may be monetized independently through standardized or project-specific profiles. + +When Development Credits and Remission Credits together satisfy the Initial Target, the Milestone Release automatically and irrevocably becomes available under a declared permissive **Future License**, initially expected to be MIT or Apache-2.0. + +A centralized **Trust Service** publishes authoritative phase declarations, monetization extensions, ledger states, metrics, and conversion attestations. It supplies factual certainty but does not possess discretionary authority to prevent a conversion that has already occurred under the license. The architecture should be designed from the beginning for later verification, replication, and federation. + +--- + +## 2. Motivation + +Exploratory product development creates an economic coordination problem: + +1. New software capabilities require up-front work and risk-taking. +2. Fully proprietary licensing can restrict adoption, inspection, learning, and ecosystem participation. +3. Immediate permissive open-source publication may make it difficult to recover development investment. +4. Conventional open-core and dual-licensing models do not necessarily connect commercial success to a transparent transition into the software commons. +5. Product exploration benefits from multiple monetization paths, including development licensing, hosted operations, services, consulting, ideation, and sponsorship. + +The Target Revenue Framework addresses this problem by creating a temporary and observable commercial protection period around a specific body of development. Commercial users collectively contribute toward a published target. Every qualifying contribution brings the corresponding release closer to permissive open-source publication. + +The intended bargain is: + +> Commercial beneficiaries fund the creation and early availability of a software improvement; once the declared target has been satisfied, the resulting Milestone Release becomes part of the permissive software commons. + +--- + +## 3. Scope + +This concept defines: + +- the minimal terminology of the Target Revenue Framework; +- the relationship between the license and the Trust Service; +- the phase and conversion lifecycle; +- the distinction between development monetization and other monetization activities; +- the accounting boundary for Development Credits and Remission Credits; +- the extension mechanism for additional monetization models; +- the initial centralized and later federated Trust Service architecture; +- the fundamental trust, transparency, and irreversibility rules. + +This concept does **not** yet define: + +- final legal license text; +- a final formula for target degeneration; +- tax or financial-accounting treatment; +- detailed pricing schedules; +- service-level agreements; +- jurisdiction-specific commercial agreements; +- the implementation technology of the Trust Service; +- final governance institutions. + +--- + +## 4. Design Goals + +The framework should be: + +### 4.1 Easy to explain + +The core mechanism should be understandable as: + +> Define a target, credit qualifying payments, remit part of the target over time, and convert the release when the target is satisfied. + +### 4.2 Legally determinate + +The governed software, target, applicable rules, and conversion condition must be identifiable without relying on discretionary interpretation by the licensor or Trust Service. + +### 4.3 Economically explicit + +Payments must be classified and allocated according to the value supplied. Operations revenue, service revenue, consulting revenue, and other income must not accidentally or ambiguously count as development monetization. + +### 4.4 Extensible without fragmenting the core + +New monetization ideas should be publishable as extensions or profiles without creating incompatible license variants or redefining the core terms. + +### 4.5 Transparent and auditable + +Users should be able to inspect the phase definition, applicable rules, aggregate ledger state, progression toward conversion, and final conversion evidence. + +### 4.6 Resistant to manipulation + +The framework must prevent silent target increases, duplicate credits, discretionary postponement of conversion, retroactive withdrawal of rights, and opaque degeneration adjustments. + +### 4.7 Federation-ready + +The initial Trust Service may be centralized, but records and calculations should be portable, signed, reproducible, and independently verifiable. + +--- + +## 5. Non-Goals + +The framework is not intended to: + +- guarantee that a product or improvement will reach its target; +- guarantee profitability; +- impose a universal pricing model on all projects; +- make hosted operation, support, or consulting free after license conversion; +- determine the commercial value of an improvement objectively; +- prevent independent competition after permissive conversion; +- replace contracts for hosting, services, support, data processing, or customer-specific work; +- act as a tax, revenue-recognition, or general accounting standard. + +--- + +## 6. Conceptual Architecture + +The framework consists of a small legal and accounting kernel supported by standardized publication and evidence infrastructure. + +```mermaid +flowchart TB + TRF[Target Revenue Framework] + + TRF --> Legal[Legal Layer] + TRF --> Declaration[Declarative Layer] + TRF --> Trust[Trust Layer] + TRF --> Federation[Federation Layer] + + Legal --> License[Target Revenue Source License] + Legal --> Agreements[Commercial and Service Agreements] + + Declaration --> Phase[Phase Manifest] + Declaration --> Degeneration[Degeneration Policy] + Declaration --> Extensions[Monetization Profiles and Extensions] + + Trust --> Registry[Phase and Extension Registry] + Trust --> Ledger[Target Ledger] + Trust --> Metrics[Metrics and Forecasts] + Trust --> Evidence[Evidence and Attestations] + + Federation --> Schemas[Open Schemas] + Federation --> Signatures[Signed Records] + Federation --> Replication[Replication and Verification] + Federation --> Providers[Federated Trust Service Providers] +``` + +The architecture rests on a strict separation: + +> The license establishes legal rights and automatic conversion. The Trust Service establishes an authoritative and verifiable factual record. + +--- + +## 7. Minimal Core Terminology + +The normative core should remain deliberately small. + +### 7.1 Phase + +A bounded development undertaking governed by one Initial Target, one Milestone Release, one degeneration policy, and one Future License declaration. + +A Phase may cover: + +- a bug fix; +- a refactoring; +- a performance improvement; +- a new feature; +- a new integration; +- a product-defining capability; +- a platform-level improvement. + +### 7.2 Milestone Release + +The precisely identified software release that will become available under the Future License when the Conversion Event occurs. + +The Milestone Release should be identifiable through an immutable release artifact, source revision, cryptographic digest, or equivalent reproducible reference. + +### 7.3 Initial Target + +The immutable monetary target declared for the Phase. + +The Initial Target is a historical statement of the intended development monetization opportunity. It must not be silently increased or rewritten after the Phase has begun. + +### 7.4 Target Multiple + +A multiplier applied to the estimated development cost to determine the Initial Target. + +The Target Multiple represents a product and commercial hypothesis, not an objectively measurable claim that the software becomes a corresponding number of times better. + +Indicative classes are: + +| Class | Multiple | Indicative interpretation | +|---|---:|---| +| Commons | 0x | Immediate permissive release or no development monetization target | +| Recovery | 1x | Direct development cost recovery | +| Incremental | 10x | Material enhancement of an existing use case | +| Product-defining | 100x | Significant commercial differentiator or new product capability | +| Platform-defining | 1000x | New platform, market, ecosystem, or foundational capability | + +The names and criteria of these classes remain subject to refinement. + +### 7.5 Development Credit + +The portion of a collected and settled payment explicitly allocated toward satisfying the Initial Target of a specific Phase. + +Development Credit is an accounting concept of the framework. It is not synonymous with total revenue, recognized accounting revenue, cash flow, profit, or contribution margin. + +### 7.6 Remission Credit + +A transparent, non-revenue reduction of the Outstanding Target generated under the published degeneration policy. + +Remission Credit records the expiry or reduction of the remaining commercial protection opportunity. It must never be represented as revenue captured. + +### 7.7 Outstanding Target + +The remaining amount required for conversion. + +\[ +T_{outstanding} = \max(0, T_0 - C - R) +\] + +where: + +- \(T_0\) is the Initial Target; +- \(C\) is cumulative Development Credit; +- \(R\) is cumulative Remission Credit. + +### 7.8 Conversion Event + +The moment at which the Outstanding Target reaches zero. + +At the Conversion Event, the Milestone Release automatically and irrevocably becomes available under the declared Future License. + +### 7.9 Future License + +The permissive open-source license that applies to the Milestone Release after the Conversion Event. + +Initial candidates are: + +- MIT for simplicity and broad compatibility; +- Apache License 2.0 where an explicit patent grant is preferable. + +### 7.10 Trust Service + +The publication, accounting, metrics, evidence, and attestation infrastructure for the framework. + +The Trust Service observes, records, calculates, and attests. It must not possess discretionary power to prevent a conversion that has occurred under the license. + +### 7.11 Monetization Profile or Extension + +A standardized or project-specific declaration describing: + +- what value is supplied; +- how it is priced; +- how payments are allocated; +- when allocations are recognized; +- how reversals are handled; +- what evidence is required. + +An extension may not redefine the core meaning of Phase, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, or Future License. + +--- + +## 8. Target Determination + +The initial target model is: + +\[ +\text{Estimated Development Cost} += +\text{Estimated Effort} +\times +\text{Published Rate} ++ +\text{Approved Direct Costs} +\] + +\[ +\text{Initial Target} += +\text{Estimated Development Cost} +\times +\text{Target Multiple} +\] + +Example: + +```text +Estimated effort: 1 day +Published daily rate: $1,000 +Approved direct costs: $0 +Target Multiple: 100x +Initial Target: $100,000 +``` + +The estimate and multiple should be published before Development Credits are accepted. + +The Initial Target may be reduced through Remission Credits. It should not be retroactively rewritten, because retaining the original target preserves the historical product hypothesis and the audit trail. + +--- + +## 9. Core Lifecycle + +The framework can be understood through five verbs. + +### 9.1 Define + +Publish the Phase, Milestone Release, Initial Target, Future License, degeneration policy, and applicable monetization extensions. + +### 9.2 Allocate + +Classify each payment and allocate it between target-relevant and non-target purposes. + +### 9.3 Credit + +Recognize the eligible target-relevant allocation as Development Credit for one identified Phase. + +### 9.4 Remit + +Generate Remission Credit according to the published degeneration policy. + +### 9.5 Convert + +Automatically apply the Future License to the Milestone Release when the Outstanding Target reaches zero. + +```mermaid +stateDiagram-v2 + [*] --> Defined + Defined --> Active: Phase published + Active --> Active: Development Credit + Active --> Active: Remission Credit + Active --> Converted: Outstanding Target = 0 + Converted --> [*] +``` + +--- + +## 10. Core Rules + +The normative kernel should be limited to rules that are universal, interoperability-critical, and trust-critical. + +### Rule 1 — Immutable phase definition + +The Phase, Milestone Release, Initial Target, Target Multiple, Future License, and applicable degeneration policy must be published before Development Credits are accepted. + +Subsequent changes must be versioned, historically visible, and constrained by the framework. The Initial Target may not be increased for commercial convenience after the Phase begins. + +### Rule 2 — Explicit allocation + +No payment creates Development Credit unless its development allocation is explicitly defined. + +### Rule 3 — No duplicate credit + +The same economic value may not be credited more than once, whether against one Phase or several Phases. + +### Rule 4 — Settled-payment recognition + +Development Credit normally arises only from collected and settled payments. Refunds, chargebacks, and equivalent reversals must generate compensating ledger entries. + +### Rule 5 — Separate remission + +Target degeneration must be recorded as Remission Credit and never misrepresented as captured revenue. + +### Rule 6 — Automatic conversion + +When the Outstanding Target reaches zero, conversion occurs automatically and irrevocably without requiring further discretionary action by the licensor or Trust Service. + +### Rule 7 — Permanent prior freedom + +Rights granted to an earlier Milestone Release may not be withdrawn or restricted by a later Phase. + +### Rule 8 — Correction without erasure + +Published ledger history should be append-only. Errors and reversals should be corrected through compensating entries rather than deletion or silent modification. + +### Rule 9 — Conversion irreversibility + +Once a valid Conversion Event has occurred, later refunds, accounting corrections, service failures, or disputes must not revoke the Future License grant. + +--- + +## 11. Monetization Architecture + +### 11.1 Core economic distinction + +The core distinguishes only between: + +- **target-relevant allocation**, which may become Development Credit; and +- **non-target allocation**, which does not affect the Outstanding Target. + +A transaction may be represented as: + +```yaml +payment: + collected_amount: 1500 + development_allocation: 500 + non_target_allocation: 1000 + phase: trsl:phase:example-001 + monetization_profile: hosted-operations-v1 +``` + +The monetization profile explains the business transaction. The explicit allocation determines its effect on conversion. + +### 11.2 Development monetization + +Development monetization covers payments for commercial access to the protected development, including: + +- commercial-use rights; +- early commercial access; +- access to protected features; +- enterprise distribution rights; +- phase-specific commercial entitlements. + +Canonical default: + +```text +Development allocation: 100% +``` + +subject to taxes, refunds, chargebacks, and any explicitly declared exclusions. + +### 11.3 Operations monetization + +Operations monetization covers the provision of an operated capability, including: + +- compute; +- storage; +- networking; +- external APIs; +- monitoring; +- backup and recovery; +- deployment maintenance; +- security operations; +- incident response; +- operational labor; +- capacity and availability risk. + +The proposed canonical pricing profile is: + +\[ +\text{Operations Price} += +\text{Eligible Operations Cost} +\times +(1 + \text{Operations Surcharge}) +\] + +Initial default: + +```text +Operations surcharge: 50% +Development allocation: 0% +``` + +Example: + +```text +Eligible operations cost: $100 +Operations surcharge: $50 +Customer price: $150 +Development Credit: $0 +``` + +A project may explicitly allocate part of the surcharge to development, but the default should be zero to preserve a clear boundary between funding development and paying for operation. + +The conversion of software to the Future License does not make hosting, support, compute, security, or operational responsibility free. + +### 11.4 Ideation monetization + +Ideation monetization may cover: + +- opportunity discovery; +- problem exploration; +- feasibility analysis; +- product conception; +- architecture exploration; +- prioritization rights; +- design workshops; +- commissioned product hypotheses. + +Canonical default: + +```text +Development allocation: 0% or explicitly declared +``` + +An allocation may be appropriate when a reusable product artifact is incorporated into the governed Phase. + +### 11.5 Service monetization + +Service monetization may cover: + +- installation; +- migration; +- configuration; +- integration; +- customization; +- training; +- support; +- managed onboarding. + +Canonical default: + +```text +Development allocation: 0% +``` + +A reusable deliverable incorporated into the Milestone Release may receive an explicit development allocation. + +### 11.6 Consulting monetization + +Consulting monetizes knowledge, analysis, and judgment, including strategy, architecture, security, organization, product, and implementation advice. + +Canonical default: + +```text +Development allocation: 0% +``` + +### 11.7 Sponsorship monetization + +Sponsorship should distinguish at least: + +- phase sponsorship; +- feature sponsorship; +- general project sponsorship; +- infrastructure sponsorship; +- promotional sponsorship. + +Canonical default: + +```text +Development allocation: explicitly declared +``` + +Unrestricted sponsorship should not be silently assigned to an arbitrary Phase. + +--- + +## 12. Monetization Extension Contract + +An extension should answer only the questions necessary to integrate it into the core accounting model. + +```yaml +extension: + id: trsl:extension:example + version: "1.0" + + value: + description: What does the payer receive? + + pricing: + method: How is the payment calculated? + + allocation: + rule: What portion may become Development Credit? + + recognition: + event: When is the allocation recognized? + + reversal: + rule: How are refunds, chargebacks, or corrections handled? + + evidence: + requirement: What proves the transaction and allocation? +``` + +An extension may define commercial mechanics but may not alter the license kernel or conversion formula. + +### 12.1 Registered extensions + +Any extension that conforms to the extension contract and is published through the Trust Service. + +Registration indicates structural compatibility, not endorsement. + +### 12.2 Canonical extensions + +Extensions reviewed and maintained as recommended framework profiles. + +Initial candidates are: + +- `development-license`; +- `cost-plus-operations`; +- `phase-sponsorship`; +- `service-with-development-allocation`; +- `product-ideation`; +- `general-consulting`. + +--- + +## 13. Target Degeneration and Remission + +A pure revenue trigger may leave an unsuccessful or abandoned release restricted indefinitely. The framework should therefore support target degeneration over time. + +The degeneration mechanism must preserve three distinctions: + +1. The Initial Target remains historically immutable. +2. Actual development monetization is recorded as Development Credit. +3. Time- or progress-based target reduction is recorded as Remission Credit. + +The general model is: + +\[ +T_{outstanding}(t) += +\max(0, T_0 - C(t) - R(t)) +\] + +The degeneration policy should be published at Phase creation and should be deterministic or objectively calculable. + +### 13.1 Intended properties + +A suitable degeneration policy should: + +- prevent indefinite commercial restriction; +- react to insufficient material progress toward the target; +- preserve incentives during periods of genuine commercial validation; +- remain easy to explain and calculate; +- avoid manipulation through unrelated revenue; +- use Development Credit rather than operations success as the primary progress signal; +- provide an eventual path to conversion even when the initial product hypothesis fails. + +### 13.2 Possible inputs + +A future policy may consider: + +- elapsed time since Phase activation; +- Development Credit earned during a measurement period; +- percentage of Initial Target already satisfied; +- time since the last material Development Credit; +- number or diversity of commercial contributors; +- phase maintenance or abandonment status; +- a maximum protection period. + +### 13.3 Longstop + +A Longstop Date may be represented as either: + +- a separate maximum protection rule; or +- the point at which the degeneration policy necessarily remits the full remaining target. + +The detailed relationship between progress-sensitive degeneration and a fixed longstop remains an open design question. + +### 13.4 Non-interference by operations revenue + +Operations revenue should not suspend degeneration merely because a hosted service is successful. Operations success validates demand for an operated capability; Development Credit validates the protected development monetization hypothesis. + +--- + +## 14. The Trust Service + +### 14.1 Purpose + +The Trust Service creates a shared, authoritative, and verifiable factual basis for applying the framework. + +It should provide: + +- a Phase Registry; +- an Extension Registry; +- an append-only Target Ledger; +- metrics and forecasts; +- evidence references; +- signed checkpoints; +- Conversion Attestations; +- export and verification interfaces. + +### 14.2 Responsibility boundary + +The Trust Service: + +- observes; +- records; +- validates conformance; +- calculates; +- publishes; +- attests. + +It does not possess discretion over whether a Conversion Event occurs. + +A Conversion Attestation is evidence of conversion, not the legal cause of conversion. + +### 14.3 Centralized initial architecture + +The first Trust Service should be centrally operated to support: + +- one canonical interpretation of the developing standard; +- rapid improvement of terminology and rules; +- consistent extension review; +- uniform metrics; +- simpler integration; +- coherent dispute handling; +- faster learning from real product phases. + +Centralization is an intentional learning strategy, not a permanent architectural requirement. + +### 14.4 Federation-ready properties + +The centralized service should provide from the beginning: + +- open schemas; +- deterministic calculations; +- globally unique identifiers; +- signed records; +- append-only history; +- cryptographic linkage of ledger entries; +- complete phase exports; +- independent verification tools; +- stable versioning; +- published key-rotation history. + +### 14.5 Public and confidential evidence + +The Trust Service should distinguish: + +#### Public record + +- Phase declaration; +- Initial Target; +- aggregate Development Credit; +- aggregate Remission Credit; +- Outstanding Target; +- applicable extensions and policies; +- ledger entry identifiers and timestamps; +- signed checkpoints; +- conversion status. + +#### Confidential audit evidence + +- contracts; +- invoices; +- payment receipts; +- allocation calculations; +- refunds and chargebacks; +- cost evidence where required by a profile. + +#### Private commercial data + +- customer identities where disclosure is unnecessary; +- user-level consumption; +- unrelated contractual provisions; +- operational secrets; +- personal data not required by the framework. + +### 14.6 Metrics + +The Trust Service may publish: + +- target satisfaction percentage; +- Development Credit velocity; +- Remission Credit velocity; +- time since material progress; +- contributor count or diversity; +- projected conversion dates; +- confidence ranges and assumptions. + +Metrics must distinguish clearly between: + +- ledger facts; +- deterministic calculations; +- forecasts; +- recommendations. + +Forecasts must not alter the legal conversion mechanism. + +--- + +## 15. Trust Service Federation Path + +The Trust Service may evolve through the following maturity stages. + +### Stage 0 — Centralized authority + +One service registers Phases, extensions, ledger entries, metrics, and attestations. + +### Stage 1 — Public verification + +Third parties can export and independently verify records and calculations. + +### Stage 2 — Read federation + +Other services replicate, preserve, and index authoritative records. + +### Stage 3 — Attestation federation + +Independent auditors or services may countersign checkpoints and Conversion Events. + +### Stage 4 — Operator federation + +Projects may choose among compatible Trust Service providers. + +### Stage 5 — Multi-authority phases + +A Phase may use several accepted authorities, auditors, or threshold attestations. + +### Stage 6 — Protocol-governed ecosystem + +Governance, discovery, replication, compatibility, and trust are distributed across an open federation. + +--- + +## 16. Minimum Phase Manifest + +A minimal Phase Manifest could be: + +```yaml +framework: TRF-0.1 +license: TRSL-0.1 + +phase: + id: trsl:phase:example-001 + milestone_release: + name: release-1.0 + source_revision: abc123 + artifact_sha256: "..." + + initial_target: + amount: 100000 + currency: USD + + target_basis: + estimated_effort_days: 1 + daily_rate: 1000 + approved_direct_costs: 0 + target_multiple: 100 + + future_license: MIT + degeneration_policy: trsl:policy:progress-decay-v1 + ledger: https://trust.example/phases/example-001 + +extensions: + - trsl:extension:development-license@1.0 + - trsl:extension:cost-plus-operations@1.0 +``` + +The legally required subset should remain smaller than the recommended transparency metadata. + +--- + +## 17. Target Ledger + +A ledger entry may use a common structure for credits, remission, reversals, and corrections. + +```yaml +entry: + id: trsl:entry:01KEXAMPLE + phase: trsl:phase:example-001 + type: development-credit + amount: 2500 + currency: USD + recognized_at: 2026-10-15T09:30:00Z + + extension: + id: trsl:extension:development-license + version: "1.0" + + evidence_reference: confidential:evidence:123 + previous_entry_hash: "..." + signature: "..." +``` + +Permitted entry types may include: + +- `development-credit`; +- `remission-credit`; +- `credit-reversal`; +- `remission-correction`; +- `administrative-correction`; +- `conversion-checkpoint`. + +The ledger should favor compensating entries over mutation or deletion. + +--- + +## 18. Conversion + +The legal mechanism should establish that: + +1. the Conversion Event is objectively determined by the Phase Manifest, ledger, and degeneration policy; +2. conversion occurs automatically when the Outstanding Target reaches zero; +3. no declaration by the licensor or Trust Service is required for legal effect; +4. the Future License grant is irrevocable; +5. the Milestone Release remains permanently available under the Future License; +6. later Phases may govern later improvements but may not restrict the converted release; +7. later accounting reversals do not restore the prior restriction. + +The Trust Service should publish a signed Conversion Attestation containing: + +- Phase identifier; +- Milestone Release identifier; +- conversion timestamp; +- Future License; +- final Development Credit total; +- final Remission Credit total; +- final Outstanding Target; +- supporting ledger checkpoint; +- signature and verification information. + +--- + +## 19. Successive Phases + +Software may evolve through multiple independently governed phases. + +```mermaid +flowchart LR + M1[M1 converted to MIT] + P2[Phase 2 protected improvements] + M2[M2 converts to Future License] + P3[Phase 3 protected improvements] + + M1 --> P2 --> M2 --> P3 +``` + +Each Phase must identify: + +- its base release; +- the included change set; +- its Milestone Release; +- its Initial Target; +- its Future License; +- its degeneration policy; +- its ledger. + +Earlier freedoms remain permanent. A new Phase protects only the later governed improvements and does not re-proprietarize earlier converted code. + +--- + +## 20. Governance Principles + +### 20.1 Complexity budget + +A rule should enter the core only when interoperability or trust cannot be achieved without it. + +A proposed core addition should pass three tests: + +- **Universal:** Nearly every Phase needs it. +- **Interoperable:** Different implementations would otherwise produce incompatible meanings. +- **Trust-critical:** Its absence would permit manipulation of the conversion bargain. + +Otherwise, the rule belongs in a canonical profile, implementation guide, project policy, or optional extension. + +### 20.2 Versioning + +The framework should version independently: + +- the TRSL legal text; +- the framework core; +- Phase Manifest schemas; +- ledger schemas; +- degeneration policies; +- monetization extensions; +- Trust Service protocols. + +A Phase should remain governed by the declared versions unless an allowed and explicitly accepted migration occurs. + +### 20.3 Extension governance + +The Trust Service should publish: + +- registration criteria; +- canonicalization criteria; +- conformance tests; +- compatibility rules; +- deprecation rules; +- conflict-of-interest rules; +- dispute procedures. + +### 20.4 Operator governance + +The centralized Trust Service should disclose: + +- operator identity; +- applicable terms; +- signing keys; +- key-rotation history; +- service continuity policy; +- archival and export policy; +- correction and dispute processes; +- framework change process. + +--- + +## 21. Legal Architecture + +The complete legal and commercial system will likely require several coordinated instruments. + +### 21.1 Target Revenue Source License + +The public source license should govern: + +- permitted noncommercial use; +- restrictions on unlicensed commercial use; +- modification and redistribution during the protected Phase; +- commercial entitlement requirements; +- patent treatment; +- termination and cure; +- warranty and liability exclusions; +- automatic Future License conversion. + +Before conversion, the software should be described as **source available**, not Open Source in the OSI sense, because the commercial-use restriction is incompatible with the Open Source Definition. + +### 21.2 Commercial Use Agreement + +A separate agreement should govern: + +- commercial entitlements; +- pricing; +- metering; +- payment; +- customer and affiliate scope; +- audit rights; +- support; +- liability; +- allocation of payments to Phases. + +### 21.3 Operations and Service Agreements + +Hosting, support, consulting, integration, data processing, and other services should be governed separately from the copyright license. + +### 21.4 Contributor rights + +The project must hold sufficient rights to promise both: + +- the protected TRSL phase license; and +- the later permissive Future License. + +Contributor arrangements may therefore require copyright assignment or an appropriately broad contributor license agreement. + +### 21.5 Legal review + +The final license and related agreements require specialist legal review, including review of: + +- automatic conditional license grants; +- standard-terms law; +- copyright and patent rights; +- contributor rights; +- audit and evidence provisions; +- international enforceability; +- consumer and business distinctions; +- insolvency and service discontinuity scenarios. + +This document is a product and framework concept, not legal advice or final license text. + +--- + +## 22. Foundational Invariants + +The framework should preserve the following invariants: + +1. Every Phase has one identifiable Milestone Release. +2. Every Phase has one immutable Initial Target. +3. Every target-affecting movement is either Development Credit, Remission Credit, or an explicit correction or reversal. +4. No payment contributes without an explicit allocation rule. +5. The same value cannot be credited twice. +6. Operations monetization remains independent by default. +7. Degeneration is visible and is never represented as earned revenue. +8. Conversion is automatic, objective, and irrevocable. +9. The Trust Service supplies evidence, not discretionary permission. +10. Earlier permissive rights cannot be withdrawn by later Phases. +11. Extensions may add commercial models but cannot redefine the core. +12. Centralized operation must not prevent independent future verification or federation. + +--- + +## 23. Illustrative Example + +A project defines a one-day, product-defining feature: + +```text +Estimated effort: 1 day +Daily rate: $1,000 +Target Multiple: 100x +Initial Target: $100,000 +Future License: MIT +``` + +During the Phase: + +```text +Commercial development licenses: $25,000 Development Credit +Hosted operations revenue: $30,000, with $0 Development Credit +Feature sponsorship: $10,000 Development Credit +Service engagement: $12,000, of which $2,000 is allocated + to reusable development +Remission Credit: $18,000 +``` + +The ledger state is: + +```text +Initial Target: $100,000 +Development Credit: $37,000 +Remission Credit: $18,000 +Outstanding Target: $45,000 +``` + +Later, an additional $30,000 Development Credit and $15,000 Remission Credit reduce the Outstanding Target to zero. The Milestone Release automatically becomes available under MIT. Hosted operations, support, consulting, and later protected improvements may continue to be monetized. + +--- + +## 24. Open Design Questions + +The following questions require dedicated design work: + +1. What precise rights should noncommercial users receive during the protected Phase? +2. How should commercial use be defined across enterprises, contractors, affiliates, public institutions, research organizations, and mixed-purpose use? +3. Should MIT, Apache-2.0, or both be supported as canonical Future Licenses? +4. How should 0x, 1x, 10x, 100x, and 1000x classifications be defined and justified? +5. Which development-cost components may enter the target basis? +6. How should currencies and foreign-exchange conversion be handled? +7. What is the simplest progress-sensitive degeneration formula? +8. Should every Phase have a fixed Longstop Date in addition to degeneration? +9. Which public metrics are mandatory, recommended, or optional? +10. What minimum evidence is required for Development Credit? +11. Which extensions should be canonical in the first release? +12. How are disputes, audits, corrections, and operator conflicts of interest handled? +13. How can Trust Service discontinuity be handled without impairing license conversion? +14. What cryptographic and protocol model best supports later federation? +15. What governance path moves the framework from founder-controlled experimentation to a credible multi-stakeholder standard? + +--- + +## 25. Proposed Initial Deliverables + +The framework can be established through the following artifacts: + +1. `TargetRevenueFrameworkCore.md` + Normative terminology, formulas, invariants, and lifecycle. + +2. `TargetRevenueSourceLicense-Draft.md` + Initial legal drafting basis for specialist review. + +3. `PhaseManifestSpecification.md` + Required and optional Phase declaration fields. + +4. `TargetLedgerSpecification.md` + Ledger entry types, recognition, corrections, signatures, and calculations. + +5. `TargetDegenerationPolicyResearch.md` + Comparative models and candidate degeneration formulas. + +6. `MonetizationExtensionSpecification.md` + Extension contract, registration, conformance, and versioning. + +7. `CanonicalMonetizationProfiles.md` + Development licensing, cost-plus operations, services, consulting, ideation, and sponsorship. + +8. `TrustServiceProductRequirementsDocument.md` + Centralized registry, ledger, metrics, evidence, attestation, export, and verification service. + +9. `TrustServiceFederationArchitecture.md` + Signed records, replication, discovery, independent verification, and operator federation. + +10. `TRSL-Governance.md` + Change process, extension review, canonicalization, disputes, conflicts of interest, and transition toward federation. + +--- + +## 26. Concise Definition + +> The Target Revenue Framework is an extensible software monetization system in which a defined development Phase accumulates transparent Development and Remission Credits against an immutable Initial Target, causing the governed Milestone Release to convert automatically and irrevocably to a permissive open-source license when the target is satisfied, with a Trust Service publishing the authoritative records, metrics, extensions, and evidence required to make the process credible and verifiable. + +--- + +## 27. Concept Summary + +The Target Revenue Framework is built around a deliberately small kernel: + +- one governed Phase; +- one Milestone Release; +- one immutable Initial Target; +- two target-reducing credit types; +- one objective Conversion Event; +- one declared Future License; +- one Trust Service evidence model; +- one constrained extension interface. + +This minimal structure allows the framework to remain understandable while supporting a broad and evolving monetization canon. Development licensing funds the protected improvement. Operations monetization pays for operating the capability. Other forms of value creation may be integrated through explicit profiles and extensions. Target degeneration provides an eventual path into the commons when commercial validation is weak. The Trust Service enables consistent learning and adoption through centralization first, while open records and deterministic calculations prepare the framework for later federation. + +xxx