§24 Entity & Licensing Structure

The Decision Lineage Protocol operates across three architectural layers — the protocol specification, the reference implementation and assets, and commercially delivered substrates — each with distinct ownership and licensing characteristics. This section specifies the three-layer licensing model, the license types, license attestation, conformance verification, federation licensing across legal entity boundaries, and profile graduation licensing.

The licensing architecture bridges the separation of protocol specification from implementation from application ownership. It establishes:

1. Three layers of distinct access and ownership. The protocol layer (open specification) separates from the reference layer (open implementation and reference assets), which separates from the commercial layer (Studio-delivered substrates). What organizations build on any substrate is their own — the application boundary is absolute and is not a licensed layer.

2. Conformance as an open, verifiable property. Architectural conformance is independently testable by anyone against the open specification. Conformance verification is not gated by any commercial relationship.

3. Federation licensing for multi-entity ecosystems. Organizations at different scales can integrate through federation agreements that operate as Constraint primitives (§4), enabling recursive viable system patterns across legal entity boundaries.

4. Profile graduation as a topology event, not a license event. Profiles (§21) are substrate configurations, never license tiers. As governance instances evolve (project to business to enterprise), the substrate topology changes; commercial terms change only where a commercial engagement exists.

The licensing architecture rests on three foundations:

1. Protocol and reference openness. The protocol layer — the specification of the nineteen primitives, ten behavioral invariants, truth type system, and state transformation model — is open under Apache 2.0. The reference implementation — the SDK and Core Workbench that make the grammar operational — is also open under Apache 2.0, and the reference assets (charter record templates, the ontology, packet schema documentation) are open under CC-BY-SA 4.0. A self-hosted deployment of the open reference stack runs a complete PAS-profile substrate with no commercial relationship. The commercial layer is the delivery of generated, personalized substrates and their operation — not access to the protocol or the means of running it.

The DLP protocol is independently implementable. Any organization can read the specification, build a conformant substrate, and operate governance without licensing any product from any vendor. The reference implementation exists to accelerate adoption and enable independent inspection of conformance — not to gate access to the protocol's governance architecture.

2. License terms as governance objects. The Constraint primitive (§4) operates across legal entity and instance boundaries. Where commercial license terms exist, they are not legal text attached to engineering; they are Constraint primitive instances in the governance graph, enforceable through the same invariant system that governs all substrate operations.

3. Recursive viable system pattern. Federation licensing mirrors the recursive viable system pattern (§23.1). Just as internal recursion enables organizations to structure themselves at multiple scales, federation licensing enables organizations to partner and operate at multiple levels while preserving the same governance guarantees at every scale.

The entity that maintains the specification and reference implementation serves as the stewarding authority for the ecosystem. This authority:

• Owns and maintains the DLP specification (open, Apache 2.0)
• Maintains the open reference implementation and reference assets
• Maintains the conformance test suite (open)
• Delivers and operates commercial substrates through Studio engagements

The stewarding authority's governance is constrained by the open protocol commitment: the DLP specification cannot be retroactively closed, the open reference implementation cannot be retroactively closed, and the three-layer model cannot be collapsed. The protocol and reference layers remain open indefinitely.

§24.1 Three-Layer Licensing Model

The DLP ecosystem is organized into three layers. Each layer has distinct ownership, access rights, and enforcement characteristics.

Table 24.1.1: Three-Layer Model

What organizations build using any layer — their governance substrates' content, domain tools, integrations, and workflows — is organization-owned IP and is not a licensed layer of this model.

Layer Independence

The three layers are architecturally independent. Each layer can exist without the layers above it, and each layer's licensing is self-contained.

Protocol layer is open specification. Anyone can read the DLP specification, study the primitive model, research the behavioral invariants, and build their own implementation from the open specification. No license beyond Apache 2.0 attribution is required to read, study, or implement the protocol.

