Perpetual Fallback Licenses: Keep a Version, Renew Updates

A perpetual fallback license lets a customer keep using an eligible version after a paid update period ends. It separates continued use of that version from future feature upgrades. The useful promise is specific: which version, what features and dependencies, and how the buyer can reinstall it.

This commercial model is not the same as leaving an ordinary subscription expired, granting unlimited future updates or removing every service dependency. Define the entitlement and delivery policy before describing it as perpetual.

Separate the three deadlines

License access expiry controls whether the license can authorize continued use. Maintenance expiry describes the update/support period you sell. Signed offline expiry bounds a particular proof used while disconnected. Those dates serve different purposes.

A perpetual license can leave ExpiresAt unset while carrying a MaintenanceExpiresAt date. That does not make it immune to product, device, revocation or application-policy checks, and it does not turn a time-limited offline token into an eternal proof.

Publish the support and update terms separately. Assess applicable security-support obligations independently; a maintenance cutoff alone does not decide every security-fix obligation. The security-support planning guide explains the scope and limits of that discussion.

What PermitCore currently provides

PermitCore returns the maintenance date in the license validation response. It does not enforce that date as an automatic last-eligible-release calculation. Your application or update service decides which releases require a current maintenance entitlement.

Optional minimum and maximum version limits provide a different control over allowed dotted-numeric application versions. They do not automatically translate a maintenance date into the correct release. Keep an authoritative release catalog and compare versions with appropriate numeric/version logic, not plain text ordering.

The maintenance reference describes the existing fields. SDK 2.1.1 does not supply a complete updater, release archive or one-click perpetual-fallback conversion workflow.

Define the eligible version precisely

Choose whether a purchase covers releases published during a period, a named major version or another clearly stated rule. Record the release dates and identifiers needed to apply it. A version number alone does not establish when that release became available.

When maintenance ends, keep the eligible build available through your own distribution process and explain how to reinstall it. A license record without an obtainable installer, required runtime or product data may not fulfill the promised experience.

Decide how a customer learns which build is eligible and what happens if it launches a newer one. Offer a supported downgrade or renewal path without overwriting user data blindly. Test file-format compatibility before promising that an older executable can reopen everything created by a newer release.

Keep the update decision separate from the run decision

An otherwise valid perpetual entitlement can allow its eligible installed version to run while denying a new paid feature upgrade. Do not make a maintenance-expired notice override a revoked or otherwise invalid license, and do not equate a failed network request with a valid perpetual entitlement.

For disconnected update eligibility, verify the signed authority actually available to your app. A client-editable maintenance date is not sufficient proof. Offline token verification does not supply your complete release catalog or learn later policy changes automatically.

Configure trusted public keys and deliberate proof lifetimes, then plan reconnect and recovery. If the licensing service might disappear, include the app release and signing/trust strategy in the exit plan. An export alone does not distribute a final offline build.

A Store subscription does not convert itself

An ordinary recurring Store license follows its paid-through, grace and cancellation rules. Cancelling billing does not automatically create a perpetual fallback entitlement. A Store listing also does not automatically calculate and maintain each buyer's last eligible software release.

If you sell a fallback promise, design the separate entitlement and authorised fulfillment policy. Establish when it is earned, how the maintenance period is recorded, how renewals affect it and how refunds or fraud affect eligibility. Verify the actual issued license rather than assuming a pricing label implements the policy.

Keep provider billing separate from license policy. One saved Stripe or Paddle provider serves the vendor Store, and existing subscriptions retain their original binding. A credit-only change is not an independently paid renewal. Use the payment lifecycle guide for current behavior.

Test the promise at the cutoff

• The eligible version runs under an otherwise valid perpetual license after maintenance ends.
• A later paid release is offered, denied or downgraded according to the published policy.
• Wrong-product, revoked and capacity states remain enforced.
• Offline proof expiry, reconnect and application trust updates behave deliberately.
• A clean installation can obtain and use the eligible build with its required dependencies.
• Renewal, refund, cancellation and recovery do not silently rewrite the promised rights.

The outcome depends on your application, release hosting and commercial policy as well as the license fields. Describe the tested experience to the buyer, including services that still require connectivity.