For European proprietary publishers#

You publish proprietary software in Europe. You operate a SaaS, or you are starting an ambitious project that will not be open source. The question may have been put to you — by a client, a partner, a journalist, or by yourself: is your model compatible with the requirement of European technological sovereignty carried by the manifesto? This page answers. The manifesto does not ask you to open your code. It asks you, as it asks every provider, to make your chain readable — and, on the dimensions where the proprietary license is intrinsically weak, to demonstrate contractually what open source offers structurally.

The position of the device#

The manifesto does not push toward free software. Nor does it push toward proprietary. It pushes toward chain readability, whatever the model.

This distinction changes everything. The word “sovereign” has long served as a positioning marker: a product was presented as such on the sole grounds that its publisher was European, or that its code was free. The device refuses that shortcut. As thesis 3 of the manifesto puts it, “the license, open or closed, is a legal attribute of the software — not a guarantee of sovereignty”. Sovereignty is an attribute of the entire chain — capital, jurisdiction, hosting, continuity, dependencies, governance — not of the software alone.

Axis 4 of the manifesto writes it explicitly: “the Profile does not distinguish open source from proprietary: it distinguishes providers who make their chain readable from those who obscure it.” You are therefore invited to publish a Sovereignty Profile on the same footing as an open source publisher. Neither above, nor below. On one condition: that what open source offers by default, you formulate by contract.

Why the structural / contractual nuance changes everything#

When a client buys an open source solution published under a permissive or copyleft license, several guarantees come by construction:

• The source code is public — they can audit it, archive it, or have it audited.
• If the publisher disappears, the code remains usable — it can be forked, maintained by a community, or self-hosted.
• The use of the software does not depend, in the long term, on the survival of a single commercial entity.

These guarantees are structural: they flow from the model, not from a contractual effort. The open source publisher obtains them without doing anything special — its license carries them.

When a client buys a proprietary solution, these guarantees do not exist by default. If the publisher closes, the code disappears. If it unilaterally flips its license, its pricing, or its strategy, the client often has no fast operational recourse. The protection must be manufactured, added, negotiated — by contract. This is the proper work of the proprietary publisher who wants to exist in the sovereign ecosystem: to produce contractually what the free license produces structurally.

This is not an inferiority. It is a higher cost of entry, paid once, that in the long run distinguishes serious publishers from the others.

When transparency becomes a risk — the sectoral caveat#

The manifesto sets chain readability as principle — not the universal publication of the source code. The distinction is essential for certain sectors: defence, critical infrastructure, energy, health, finance, sensitive administrations. In these contexts, the open source publication of the code may itself constitute an active risk — not from security through obscurity (a chimera), but from an asymmetry of defensive and offensive capability in the AI era.

Agentic AI now allows an equipped attacker to silently scan millions of lines of source code, identify non-trivial flaws, and exploit them — without alerting, without contributing a patch, without responsible disclosure. It is the opposite of the Copy Fail (CVE-2026-31431) case where Theori/Xint responsibly disclosed a kernel flaw discovered through defensive AI; what makes Copy Fail instructive is precisely that it could have remained silent.

For the sectors cited, the classical calculation of “Linus’s law” — given enough eyeballs, all bugs are shallow — is partially inverted: the “eyes” now include AI agents in silent offensive mode, whose diligence exceeds that of human defenders equipped with equivalent tools but less economically motivated. Proprietary software paired with solid contractual mechanisms — tested reversibility first, targeted audit right next, escrow as a safety net — can, in these contexts, offer a better sovereign profile than an open source publication that would expose the attack surface without proportionate defensive counterpart.

This nuance does not disqualify open source in these sectors; it requires that the associated defensive posture — funding maintainers equipped with defensive AI, a bug bounty programme matching the new offensive capabilities, defensive AI audit — be commensurate with the asymmetry. The Profile device does not decide for the declarant: it makes visible the choice and the conditions of its sovereign equivalence.

The seven contractual mechanisms — reversibility first#

The device retains seven established mechanisms which, cumulated, demonstrate the equivalence that open source reaches by default. None alone is enough; serious proprietary publishers combine several.

But they are not equal. Reversibility is the inescapable priority — particularly for models where the client entrusts its workload to the provider (SaaS, and even more so PaaS). Without operationally tested reversibility, the six other mechanisms become theoretical:

• escrow gives you access to code you cannot run elsewhere;
• the notice period is only a delay before the inevitable;
• operational continuity assumes that a successor can operate what you yourself cannot take over;
• the audit right does not change the dependency;
• anti-acquisition statutes protect the capital future without ensuring the technical exit;
• release-on-trigger only releases usable code if the execution target remains available.

Reversibility is what makes the other mechanisms operable.

1. Standard reversibility clause — the inescapable condition#

Depending on the service model, reversibility takes two distinct operational forms.

SaaS — a clause for full data export in documented open formats, with migration scripts tested in real conditions and a contractual export deadline with a cap. The stake is data portability.

PaaS — packaging in standard OCI format, deployment manifests portable to diverse targets, detachable managed services with a documented and tested self-hosting procedure, periodic public demonstration of a successful migration. The privileged target is self-hosted via Docker Compose — accessible and sustainable without a heavy cluster to maintain. The stake is application workload portability, deeper than data alone. It is on PaaS that the cost of unprepared reversibility is heaviest: if it has not been designed from the outset, it may prove impossible after the fact.