Reference layer is open implementation and content. The reference SDK and Core Workbench run a complete PAS-profile substrate, self-hosted, under Apache 2.0. The reference assets carry CC-BY-SA 4.0 — attribution required, share-alike on distributed derivatives. The reference layer exists so that a conformant substrate is runnable from open materials alone.

Commercial layer is Studio delivery. What a Studio engagement provides is not access to withheld code — it is the generation of a personalized substrate (charter content composed for the organization, ontology pre-loaded, control surfaces configured) and optionally its custodial operation. Commercial terms attach to the delivered artifact and engagement, not to the protocol or reference layers.

Applications are organization-owned. The licensing relationship, where one exists, is with the delivered substrate — never with what organizations build on it. An organization that builds a governance workflow, configures domain-specific tools, or creates methodology implementations owns that work without encumbrance.

Enforcement Model

Enforcement is narrow by design: commercial terms apply to Studio-delivered artifacts and engagements only. There is no cascading IP tracking, no derivative-work chain analysis, and no multi-degree ownership claims.

Protocol/Reference/Commercial Boundary

The boundary between protocol (specification) and reference (code and content) is the boundary between grammar and machinery. The specification defines the governance grammar — the primitives, composition rules, invariants, and state transformation model. The reference implementation is one engineered system that makes the grammar operational; independent implementations are equally legitimate. The boundary between reference and commercial is the boundary between generic and generated: the reference layer is the same for everyone; the commercial layer is composed for one organization.

This boundary is testable: could someone implement the protocol knowing only the specification? If yes, the knowledge is protocol-level. Could someone run a substrate using only the open reference stack? If yes, the capability is reference-level. Is the artifact composed for a specific organization by the delivery process? Then it is commercial-layer.

Openness at the protocol and reference layers encourages adoption, enables academic study, and invites alternative implementations that grow the DLP ecosystem. The commercial layer funds continued development through delivery and operation — not through gating the grammar or the machinery.

§24.2 License Types

Three license types correspond to the three layers.

Table 24.2.1: License Type Summary

Protocol License

The DLP specification is open under Apache 2.0. The protocol license grants unrestricted access to read, study, teach, and implement the protocol specification. Attribution to GrytLabs is required when publishing implementations; copyright in the specification text is held by GrytLabs Dynamics Inc.

The protocol license covers:

• The nineteen primitive definitions and five-tier hierarchy (§4)
• The ten behavioral invariants (§5)
• The truth type system and claims graduation model (§6)
• The minimum viable record specification (§7)
• The control-theoretic foundation (§8)
• The state transformation model and conservation laws (§9)
• The governance activation model (§12)
• The orchestration grammar specification (§A1, §A2)

The open protocol license enables:

1. Academic study. Researchers can analyze the DLP governance grammar and propose extensions without commercial relationships.
2. Independent implementation. Engineers can build DLP-conformant systems from the open specification. Independent implementations that pass conformance tests strengthen the ecosystem.
3. Interoperability research. The open specification enables interchange format development and cross-implementation compatibility work.

Reference License

The reference layer is open in two grants. The reference implementation — the SDK and Core Workbench — is Apache 2.0: use, modify, and redistribute with attribution. The reference assets — charter record templates, the ontology, packet schema documentation — are CC-BY-SA 4.0: attribution required, and distributed derivatives carry the same license.

A self-hosted deployment of the reference stack runs a complete PAS-profile substrate with no commercial relationship and no feature gate. The reference layer is the floor of the ecosystem, not a demonstration tier.

Studio Commercial License

The commercial license attaches to Studio-delivered substrates: the generated charter content composed for the organization, the pre-loaded ontology and configuration, and optionally custodial operation. Terms are per engagement. The commercial license never restricts the licensee's access to their own governance data, never embeds copy-protection in the substrate, and never claims IP in what the organization builds or records.

There is no application license from any layer. Organizations own their applications and may license them to others under their own terms.

§24.3 License Attestation

Where a commercial engagement exists, its license terms are represented as Constraint primitive instances in the governance graph (§25) and the engagement's standing is attestable as a governance record like any other commitment.

