Owned, Not Rented: How to Sell Software Licenses That Survive Server Shutdowns and New Ownership Laws

A customer pays once for your desktop app, game, or Unity tool. Five years later, your activation service closes. Does the copy they paid for still open? The useful question in software license vs ownership is what the buyer can actually keep doing when your business, infrastructure, or support policy changes.

You can sell a license and still treat buyers fairly. Define the licensed use, separate that use from optional services, and engineer a credible end-of-life path. A purchase receipt, a perpetual-license label, and a cached validation result each solve different problems.

What the Power To The Players Act and Stop Killing Games ask for

In an official announcement dated October 15, 2026, US Representative Ritchie Torres said he would introduce the Power To The Players Act. His announcement describes FTC rules intended to protect game ownership, continued play, and transfer, including an offline mode before supporting servers close. That announcement is a proposal summary, not enacted statutory text. It does not establish that every desktop application or Unity asset must follow the same rules.

The European debate has its own process. In its June 2026 response to Stop Destroying Videogames, the European Commission said it could not at that stage propose a legal obligation to keep discontinued games playable. It described existing consumer protections and planned work toward an industry end-of-life code of conduct. A campaign, a proposed bill, and an adopted legal requirement are different things.

The engineering lesson is useful before legislation changes: if the product needs your server to start, decide how that dependency ends. An indie editor, a single-player game, and a hosted multiplayer world will need different answers.

License vs ownership: what your checkout promises

California's existing AB 2426 is a separate disclosure rule, effective January 1, 2025. Under Business and Professions Code §17500.6, covered digital-goods transactions using ownership-style purchase wording need a qualifying acknowledgment or a distinct, clear license disclosure with access to its terms before the transaction. The section includes exceptions for subscription-only access, free goods, and goods whose access the seller cannot revoke. A downloadable file with an expiring activation requirement should not casually be described as irrevocable.

Get advice about your markets and actual transaction. A generic sentence or checkbox does not establish compliance. Make your product description, checkout presentation, license terms, receipt, support replies, and application behavior tell the same story.

• Use: who can use the licensed version, on how many devices, and for how long?
• Services: which features depend on accounts, matchmaking, hosted models, storage, or an update service?
• Connectivity: is activation required once, periodically, or at every launch? State the actual offline limit.
• Support: when do updates and support end, and what happens to the installed version afterward?
• Transfers: distinguish moving to a new computer from transferring the entitlement to a different person.

For example, a precise description of a periodically checked product could be: “One-time license for version 3, for one person on two devices. Updates are included for twelve months. Activation requires internet access; the app can then run offline for up to thirty days before another successful license check.” That describes a continuing service dependency honestly. If you promise a final offline build when support ends, provide a separate delivery date and procedure, and test that build before making the promise.

For recurring access, show the billing period, cancellation outcome, and any payment grace clearly. “Perpetual” should describe the purchased use right; it does not by itself guarantee perpetual updates, a hosted service, or a working activation server. Our perpetual vs subscription guide covers that distinction.

Why always-online checks become a shutdown risk

An outage and a shutdown have different recovery assumptions. Retrying a validation request and using a signed cache can bridge an outage. A cache that expires next month cannot bridge a server that will never return.

Map the whole launch path. A valid local license is insufficient if the app also requires an unavailable account login, a mandatory update manifest, a cloud save, a content decryption request, or a remote feature-flag response. For a Unity asset, test a clean project import and an exported player build; editor-only checks and runtime checks may have different dependencies. A multiplayer game may need a local mode or distributable server software, not merely a different license check.

Do not convert every server error into unlimited access while the service is operating. Give customers a deliberate, documented continuity mechanism with trusted verification material. Our license-server outage guide explains the shorter-term failure modes.

Design validation that can outlive your server

Signed licenses let an application verify an entitlement using a public key distributed with the app. Keep the private signing key with the issuer. The signature proves who issued the payload; your application must also enforce its product, device, features, and expiry conditions. Keep the verification keys needed for existing token versions available.

A permanent offline plan has to resolve future reinstalls and replacement hardware too. A device-bound token issued today may help the current laptop without helping a buyer whose replacement laptop arrives after your company closes. Decide whether the final version changes device enforcement, whether a successor can issue entitlements, or whether you provide another usable transfer mechanism. Document the security and business trade-offs.

