Licensing and the open-source release

From the white paper: section 4.8 sets out two license tiers and section 7.3 the lock-in risk; this page gives the tiers, the timetable, the self-hosting mechanics, and what a government keeps if it walks away.

The two-tier model. Civitas organizes its intellectual property in two tiers. Each tier names the license its assets will carry when they are released.

Tier 1 is the open-source core that Civitas will release: the credentialing stack, the issuer, verifier and wallet interfaces, the wallet connectivity APIs, and, as each is built, the goal-path orchestration engine and the Resource Center content platform. The recommended license is the Mozilla Public License 2.0 (MPL 2.0). It provides file-level copyleft: improvements to existing files must be shared back under the same license, while larger works that combine Civitas code with other software may keep their own. It permits commercial use and proprietary combination, and it is the approach taken by comparable digital public infrastructure projects, MOSIP among them. This remains a recommendation, not a decision already executed against a repository.

Tier 2 is open content that Civitas will also publish: the governance and compliance frameworks (institution onboarding processes, trust-registry governance tooling, consent and safeguarding policies), the Resource Center design patterns, content schemas and localization frameworks. These will be published under Creative Commons Attribution 4.0 (CC BY 4.0), the standard for open policy and educational content in this ecosystem.

What is applied today: nothing yet. No license has been applied to any Civitas repository. The open-source release of the full stack is scheduled for the first half of 2027. Until the release ships, the model on this page is a commitment, not a term a third party can rely on.

One constraint the Tier 1 choice imposes. A capability that depends on a proprietary third-party component cannot sit inside the open core. The biometric recovery route under research rests on patented technology, so if it proves out it can ship only as an optional add-on behind a vendor-neutral interface, with the recovery phrase and the encrypted backup remaining the primary path.

Self-hosting the trust layer. The gateway between a platform and the on-chain contracts runs as three services on the Civitas production platform: a registrar bridge that submits registrations and status changes, stores each institution's DID log and relays the log attestations the institution signs in its own wallet, an exporter that publishes registry state as a signed snapshot, and a verifier extension that consults the snapshot during verification In build: the services run in production against contracts on the Stellar test network, and they have been installed from scratch on the test network, with new contracts and new governance keys, from an integration guide that sits with their source, which is not yet public. They are built for independent deployment, including the fixes an installation needs when it does not sit behind the Civitas platform's own routing. On release, a ministry will be able to run its own instance, govern its own registry entries and take part in verification with no dependency on Civitas.

What a government keeps if it walks away. The test of lock-in is what survives the relationship ending. Once the release ships, a departing government keeps:

• the software, to deploy, inspect, modify and redistribute under the applicable license, with no further permission from Civitas;
• its trust-registry entries, held in the registry contracts rather than in a Civitas database (those contracts run on the Stellar test network today; deployment to the public network waits on the audit of the next release of the contract library they build on);
• the governance and content frameworks, reusable under CC BY 4.0 with attribution;
• its holders' credentials, which sit in their wallets and never pass through Civitas in the first place.

The remaining item is credential portability. Credentials issued today use AnonCreds over Hyperledger Indy, so a verifier outside the ecosystem needs compatible tooling to read them. That gap closes with the migration to open credential formats Research: no shipped code yet; the migration is a funded roadmap item, after which a Civitas-issued credential will be readable, with or without the Civitas platform, by standards-based verifiers that resolve the issuer's did:webvh keys, and by verifiers that trust issuers only through X.509 certificates once a certificate chain is added with the first partner that needs one.

Status, 2026-10-01: no license is applied to any repository, the Tier 1 license is a recommendation not yet applied, the three trust-layer services run on the Civitas platform against test-network contracts and have been installed from scratch on the test network from their integration guide, their source is not yet public, and the full open-source release is scheduled for the first half of 2027.