The mechanics by which a commercially delivered substrate attests its engagement standing are commercial-layer implementation detail, not protocol commitment. The protocol commits to two properties:

• Attestation without intrusion. Attestation, where present, operates on records the licensee chooses to expose. The steward receives nothing automatically; governance data remains in the licensee's environment.
• No DRM. The substrate never restricts the licensee's access to, or export of, their own governance data — regardless of engagement standing. License enforcement is a commercial and legal matter; it is never enacted by degrading the licensee's substrate. Open-layer deployments carry no attestation obligation of any kind.

§24.4 Conformance Verification

Architectural conformance — whether an implementation correctly realizes the DLP architecture — is an open, independently testable property. Conformance verification is available to any implementation, commercial or independent, and is not gated by any commercial relationship.

§24.4.1 Conformance Testing

Conformance testing verifies that an implementation correctly realizes the DLP architecture across three levels:

All three levels must pass. Structural conformance alone is insufficient if invariants are not enforced. Behavioral conformance alone is insufficient if composite operations break lineage. All three dimensions together establish architectural soundness.

§24.4.2 Verification Workflow

Initial verification:

1. The operator deploys an instance.
2. The operator runs the open conformance test suite against the deployed instance.
3. All three conformance levels pass (structural, behavioral, compositional).
4. The operator generates a conformance attestation — a signed record of the verification result — and may publish it.

Ongoing verification:

Conformance status is re-verified at defined intervals and after significant configuration changes. Re-verification triggers include scheduled interval, version upgrade, profile configuration change, and constraint modification. Any conformance failure suspends conformant status until restored through the same workflow — there is no expedited path.

Self-service by design. Verification runs locally. No governance data is transmitted to the steward or anyone else. The operator may provide conformance attestations to auditors or counterparties; the attestation, not the governance data, is the verification artifact.

§24.4.3 Conformance in the Ecosystem

A conformant implementation — independent or commercial — may represent itself as conformant, participate in federated deployments with other conformant implementations, and produce interchange exports other substrates can trust structurally. Conformance is the ecosystem's trust signal; commercial standing is a bilateral matter between an organization and its vendor.

§24.5 Federation Licensing

Federation is a recursive pattern — a federated entity operates its own substrate instance with the same internal structure as any other instance (§23.4). Federation licensing specifies how licensing agreements extend across legal entity boundaries.

§24.5.1 Federation Licensing Tiers

Federation licensing tiers vary by deployment context. The protocol commits to federation-as-Constraint with tighten-only cascade across legal entity boundaries (per §23.4). Specific tier structures are licensee implementation choices.

§24.5.2 The Licensing Agreement as Constraint

The federation licensing agreement is the Constraint primitive (§4) instantiated at the organizational boundary. The agreement specifies:

• Methodology constraints. The practitioner follows the licensed methodology. Constraints cascade to the practitioner's child instances.
• Quality constraints. The practitioner meets the parent firm's quality standards, verifiable through conformance testing.
• Reporting obligations. Aggregate metrics flow upward. Depth-gating (§23.4) ensures individual engagement detail does not reach the parent firm.
• Conformance requirements. Each federation party maintains independently verifiable conformance status.

§24.5.3 Recursive Federation

Federation licensing mirrors the recursive viable system pattern (§23.1). Each federation tier operates the same licensing mechanics with different constraint depth. The recursive property produces cascading constraints: a federated practitioner who operates an EAS instance with child instances is itself a recursive structure. The practitioner's child BAS inherits constraints from both the practitioner's own EAS and, transitively, from the parent firm's EAS. This is B6 (Constraint binds primitives, §5) operating across both legal and instance boundaries simultaneously.

Federation depth is unbounded. The protocol does not impose a hard limit on federation depth. A parent firm can federate with a practitioner who federates with a sub-practitioner. Each boundary is a licensing agreement operating as a Constraint. Each boundary follows the tighten-only rule.

§24.5.4 Federation Standing Independence

Standing is independent at each level:

