Licence

Crypt-in is not one licence. It is four, one per layer, and the split is deliberate.

Layer	Licence
SDK (Windows DLL + Linux CLI)	Apache License 2.0
App Personal (Windows client)	GNU GPL v3
Explorer (Windows file manager)	Proprietary — licence details at product launch, Q1 2027
Firmware (ESP32-S3)	Proprietary — closed source
Licence server (license.lake8.dev)	Proprietary — closed source

The Linux CLI is part of the SDK, not a separate product: same Apache 2.0 package, same repository, one licence.

The Python files in tools/ are an internal test harness used during development and red team sessions. They are not a distributable SDK today.

Q2 2027: the Python client ships as part of CryptinSDK, Apache 2.0, free on GitHub. If it is ready earlier, it ships earlier. See Python tools.

SDK dependencies

The Apache-2.0 promise made for CryptinSDK and the CLI only holds if the dependencies allow it. They do:

Dependency	Version	Licence
HidSharp	2.6.4	Apache-2.0
System.IO.Ports	9.0.0	MIT
.NET runtime pack	9.0.10	MIT

HidSharp is licensed Apache-2.0 (verified from source, not inferred). This is a prerequisite of the Apache-2.0 promise made for CryptinSDK and the CLI: a copyleft dependency in the USB HID layer would have forced the whole SDK to the same terms, and the permissive promise above could not have been made.

The full component list, per platform, is in the SBOM.

Why Apache 2.0 for the SDK?

The SDK is a thin transport layer that communicates with the dongle over USB HID. Apache 2.0 lets anyone integrate it freely, including in proprietary products, while protecting integrators from patent claims related to the HID protocol or the .crin format.

That patent grant is the reason Apache 2.0 was chosen over MIT. A permissive licence without an explicit patent clause leaves an integrator — in particular an LPN reseller shipping Crypt-in inside a commercial product — exposed to a claim that the licence text never addressed. Apache 2.0 grants the patent rights explicitly and terminates them for anyone who files a patent suit over the covered work.

Why GPL v3 for the app?

The app runs on your machine and handles your files. GPL v3 guarantees you can inspect and verify what it does.

GPL v3 rather than v2 also for a mechanical reason: Apache 2.0 is compatible with GPL v3, and not with GPL v2. The app links the SDK, so the app’s licence has to be the one that can absorb Apache-2.0 code. GPL v2 could not.

Why closed source for the firmware?

The firmware contains the JWT gate logic that enforces licensing on-chip. With its source, anyone could strip the PIN gate and the licence check and rebuild the product.

Secure Boot v2 prevents running unsigned firmware on production dongles — the eFuses are burned on every unit, developer beta included, with no exception. The protocol is public: see the HID protocol and the .crin format. Nothing about the firmware source is needed to write an independent client.

The SBOM lists the open-source components the firmware is built from. That is a component inventory published for CRA compliance — not a source release.

The licence server

The licence server is operated by lake8.dev, not distributed. No open-source obligations apply to it: nobody receives a copy, so none of the licences above is ever triggered, and neither the GPL nor Apache 2.0 extends to it.

It holds entitlement state and the attestation public key — never K_root, never K_identity, never a file key.

What this means in practice

• You can ship the SDK inside a closed-source commercial product. Apache 2.0 asks for attribution and a notice, not for your source.
• If you distribute a modified App Personal, GPL v3 requires you to publish your changes.
• You cannot rebuild the firmware, and a modified build would not boot on a Crypt-in dongle even if you could.

The business model in one sentence: the value is in the dongle, not in the software that talks to it.

The SDK is always free (Apache 2.0). Personal, Explorer and Vault are paid — you pay for the silicon, the licence server, and the guarantee that your files stay yours.

SDK Developer Support is available from the public launch (Q1 2027). It is not available during the developer beta: during the beta all participants have direct access at no charge. The plan buys a response time, never the code — the SDK itself never costs anything.

Where the source lives

github.com/lake8dev/cryptin-sdk — the repository opens at the developer beta, 30 September 2026. It does not exist yet, which is why the link is not clickable: it would return a 404.