How licensing works

Offline verification, what a key records, and what maintenance actually covers.

A LumasPDF licence is a signed blob of data. Your application hands it to the engine, the engine checks the signature with a public key compiled into it, and that is the whole protocol.

There is no server to contact, no account to register, and no state held anywhere but in the key itself. An air-gapped build works. A build running while our website is down works. Nothing can go wrong at your run time because of something happening at our end.

What a key records

Edition: Which capability groups are enabled.
Features: The optional extras your edition is allowed to buy, if you bought them.
Package: Which download the key is for. The engine refuses to run on a platform that package does not ship binaries for.
Seats: How many developers are covered. Recorded, never counted.
Build window: Which engine builds are covered.

The build window, precisely

This is the part that is most often assumed rather than read.

The window in your key is compared against the date the engine binary you are running was BUILT. It is never compared against the current date, and the engine does not read the system clock as part of licence checking at all.

Two consequences follow. Software you have shipped keeps working indefinitely, because the build it contains does not change its build date. And a build cut after your window is not covered -- not because anything switched off, but because you have not bought that build.

The changelog prints the build stamp of every release for exactly this reason: it is the number the comparison is made against, so it is the number that tells you whether a release is inside what you bought.