KDPika Licensing
Sign inStart freeUpgrade the application package without accidentally replacing its installation identity or weakening license verification.
What you will learn
- Use a complete source/runtime/API migration checklist.
- Reinstall the verified current source without invented version history.
- Handle rollback, uncertain operations and intentional uninstall safely.
Prerequisites
- Complete the Sandbox quickstart.
- Read signed responses, authentication and offline mode.
Current version and history boundary
The current Python release is kdpika-licensing 1.1.5, published on PyPI with MIT-licensed GitHub source. Other source SDK labels remain 1.0.0.
Python migration from studio-soline-license-sdk
- Stop processes using the old distribution and record your existing product, environment, application name and private state directory.
- Preserve installation identity and protected state. Do not delete either to upgrade.
- Use Python 3.11–3.14. If installed in this environment, remove the old studio-soline-license-sdk distribution before installing the new one.
- Install kdpika-licensing 1.1.5 and change imports from license_sdk to kdpika_licensing.
- Check your pinned verification-key ID matches the Ed25519 public-key hash. New validation rejects mismatched pins rather than silently accepting them.
- Test signed activation, validation, cache reload, offline deadlines and refusal paths before distributing your app.
python -m pip uninstall studio-soline-license-sdk
python -m pip install "kdpika-licensing==1.1.5"
python -m pip check
Run the uninstall only if the old distribution is installed in that environment. The deprecated license_sdk import remains a compatibility shim, not the recommended import. Do not keep two distributions owning that namespace. Review the versioned migration guide.
API v1 and SDK versions are independent. Download the actual source package and SHA-256 from the SDK overview. Keep a private application dependency lock and the current runtime package checksum. Do not replace the first-party package with an unverified registry name.
Migration review template
| Review item | Record before | Verify after |
|---|---|---|
| Package identity | Exact language/name/version/hash | Intended source, no unexpected import/namespace change |
| Runtime/dependencies | Compiler/runtime versions and dependency lock | New minimums actually work on the target |
| Public API | Constructor/method signatures, result fields and exceptions | Application builds and expected safe failures remain handled |
| Trust | Independently pinned public key/key_id | No untrusted replacement or disabled verification |
| Installation | Actual stable identity and namespace inputs | Same installation hash and no accidental new activation |
| Storage | Exact per-app location and vault/fallback category | Private permissions, readable expected state and atomic writes |
| Signed bytes | Current response/cache vectors | Complete payload authenticates without numeric/Unicode drift |
| Offline | Signed validation/grace/expiry/checkpoint behavior | Cache reload, network loss, rollback and explicit rejection tested |
| Features | Boolean/numeric type handling and validity guard | Invalid result cannot unlock any feature |
| Mutation recovery | Current activation/release state | No blind retry or seat/cumulative-count assumption |
| Packaging | Real target artifact/signing settings | Actual native packaged app passes the same flow |
Reinstall the current source safely
- Record the exact current package/dependency/runtime versions and your application configuration. Expected: a reproducible private manifest without keys/tokens/customer payloads in shared logs.
- Identify the exact private application state directory and stable namespace inputs. Expected: you know what must persist; no broad user-directory deletion command.
- Back up required state using your application's actual retention/security policy. Expected: protected backup access, not a token pasted into a support ticket.
- Download and verify the intended source ZIP checksum. Expected: exact current digest, otherwise stop.
- Restore dependencies in a separate clean application project. Expected: the documented import/build succeeds before changing an installed application.
- Run the full Sandbox lifecycle and published vectors. Expected: accepted signed decisions and safe refusals, with known release limitations visible.
- Package and run on the actual target OS. Expected: the final artifact—not just the source interpreter—passes activation/check/refusal/offline/release behavior.
- Update the deployed application without changing App ID/environment/origin/storage namespace accidentally. Expected: the existing installation hash persists and cumulative activation_count is not consumed unnecessarily.
- Monitor safe error/source/request-ID metadata. Expected: no raw license key, token, private path, stack trace or customer payload in logs.
This is a source package upgrade process, not authorization to modify platform billing, database state, API response shapes or SDK behavior.
Identity and cache compatibility
Changing origin, product, environment, application storage root or default application name can select another namespace and generate another installation ID. Preserve the correct explicit state location across updates. Deactivation releases a seat but does not reset cumulative activation_count. A reinstall that deletes identity may consume another activation even after release.
Do not copy one buyer's token/cache into another installation. Do not edit a signed payload to make a new client accept it. If a new release changes canonicalization or cache serialization, test actual raw server responses and restart/offline behavior before rollout. Fail closed on incompatible data and reconcile with the software provider.
Rollback and uncertain operations
Keep the old application artifact, exact dependency lock and required private state backup. A rollback is safe only when the earlier artifact can read the state format and preserve current trust/time semantics. Do not assume restoring a full machine snapshot is neutral for rollback checks or a server token already deactivated/revoked.
If activation or deactivation lost its response, reconcile server state before retrying. Do not delete local state to hide uncertainty. Removing a package does not release its server seat. Releasing a seat while online before intentionally removing an installation is different from a normal in-place application upgrade.
Uninstall deliberately
Use the language-specific package/reference removal command only inside the consuming application project. A direct PHP copied SDK directory is not a Composer dependency-removal action. Keep or remove the exact application state according to your application's privacy/retention policy; do not recursively delete a broad home or workspace directory.
Before removal, deactivate online if you intend to release the installation seat. Expected: confirmed release, no feature grant and identity preserved if the application policy retains it. If offline, show a simple reconnect/support path rather than pretending the server seat was released.
Future version change entry
For every future version, record the observed release/source commit and checksum, exact API/constructor changes, dependency/runtime requirements, data/trust migration steps, rollback limits, known defects and executed test evidence. If nothing changes, say exactly that with source evidence. Do not invent historic versions, a support deadline or a deprecation email/header mechanism absent from the product.
Expected result
Your integration authenticates signed state and handles failures without granting features. Installation identity, source version and test boundaries remain explicit.
Common mistakes
- Deleting identity/cache as a routine upgrade step.
- Assuming package removal releases a server seat.
- Rollback to an artifact that cannot read the current state/trust format.
Security notes
Keep developer keys on trusted backends, pin independent key trust, preserve HTTPS/signature verification and never equate token presence with permission. Local machine owners can patch software; a successful build or checksum is not an anti-tamper certification.
Troubleshooting
| Symptom | Cause | Action |
|---|---|---|
| New activation after upgrade | Namespace changed | Restore the intended origin/App ID/environment/state root |
| Signature failures after update | Changed byte/Unicode/number handling | Run exact vectors and raw response/cache tests |
| Uninstall left a seat | Package removal is not server deactivation | Reconnect and release deliberately or reconcile with the provider |
Next steps
Review the SDK downloads, test vectors and API errors for the exact selected client.