→ pub-009 — Reversibility clause (SaaS) · pub-014 — Application portability (PaaS)

2. Software escrow with a trusted European third party#

The current source code is deposited with a specialised notary, a legal escrow agent, or a European foundation. A tripartite contract (publisher, escrow agent, clients) precisely defines the circumstances of release of the code to clients: opening of insolvency proceedings with liquidation, officially announced cessation, finalised acquisition by a non-EU entity. The periodic update of the deposit — typically quarterly — is what gives it its protective value.

→ pub-005 — Establish a software escrow

3. Public release commitment#

Failing or in addition to escrow, the publisher publishes an explicit commitment (release-on-trigger) to release its code under a free license under named triggering circumstances: bankruptcy, liquidation, definitive product discontinuation, non-EU acquisition. The commitment specifies the applicable license (for instance AGPL v3) and the public repository where the code will be published, as well as a documented deadline (typically 30 to 90 days after the event).

→ pub-005 — Establish a software escrow (release commitments included)

4. Minimum contractual notice period#

Before any discontinuation of support, unilateral flip, or substantial modification of the service, the publisher contractually commits to a minimum notice period — typically 6 to 12 months. This gives the client time to migrate, to re-contract, or to mobilise its escrow. A short or absent contractual notice empties all the other commitments in practice.

→ pub-010 — Minimum contractual notice period

5. Operational continuity arrangement#

In case of cessation, an arrangement is provided before it occurs: organised transfer of the client relationship to an identified successor, sector guarantee fund, or mutual takeover agreement among peers. The publisher does not merely promise an export — it prepares a continuous operating trajectory for the client, which does not depend on the goodwill of the day of liquidation.

→ pub-011 — Operational continuity

6. Anti-non-EU-acquisition statutory clauses#

For providers of strategic interest: shareholders’ agreement forbidding transfer to a non-European entity without approval, pre-emption rights for European investors, public golden share, specific share with blocking rights. Domain 6 of the Profile declares them explicitly. This mechanism is what distinguishes, in the long run, a sovereign publisher from a sovereign publisher waiting for an acquisition offer.

→ pub-012 — Anti-acquisition statutes

7. Source code audit right under non-disclosure agreement#

For clients whose contract justifies it — sensitive administrations, critical infrastructure, strong sovereign requirement — the publisher opens a source code audit right under non-disclosure agreement (NDA). It is not a publication, but a verification possible by independent eyes chosen by the client. It is the targeted contractual equivalent of what open source offers by default to all.

→ pub-013 — Source code audit right

A specific form for startups#

If you are starting a software project that will be sold as proprietary, you probably do not yet have an escrow, an anti-acquisition statutory clause, or a sectoral continuity fund — and that is normal. The question for you is not “do you have everything, right now?”, but “which commitments do you publicly assume today, and which will you take when scale allows?”

Here is what a startup can credibly assume from the seed stage, and what may figure in a first honest declaration:

• Reversibility by design. Design your formats and your architecture so that export is possible from the first client. It costs less at 5 clients than at 5,000.
• Choice of dependencies. Trace the jurisdiction of your strategic third-party components from the start. Prefer, at functional equivalence, bricks under European governance. Domain 1 of the Profile.
• Documented European hosting. Which datacentre, which effective jurisdiction, which status with regard to the CLOUD Act. Domain 4.
• Statutory intentions. You may not yet have negotiated your first funding round. Set down in writing — in honest domains 6 and 7 — what you will accept and what you will refuse: European pre-emption in the shareholders’ agreement, a possible public golden share, refusal of board control by a non-European investor.
• Assumed limits. Domain 7 (“commitments and assumed limits”) naturally accommodates “we cannot yet but here is the trajectory”. It is the opposite of a weakness — it is a signal of honesty.

The benefit is strategic: take a public position before having to negotiate under constraint with foreign investors, demanding clients, or sceptical journalists. A public declaration is worth more, at 18 months, than a private intention.

What you publish#

The Sovereignty Profile is a sovereignty.json file that you publish at the root of your domain — https://your-domain.eu/sovereignty.json. The format is public, the schema is versioned, no membership cost is owed.

The device:

• does not score your declaration;
• does not audit its content;
• does not assign a label;
• makes readable what you assume and what you leave blank.

You fill in the seven domains relevant to your case. A domain may be left empty (meaning: not declared at this stage) or marked not applicable with a brief reason — the two states are distinct. The web generator accompanies you; nothing is transmitted to a third-party server, the draft is saved in your browser.

On notification, you pass a light challenge (DNS TXT, HTTP file, or public git) that proves you control the domain. Once validated, your declaration appears in the public index, listed in reverse-chronological order of update — without ranking, without score, without hierarchy.

To go further#

• Manifesto — the fundamental nuance between license and sovereignty is set in thesis 3 and operationalised in axis 4. A condensed version exists: short manifesto (~5 min read); the full version is here: manifesto.
• Philosophy of the device — the long formalisation of the seven mechanisms, in the context of the four categories of providers and of public self-declaration: conditions of equivalence for proprietary.
• What a Profile looks like — annotated examples cover different typical cases: Profile examples.
• Assumed limits — what the device does not measure, does not guarantee, and the gap between the manifesto and the tool: assumed limits of the device.
• Frequently asked questions — FAQ.