target-revenue/specs/TargetRevenueLicenseConcept.md

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.

Related documents: Living scope in SCOPE.md; product requirements in specs/ProductRequirementsDocument.md; schema orientation in specs/TechnicalSpecificationDocument.md; provisional open-question defaults in specs/OpenQuestions-WorkingDefaults.md. Normative extracts under specs/ (WP-0003) freeze day-to-day terminology; this file remains the ultimate source and governs if the two ever appear to diverge. This file moved from a separate spec/ directory into specs/ on 2026-07-29 (README § spec/ vs specs/); its content and git history are otherwise unchanged.

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.

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:

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.

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:

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:

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:

Operations surcharge:         50%
Development allocation:        0%

Example:

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:

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:

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:

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:

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.

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:

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.

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.

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:

Estimated effort:                  1 day
Daily rate:                        $1,000
Target Multiple:                   100x
Initial Target:                    $100,000
Future License:                    MIT

During the Phase:

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:

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.