Selling software means deciding who may use it. A licensing system is the infrastructure that enforces those commercial rules on each installation, so the product does not depend on trust alone.

What a licensing system does

A licensing system is responsible for the following:

  • Confirming that a customer's license is valid right now.
  • Turning on the features that belong to the customer's plan.
  • Enforcing the term: a subscription that expires, or a permanent license.
  • Limiting how many devices or seats can use a license, and tracking which ones do.
  • Allowing the software to keep running when the internet is unavailable.
  • Revoking access when a license is cancelled, refunded or moved to another device.

Does your software need one?

Not every product does. A web app that already requires a user account can check that account on every visit. An app sold through an app store can rely on the store. A licensing system matters most for software that is installed and run by the customer: desktop programs, tools built into other products, on-premises business systems, and anything that must keep working away from the internet.

How validation works

Each time the software checks its license, the system works through the same steps:

  1. Identify the license and the device that is asking.
  2. Confirm the license is valid: not expired, not revoked, and issued for this app.
  3. Work out which features the license grants.
  4. Apply the device and seat limits.
  5. Grant or deny access, and record when the check happened.

The check can run against a server every time, or against a proof the device already holds. Online checks see changes at once. Offline checks depend on how long the proof is allowed to last, which is set by the license terms.

A license is more than a key

A license key is only one way to identify a customer. Systems also use user accounts, activations tied to a specific machine, organisation accounts that cover several people, and signed records that a device can verify without asking a server. Each choice changes how easy the software is to use and how hard it is to share without permission.

Binding a license to a device has a practical side. A customer who replaces a laptop needs to move the license, and a customer whose device is lost needs a way back in without a support ticket every time. Good systems treat a new device, a replacement and a recovery as separate operations, so each one can be approved and audited on its own.

Common licensing models

  • Perpetual: pay once, keep the version you bought.
  • Subscription: access lasts for a set term and renews.
  • Seat or device based: a fixed number of machines or people may use it.
  • Feature based: plans unlock different parts of the product.
  • Usage based: the price follows how much the software is used.
  • Floating or concurrent: a shared pool of seats, checked out while in use and returned afterwards.
  • Trial: time-limited access that lets a customer try the product before they buy.

Sekiwa is built around terms, device slots and plan features. Each plan sets how long a license lasts, how long it can run after it expires, how many devices it covers and which features it unlocks. Plans can also be marked as trials. Sekiwa does not currently offer floating seats, so a plan's device count is fixed per license.

Working offline without losing control

Many customers work where the internet is slow, costly or switched off for hours. A system that blocks the software whenever it cannot reach a server turns a network fault into a lost sale and an angry customer. A system that never checks at all cannot stop a cancelled license.

Sekiwa takes a middle path. A license is activated online, and the server issues a signed snapshot for that device. The app verifies the snapshot with a public key, so it works without a connection. The private signing key never leaves the server. Each plan sets an offline window, 7 days by default, after which the device must reconnect before it runs again. A revocation is applied the next time the device connects, so the offline window also limits how long a revoked license can keep working.

When the network fails

A network error and an invalid license are different events, and a licensing system must treat them differently. If the server cannot be reached, a valid license already on the device should keep working. If the server answers that the license is invalid, revoked or blocked, access should stop. Systems that treat every failure as a denial lock out paying customers during an outage. Systems that treat every failure as success let cancelled licenses run indefinitely.

Sekiwa separates the two. When a check cannot reach the server, the device verifies the cached signed license and keeps the last valid result. Only an authenticated answer from the server can clear it.

The offline window is a trade-off

Every offline licensing design balances two needs. Customers need to keep working when the connection is down. Developers need a revoked or cancelled license to stop within a reasonable time. The longer a device may run without reconnecting, the longer a revoked license can keep working on it. A short window gives tighter control and more interruptions for customers in poor-connectivity areas.

There is no single right value. It depends on the product and the customer. That is why the window should be a setting on the plan, not a fixed rule imposed on every product.

Build or buy

A licensing feature looks small at first: check a key, unlock a feature. It grows quickly. Offline use, device transfers, several license types, billing sync, reporting and migrations from older systems each add work that has nothing to do with the product itself. Many teams start by building it and later move to a dedicated system, usually after the cost has already been paid.

Musika: a licensing example from real shops

Musika is point-of-sale software for shops and small businesses in Zimbabwe. It runs as an Android app on the devices a shop uses to keep trading, so it has to keep working when the network does not.

Musika is licensed through Sekiwa. A shop activates its license while it is online. After that, the app checks the signed license on the device, so trading does not stop because the connection drops. The developer still controls the license from one place: which shops are licensed, which devices they use, and when a license is renewed or revoked.

Sekiwa grew out of this work. The reasons are described in the founder story.

Where to go next

If you build software that customers install, read the developer docs to see the SDK, or compare plans and pricing.

See how Sekiwa works →