Licensing

The project uses an open-core model with two licences, each chosen to match what the code does.

The split

Layer	Repository	Licence	What it covers
Regulatory core	dpp-core	Apache-2.0	Domain types, schemas, validation rules, sector plugins, compliance calculators, crypto primitives, digital-link resolution
Operational platform	dpp-engine	BSL-1.1	Managed hosting, observability, deployment automation, operational tooling

The rule is simple: if the code exists because an EU regulation changed, it lives in dpp-core under Apache-2.0. If it exists because of how the system is deployed or operated, it lives in dpp-engine under BSL-1.1. See the Core Concepts page for the full architectural rationale.

BSL-1.1 — what it permits

The Business Source Licence 1.1 is a source-available licence that converts to Apache-2.0 after a defined change date. For dpp-engine, it permits:

• Any non-production use — evaluation, testing, integration work, local development.
• Production self-hosting — deploying dpp-engine on your own infrastructure to issue, sign, store, and serve DPPs for your own organisation’s products and compliance, at no charge. This is the self-host grant.
• Contribution and modification — you may fork and modify the source.

It restricts:

• Competing managed-SaaS deployment — you may not offer dpp-engine as a commercial managed service to third parties while the BSL-1.1 term is active. This restriction lifts when the change date arrives and the licence converts to Apache-2.0.

Change date

Each dpp-engine release ships with a specific change date in its licence header — four years after that release’s date. After the change date, that release converts to Apache-2.0 permanently. The LICENSE file is authoritative; this page is a summary.

Dependency licences

dpp-engine builds on dpp-core (Apache-2.0) and a tree of open-source Rust crates.

This page deliberately does not reproduce a table of those licences. A restated licence list is a claim that goes stale silently: the licence lives in the dependency’s own metadata, changes on the dependency’s schedule rather than ours, and a copy here would keep asserting the old terms long after they changed. That is not hypothetical — a previous version of this page carried a licence for one component that had been wrong since 2024.

The authoritative answer for any given build is the build itself. cargo license or cargo deny over the workspace enumerates every crate and its licence from the resolved dependency graph, and Cargo.lock is committed, so the result is reproducible for any tagged release. Anyone evaluating the engine for licence compatibility should run it against the version they intend to deploy rather than trust a list written against some earlier one.

Read next

Core Concepts — the architectural principle behind the licence split. Self-Hosting — deploying dpp-engine on your own infrastructure. What Odal can and cannot see — why the core is designed so that regulatory capability is never gated.