Premium edition

Two delivery channels: ionCube and signed source

At a glance

NextPDF Pro and Enterprise are delivered in two forms, and you can think of them as two channels for the same product:

ionCube-encoded — installable PHP whose source is encoded, run through the ionCube Loader at runtime.
Signed plaintext source — readable PHP source, cryptographically signed so you can verify it is genuine and unmodified.

Both channels carry the same licence and the same rights (the NextPDF Commercial License Agreement governs both, and access to readable source is never permission to copy or redistribute it). They exist because two kinds of customer have two different problems to solve, and we price each channel to match the trade-off it carries — not because one has more features than the other. This page explains the reasoning, so you can choose with open eyes. For the practical setup of the encoded build, see Set up the ionCube Loader.

Why protecting the source is a real problem in PHP

PHP is shipped and run as source. Unlike languages that compile to an opaque binary or to bytecode before they are distributed, a PHP package’s working source is the thing you install — the runtime reads it directly. That is one of PHP’s great strengths: it is transparent, easy to inspect, easy to patch, and a large part of why its open-source ecosystem is so vibrant.

It is also why a commercial PHP project has a harder protection problem than its counterparts elsewhere. The investment that goes into a deep, specialised engine — the years of standards work, the edge cases, the test suites — lives in source that, by default, travels in the clear. That investment is a trade secret: the practical know-how that funds continued development, and an asset the law recognises and protects. Protecting it is not about hiding from users; it is about keeping the work fundable.

This is also why source protection is simply easier in ecosystems that ship compiled or bytecode artifacts — Java is the common example: the distributed form is already a step removed from the working source, so a commercial vendor has less to guard. That has made it more straightforward to fund deep, specialised commercial tooling there, where a great deal of serious PHP work has instead relied on the goodwill of the open-source community. We do not think that is a law of nature. PHP deserves professional, actively-maintained, standards-grade tools too — and making the source defensible is what makes funding that work sustainable.

Open core, paid premium

NextPDF’s answer is open core with a paid premium. The engine you build on — nextpdf/core — is Apache-2.0 and stays open; you can read it, fork it, and ship it commercially. NextPDF Pro and Enterprise are the private editions, and the revenue from them is what pays for active maintenance, standards conformance, and the next features. That split is deliberate: it lets us serve teams that need professional, B2B-grade capabilities and stay friendly to individual developers, because we started as free-software-loving solo developers ourselves. The reasoning behind the open half is covered in Open core, no lock-in; this page is about how the paid half reaches you.

The ionCube channel — protection that keeps the price down

For most customers, the ionCube-encoded channel is the default. Encoding the source — a recognised way to raise the cost of tampering and misappropriation — lets us protect the premium code with far less overhead: less bespoke source-handling, less distribution and access administration, and a lighter legal and enforcement burden than guarding plaintext source at scale. Those savings are real, and we pass them on.

The trade-off is a modest runtime cost: the Loader decodes the encoded files as PHP runs, which adds some overhead. We reflect that trade-off in the price so you can evaluate it honestly rather than discover it later. In practice the overhead is usually small and often negligible in typical deployments — and effectively a non-issue on a host that already runs the ionCube Loader for other software. Performance-sensitive workloads should benchmark it against their own profile; for the great majority of deployments the encoded channel is simply the lower-cost option, which is the supply-and-demand match we want it to be. Setting up the Loader is a one-time step, documented in Set up the ionCube Loader.

The signed-source channel — for regulation, audit, and supply-chain assurance

Some customers cannot accept encoded code in their runtime. Organisations under strong regulation, or with strict supply-chain-security and audit requirements, need to read, review, and verify what they run — and they typically have the budget that those requirements imply. For them we offer the signed plaintext source channel: the same editions delivered as readable source, cryptographically signed so its origin and integrity can be verified.

That maps directly onto how modern supply-chain security expects software to be handled: source delivered in a digitally signed package, signatures verified before use, and reviewable source preferred over an opaque artifact for assurance and audit (NIST SP 800-204D). Here the code is not protected by encoding — it is protected by law and contract: it remains the confidential trade secret of PATEON, the company behind NextPDF, and what you may and may not do with it is set by the NextPDF Commercial License Agreement. Being able to read the source is never permission to copy, redistribute, or re-license it.

This channel costs more, and the reason is the inverse of the ionCube one: it removes the runtime overhead, but it shifts the protection burden back onto contract, trust, and administration — which is the cost we carry so that compliance-bound customers can meet their obligations.

Connectivity and licence enforcement

The channels also differ in how the licence is checked while your application runs, and for offline or air-gapped deployments this is usually the deciding factor.

The ionCube channel verifies its licence periodically online. A premium build delivered through the encoded channel checks in with the NextPDF licence service on a regular cadence — roughly a 7-day check that renews an approximately 14-day lease. As long as the deployment can reach the service within that window, everything runs normally. If it stays offline past the lease, the premium features pause and the engine falls back to the free Core — it does not stop, error, or crash — and they resume automatically once connectivity returns. That online lease is also what makes the licensed seat count enforceable and lets a revocation take effect within the lease window (about 14 days, plus a short grace). A check sends only a licence identifier and a salted fingerprint hash — never your document content, and never a raw fingerprint or an IP address.

The signed-source channel can run fully offline. Because its signed licence is a self-contained artefact the engine verifies locally, the signed-source channel needs no periodic connectivity and suits air-gapped deployments, bounded only by the licence’s own validity. Here the seat count is a contractual limit set by your agreement rather than something enforced at runtime, a revocation applies at the next online check or via a product update, and a purely offline deployment sends nothing at all.

Two separate clocks — don’t confuse them. The ionCube channel’s ~14-day lease is about connectivity — how long a deployment tolerates being offline. It is independent of the ~30-day grace that either channel gives after a subscription’s end date, during which premium features keep working while you renew before the engine falls back to Core. A lease lapse and a subscription expiry are different events on different timers.

Whichever channel you run, the failure mode is the same and always safe: NextPDF degrades to the free, open-source Core. It never bricks, never locks you out of software you have already deployed, and never stops mid-run.

Same rights, your choice

The two channels are not two products. They convey identical licence rights and the same software; what differs is how the source is protected, how the licence is checked at runtime, and what that costs:

	ionCube-encoded	Signed plaintext source
What you run	Encoded PHP, via the ionCube Loader	Readable, signed PHP source
How the source is protected	Encoding (a technological measure) plus the licence	The licence and trade-secret law (no encoding)
Best for	Most deployments; lowest cost	Regulated / audit / supply-chain-security needs
Runtime cost	A small Loader overhead (often negligible; benchmark if performance-sensitive)	None added by us
Online licence check	Periodic (~7-day check, ~14-day lease)	Optional; verifies locally and runs offline
Offline / air-gapped	Up to the lease window, then premium features pause to Core (auto-resume on reconnect)	Fully supported; no periodic connectivity
Seat count	Enforced through the online lease	Contractual (per your agreement); not runtime-enforced
Revocation takes effect	Within the lease window (~14 days + short grace)	At the next online check, or via a product update
Licence data sent	Licence ID + salted fingerprint hash only (never content, IP, or raw fingerprint)	Nothing when fully offline
Rights	Identical — see the EULA	Identical — see the EULA

Pricing reflects that protection-versus-runtime trade-off. For current prices and editions, see Buying and licensing and the pricing page linked from there.

Why we do it this way

We would rather the PHP ecosystem had more serious, well-funded, professionally maintained tools in it — and fewer projects that quietly burn out because there was no sustainable way to fund the depth they needed. Protecting the source is what lets us invest in that depth while keeping the core open and the encoded channel affordable.