# License Architecture Review

## Evidence reviewed

The buyer-provided purchase certificate states:

- LIFETIME / UNLIMITED / FULL RIGHTS
- Full Source Code Ownership
- Free Modification & Customization
- Unlimited Deployment
- Commercial Rights & Resale

The source package itself contains a separate source-license document and EULA that mention a five-device limit and update/support dates. These statements do not fully match the buyer-provided certificate, so they must be treated as two different pieces of evidence rather than silently choosing one.

## Current implementation

The application performs license verification during backend startup and periodically performs a heartbeat. The implementation tracks a machine identifier, license status, signed responses, machine limits, and an offline grace period. Terminal statuses can stop the process.

The application is therefore not fully self-contained from an entitlement perspective: the license service remains an external runtime dependency.

## Engineering risk

This is a reliability and contract-alignment risk rather than an authentication bug:

1. A remote license service can affect application startup.
2. A future server-side status can terminate a running process.
3. Machine binding can prevent a reinstall/migration even when the purchaser expects permanent use.
4. The source contains more than one description of device/update/support rights.

## Decision for this release

The secured release does **not** silently remove or bypass the license verification mechanism. Security changes are kept separate from entitlement changes so the production build does not accidentally alter contractual behavior.

Before changing enforcement to a self-contained/perpetual entitlement model, the final license terms should be reconciled against the buyer-provided certificate and the seller's actual intended deployment policy.

## Recommended architecture

Long-term, separate the application from the entitlement provider behind an explicit interface:

```text
Application
   |
   +-- LicenseProvider interface
          |
          +-- RemoteEntitlementProvider   (current)
          |
          +-- SignedLocalEntitlementProvider (future, if contract permits)
```

The application should depend on an entitlement result, not directly on HTTP calls to a vendor service. This makes reinstall/migration, testing, and future license-policy changes safer without mixing them into security-critical application code.

Any future local entitlement format should be cryptographically signed and should not contain a hard-coded private signing key in the application source.