The independence model prevents cascading failures. A parent's standing issue does not invalidate the practitioner's substrate. A practitioner's conformance failure does not degrade the parent's status. Termination of the legal relationship never degrades either party's access to their own governance data.

§24.6 Profile Graduation Licensing

Profile graduation (PAS→BAS, BAS→EAS) is a topology change in the instance portfolio (§23). Graduation creates a new instance with the target profile. Profiles are substrate configurations (§21), never license tiers — graduation is a governance event first, and a commercial event only where a commercial engagement exists.

§24.6.1 Graduation and Licensing

§24.6.2 Evidence Carry-Forward

Graduation carries evidence forward with three governing rules:

1. Evidence integrity. All evidence artifacts carry forward with original truth types, timestamps, and provenance intact. No evidence is modified. Authoritative evidence remains Authoritative.

2. Lineage continuity. The graduation decision links the source instance to the new instance. Carried evidence retains its lineage chain. Graduation extends lineage; it does not break it.

3. Authority chain preservation. Authority delegations from the source do not automatically transfer. The new instance establishes its own authority structure at genesis. Carried evidence references source authority chains for lineage but does not constitute active authority.

§24.6.3 Graduation in Federated Contexts

When a federated entity's instance graduates:

• Federation constraints cascade to the new instance through the tighten-only rule.
• The parent firm's visibility follows federation depth-gating — the parent sees the graduation event in aggregate metrics but not the new instance's governance data.

§24.6.4 Source Instance Disposition

Archival. When graduation replaces the source (project becomes business), the source instance completes its lifecycle and archives. The archived instance remains queryable for lineage.

Continuation. When graduation creates a parallel structure (business adds enterprise governance while operations continue), both instances may operate.

Scope

The licensing architecture constrains:

• Protocol openness. The protocol layer cannot be closed. The DLP specification remains perpetually open under Apache 2.0.
• Reference openness. The reference implementation and assets cannot be retroactively closed. A runnable substrate remains available from open materials alone.
• Layer independence. Each layer has independent licensing. Requirements at one layer do not cascade to others except where explicitly stated.
• Data sovereignty. No layer's licensing may restrict an organization's access to, or export of, its own governance data.
• Application IP protection. No layer claims intellectual property on applications built by organizations. The substrate-application boundary is absolute.

Locked Design Positions

The following positions are locked decisions:

1. Three-layer model is permanent. The separation of protocol (open specification), reference (open implementation and assets), and commercial (Studio-delivered substrates) is structural and cannot be collapsed.

2. The reference implementation is open. The SDK and Core Workbench are Apache 2.0. The runnable substrate is the ecosystem's floor, not a commercial gate.

3. No DRM, no telemetry. The substrate never embeds copy-protection and never restricts a licensee's access to their own governance data. License enforcement is commercial and legal, never technical degradation.

4. Conformance verification is open and self-service. Any implementation can verify conformance locally against the open test suite. No governance data is transmitted in verification.

5. Federation licensing follows the recursive viable system pattern. Federation constraints operate as Constraint primitives with tighten-only cascade at every level. No federation depth limit is imposed.

6. Profiles are never license tiers. PAS, BAS, and EAS are substrate configurations (§21). Commercial terms attach to delivery and operation, not to profile type.

Implementation Requirements

Core SDK commitments for §24:

• MUST implement all three conformance test levels (structural, behavioral, compositional).
• MUST support self-service conformance verification without external data transmission.
• MUST represent commercial license terms, where present, as Constraint primitive instances (§25).
• MUST record graduation events as Decision primitives with lineage.
• MUST enforce federation depth-gating constraints architecturally.
• MUST preserve the licensee's unrestricted access to, and export of, their own governance data regardless of any engagement standing.
• MUST NOT embed copy-protection, usage telemetry, or remote kill-switches in any substrate layer.
• MUST NOT transmit licensee governance data during verification or attestation.
• MUST NOT represent commercial standing as a conformance property, or conformance as a commercial property.