Native SDK

Use Babel Licensing from Rust, Go, C++ or Python to validate signed licenses in your own applications. The native SDK exposes a C ABI, so the client application does not need a .NET runtime. Your publisher signs licenses with Babel Licensing; the client verifies them offline using your trusted public key.

Runtime packages

There is no separate Botan runtime dependency. Windows packages also include the .lib needed when linking MSVC/Rust applications; it is not deployed beside the executable. Each language guide includes Linux and Windows build/run commands, plus the macOS reference configuration. The library ABI uses the C calling convention on all platforms.

Run the examples

The public example repository  contains the client sources, signed demo files and an optional publisher-side .NET issuer. Download the platform SDK automatically with the setup command below, or supply the matching ZIP with --archive.

git clone https://github.com/babelfornet/native-licensing-examples.git
cd native-licensing-examples
python3 scripts/setup-sdk.py
./run.sh python

Each language guide explains the integration code, build configuration, runtime library loading and the steps to a running application:

The setup script downloads the pinned platform archive. To use a ZIP already downloaded, pass its absolute path with --archive. Both paths verify SHA-256 before installing it in .sdk. The SDK runtime is one platform library (.dylib, .so or .dll), with the required Botan modules linked statically. Users do not install or distribute a separate Botan or SQLite library. You need Python 3 for setup and the toolchain for the language you choose. C++ and Go/cgo require the platform C/C++ toolchain; Rust requires Cargo and a matching linker. Windows Go/cgo requires a MinGW-compatible C compiler. Offline examples need neither .NET nor a running Licensing Service. Activation and floating examples connect to your Licensing Service; a loopback protocol fixture is supplied for local integration tests.

See Native SDK examples for trial, perpetual and refusal scenarios.

Supported modes

For RSA, the trusted key is Base64 X.509 SubjectPublicKeyInfo DER, as returned by RSASignature.ExportKeys(true). For ECDSA, explicitly choose P-256 and use Babel’s Base32 public-point encoding. The legacy .NET default 112-bit curve is not supported by the native SDK.

Native signing is not part of this client. Keep the private signing key on your publisher machine or Licensing Service. The client receives only the signed file and the public key pinned by your application.

Validation order

Date parsing fails closed when a license date cannot be represented on the target platform. In the current Linux x64 build, the UTC clock range is approximately 1677–2262: an explicit XML date in year 9999 is rejected with a parse error. The macOS and Windows builds represent that date correctly. Test the dates emitted by your publisher against each target when integrating the SDK.

ABI version 2 separates parsing, authentication and runtime validity:

1. babel_license_load parses untrusted XML or compact text into an opaque handle.
2. babel_license_verify authenticates the signed payload with a mandatory trusted publisher key.
3. babel_license_validate checks license expiry and refuses unsupported restrictions.
4. babel_license_feature_enabled enables a feature only while the authenticated license and feature are valid.
5. babel_license_free releases the handle once the application has finished using it.

A successful load does not authorize anything. A failed verification clears the handle’s previous authentication state. Id, type and date getters expose diagnostic data; use the validation results for access decisions.

Read the public C header  for the full interface. It uses UTF-8, opaque handles, caller-owned buffers and integer status codes. Bindings must keep each handle alive during calls and release it exactly once.

Activation and floating examples

Every language guide includes --online activation and --online floating. Both use the same native session API and verify the returned signed license against your application’s publisher key. Activation additionally requires a signed hardware restriction matching the configured machine identity.

Floating examples acquire a seat, check its validity before protected work, renew it with two heartbeats, and release it. Heartbeat failure, expiration or release disables local use immediately. The SDK does not start a background heartbeat thread or provide an offline grace period. The console examples wait for the service-provided interval before each heartbeat, so a production interval can make the demonstration take several minutes.

The guides distinguish the supplied loopback protocol fixture from your actual Licensing Service. The fixture uses signed demo payloads and disposable demo credentials; it does not issue licenses and is not a production server.

To test all four languages against your installed service, create dedicated activation and floating licenses enabling Pro, signed with the same publisher key. Configure BABEL_SERVICE_URL, BABEL_PUBLISHER_KEY_FILE, BABEL_ALGORITHM and the two test keys in BABEL_ACTIVATION_USER_KEY and BABEL_FLOATING_USER_KEY. Then run python3 scripts/test-service-examples.py (python on Windows). The service test instructions  explain prerequisites and cleanup. This test uses real sessions but does not require an administrator API key or issue licenses.

Keep the service and client clocks synchronized. Choose a floating heartbeat interval that allows for clock skew, network latency and execution pauses; an already expired lease is rejected. Test licenses must not be in use by another test. The release examples were tested on all three platforms against a protected Babel Licensing Service, using both RSA and ECDSA publisher signatures.

Issue your own files

During evaluation or with a purchased Babel Licensing SDK, use your .NET publisher components to sign files for your application. The example repository includes a publisher-side issuer  that creates a 30-day trial and a perpetual license using a separate application key pair.

See Client components for the .NET SDK installation workflow. The license used to evaluate or purchase Babel Licensing is separate from the application licenses that your publisher issues to customers.

The sample clients accept a public-key file for experimentation. In your product, pin your public key in the application or trusted configuration. Never obtain the trust anchor from the license being verified. Use separate product keys when several products share feature names.

Maintenance and release identity

Absolute license expiry and maintenance are different checks. A maintenance end date governs access to updates; it does not expire a covered perpetual release.

The native maintenance helper implements Babel’s release/version policy and requires an authenticated license. It compares release days inclusively and does not read the current clock. Authenticating the actual running release remains a caller responsibility. The sample applications demonstrate signature, expiry and feature checks; they do not define your product’s release identity or update-entitlement policy.

For Babel’s own signed release certificate, the combined babel_license_check_babel_release operation authenticates and checks maintenance against the same version and release date. It does not authenticate releases of your application: you must protect or authenticate your own release metadata.

Legacy ECDSA licenses remain compatible with high-S and low-S signatures. The Native SDK rejects malformed scalar encodings and normalizes the scalar internally. Identify licenses by their authenticated publisher and signed license ID, never by a hash of the signature or file bytes.