Offline verification also cannot discover fresh revocations while disconnected, and local clock manipulation remains a limitation. Choose the policy knowingly. The offline grace explanation and offline activation reference cover PermitCore's actual mechanisms.

Let buyers move devices, and define ownership transfers separately

Replacing a broken laptop is ordinary customer support. PermitCore's Customer Portal can remove an old activation so the same customer can activate on another machine while the service remains available, subject to the configured portal authentication policy. The old computer need not be online. See deactivate, then reactivate and the portal documentation.

Reselling or assigning a license to another person is a separate legal and account-management process. Device deactivation is not a buyer-to-buyer ownership transfer. Define eligibility, proof of purchase, treatment of previous activations and offline tokens, and which customer receives future support. Do not tell buyers to share their account password or assume changing an email address settles those questions.

For a Unity asset bought through a marketplace, check the marketplace's applicable license and transfer terms as well as your own. Do not promise resale rights that your distribution arrangement does not grant. A custom key service does not override that arrangement.

Write an end-of-life plan before you need one

1. Name the surviving product. Identify the version and local features buyers retain; list hosted features with their own end dates.
2. Inventory dependencies. Include sign-in, first activation, token refresh, updates, downloads, installers, content servers and certificate/key rotation.
3. Choose the delivery path. A final offline build, an independent operator, or a maintained self-hosted service must have an owner, deadline and budget.
4. Prepare recovery material. Keep installers, integrity hashes, trusted public keys, compatible token formats and data exports. Protect private keys separately.
5. Resolve reinstall and transfer. Test a clean machine and a replacement device, not just the developer's already activated laptop.
6. Test beyond the deadlines. In isolated QA, block every service endpoint, exercise expired grace/token states and verify the intended final-build behavior. Preserve evidence.
7. Deliver while you still can. Notify buyers, make downloads available and explain what they must save before the service closes. Do not leave first key retrieval until after shutdown.
8. Recheck the promise. Review checkout copy, receipts, documentation, EULA and support templates against the actual final release.

Keep this plan next to your restore runbook and release process. A backup helps an operator recover a service; it does not make a customer application independent of that service.

How to use PermitCore for a buyer-friendly plan

Use PermitCore's tools as parts of the design, with their actual boundaries:

• Offline activation (Professional+): issue a signed, device-bound token and distribute the trusted public key in advance. The current generation endpoint accepts ExpiresInDays from 1–365. The token's signed expiry still governs access; Store subscription tokens are capped at paid-through plus effective payment grace.
• Offline grace: configure the license's offline window and obtain a successful signed online result before disconnection. The SDK's cache helps within that deadline, rather than granting unlimited access after shutdown.
• Customer Portal: provide the existing same-customer device deactivation/reactivation flow while the service is reachable. Build any person-to-person entitlement-transfer process around your own reviewed policy.
• Enterprise continuity: signing-key export and self-hosting provide material and operational options for your own continuity design. Preserve trusted public keys, protect exported private keys, and test issuance and restoration independently. Neither option automatically distributes a final offline version of your app.

Start with business continuity, self-hosting, and offline activation. Game and asset developers can follow the Unity licensing tutorial and Unity SDK reference. For direct sales, review your license description and support policy alongside the Store checkout setup.

For concrete disconnected-client examples, work through the Python offline licensing tutorial or C++ offline validation tutorial with the customer's actual device and trusted public key.

FAQ

Do ownership proposals apply to every indie application?

Do not infer that from a game-focused announcement. Coverage depends on the actual rule, jurisdiction, transaction and product. The California disclosure provision uses a broader digital-goods definition, with specified exceptions. Review the applicable text with qualified counsel rather than treating this architecture guide as a legal determination.

Can I still sell subscriptions?

A subscription can honestly sell access for its stated term. Explain cancellation, payment failure and the end of hosted features. The cited California provision expressly treats subscription-only access separately. Proposed game-ownership policy is not a reason to promise lifetime subscription access.

Does an offline license solve every shutdown problem?

No. Check expiry, device binding, key distribution, reinstalls, and every non-licensing server dependency. A long-lived token buys time; a tested final release or independently operated service addresses a different problem.

Does “owned” mean the buyer owns my source code?

Keep the right to use an agreed copy, copyright ownership, source-code access and transfer rights distinct in your terms. The product promise should describe what you actually deliver, not rely on the word “owned” to answer all four questions.

Sell the experience you can continue to honor: understandable terms today, a dependable offline policy during operation, and a usable exit path prepared before the last server turns off.