License Activation Policy — Version 2.0 — Effective 2026-07-19
In plain language: a genuinely new device activates online once and permanently consumes one seat. Kelavon uses an immutable, salted device-binding anchor to recognise qualifying re-activation of the same machine. Raw hardware identifiers are sent over TLS only during activation and are not intentionally stored or logged. After activation, verification is local and the App works offline without periodic phone-home or remote revocation.
1. Meaning and timing
Activation is the online validation performed before commercial use on a device. A new activation anchor permanently consumes one purchased seat. A qualifying re-activation against an existing immutable anchor does not consume another seat. Internet access is required for the activation request only.
2. Activation request and raw identifiers
The request may include the license key, purchase email where required, App version, fingerprint-format version, random installation ID, and normalized raw board, disk, and CPU identifiers. These values are transmitted over TLS. Raw hardware values are used in memory to compare existing anchors and generate salted hashes, then discarded; they are not intentionally persisted or logged. Activation does not send task names, workbook contents, attachments, or other Customer Data.
3. Binding modes
Where at least one valid hardware component is available, the activation uses hardware binding. If no valid hardware component can be collected, it uses a weaker installation-ID binding. A reserved manual mode may be used only through separately implemented support procedures. The fallback is not represented as equivalent security.
4. Immutable salted activation anchor
For each new activation, Kelavon generates a unique random salt and stores separately salted cryptographic hashes of the original component values, together with binding metadata. The salt and original hashes are written once and never updated — this is enforced at the database level, not just in application code. Later observed hashes may be stored separately for support visibility, but are never used as the identity anchor. Hashing reduces exposure; it is not described as anonymous or categorically irreversible.
5. Permanent seat capacity
The Kelavon Task Manager — Single license includes 1 seat, Kelavon Task Manager — Team 5 includes 5, Kelavon Task Manager — Team 10 includes 10, and each Kelavon Task Manager — 5 Additional Devices pack adds 5 seats (repeatable). Product configuration and checkout are authoritative if an offer changes. A genuinely new activation is refused when no capacity remains. There is no self-service deactivation, release, or automatic transfer of a permanently consumed seat.
6. Same-device matching
For a hardware anchor with three original components, the service treats the request as the same device when at least two of those original component types are present and match. A two-component anchor requires both original components. A one-component anchor requires its single original component and is marked degraded/low-confidence. Incoming component types that were not in the original anchor are ignored. If multiple anchors remain equally qualified after deterministic ranking, the request is not assigned arbitrarily and is referred for support review.
7. Repairs, re-imaging, and replacement
The three-component design is intended to tolerate one changed or temporarily unavailable component — such as a repair or re-image — but this is not a guarantee for every machine or Windows environment. Replacement of the whole computer, replacement of multiple relevant components, or loss of an installation-ID fallback may require a new activation and permanently consume another seat.
8. Installation-ID fallback
If no valid hardware component is collectible, the service creates an installation-ID-bound anchor rather than an empty hardware anchor. Exact installation-ID matching is then required. This fallback is weaker because copying a complete application profile or virtual-machine image may also copy the installation ID — a documented limitation, not a hidden one.
9. Offline verification states
At launch, the App locally verifies the signed entitlement and classifies the device as VERIFIED, WRONG_MACHINE, or INCONCLUSIVE. For a three-component entitlement, two readable matching components are sufficient. A two-component entitlement requires both, and a one-component entitlement requires its only component. A one-component observation cannot verify an entitlement originally bound to two or three components. Installation-ID mode requires an exact local match.
10. Inconclusive verification and grace period
If too few required components are readable, the App retries collection once. If verification remains inconclusive, normal use continues with a non-blocking notice and local diagnostic timestamps. After 30 days of persistent inconclusive results without a successful verification, the App continues to retry and remains usable, but shows a prominent support notice and privacy-safe support code. There is no hard technical lockout. This deliberate design favours legitimate offline customers and accepts that a determined local attacker may bypass client-side controls.
11. No phone-home or remote revocation
After activation, the App does not periodically contact Kelavon to validate the license or report normal usage. Kelavon therefore cannot remotely disable, erase, lock, or revoke an existing offline entitlement. A refund, termination, or server-side block affects future activation rights but does not push a kill command to the device.
12. Activation availability window
Kelavon commits to make initial activation available for 90 days from the purchase date. After that period, activation may remain available on a best-effort basis but is not guaranteed, particularly if the licensing service has been discontinued. A late activation is not automatically rejected solely because 90 days have passed; the clause limits the service-availability commitment rather than creating a technical expiry.
13. Refunds, disputes, and invalid payments
A refunded, charged-back, fraudulent, or invalid transaction may cause the key to be blocked from future activations and expansion capacity to be removed. Existing offline installations ordinarily cannot be retroactively revoked. The technical ability to continue opening the App does not create a legal right to use refunded or terminated Software.
14. Trial activation
The seven-day trial is started inside the App and does not require an email form. It is device-gated: starting a trial contacts the licensing service once and processes the same categories of device-binding identifiers as a paid activation (stored only as per-anchor salted hashes) — see the Privacy Policy §10. A repeated trial request from the same machine returns the existing trial window rather than a fresh one. Trial controls may not be circumvented or repeatedly reset.
15. Security, privacy, and retention
Kelavon may validate request format, apply per-IP, per-email, and degraded-activation rate limits, atomically enforce capacity, and log privacy-minimised outcomes. Raw hardware identifiers are excluded from database records, logs, tracing, analytics, support codes, and error messages. Activation anchors, observations, installation-ID hashes, and security logs are processed and retained as stated in the Privacy Policy. Device binding resists casual sharing but cannot guarantee prevention of complete VM/profile cloning, disk-image duplication, local-state manipulation, or executable patching.
16. Support and contact
Activation and license-recovery help is available through /license-help, /support, or support@kelavon.com. /license-help is view-only and does not release seats. Never send a full card number, password, private key, raw hardware identifier, or unnecessary regulated data. Supplier address: Mattackerstrasse 9, 8052 Zürich, Switzerland.