Libertaria Venture License — Version 1.1

Identifier: LicenseRef-Libertaria-Venture-1.1

1. Purpose, parties and prerequisites

This License supplies the conditional commercial-combination permission expressly incorporated by Commonwealth 1.1 Section 5. It allows independent modules to remain closed while the Commonwealth core and changes to it remain open. It is not permission to close the core and is not a substitute for permission in third-party material.

Core means Core Material under Commonwealth 1.1, including all its modifications and covered integration code. Core Contributor means a rightsholder granting the Commonwealth 1.1 permission for its contribution. Distributor or You means the legal person or individual distributing or operating the Combined Product. Module Licensor means a rightsholder in an Independent Module. Recipient means a person lawfully receiving the Combined Product or using its network service. Combined Product means a combination covered by the Commonwealth 1.1 exception.

Independent Module means separately identified implementation in separate source files that contains no copyrightable portions of the Core. Mere interface declarations necessary for interoperability do not themselves constitute core implementation. Modified, translated, generated or relocated Core implementation remains Core. A common executable or static linking does not by itself disqualify a genuinely Independent Module. Modifications to covered integration files remain Core; an independent adapter without covered implementation may be an Independent Module.

Registry Operator means the identified legal person maintaining the public identity/key and attestation registry described in Section 5. Verification Implementation means the identified software that checks the Release Evidence under a published, versioned Verification Profile. Verification Profile means the documented encoding, cryptographic statements, verification procedure and trust assumptions meeting Section 4. A Release is the exact identified set of artifacts, their version, hashes and evidence package.

The exception is effective only for Core contributions whose rightsholders have granted it, including through Commonwealth 1.1. Commonwealth 1.0, GPL, AGPL or another license cannot be converted to this exception by attaching this file. You must identify and satisfy every separate dependency license. No license royalty to Core Contributors is required. Disclosed automated build, verification and registry service fees are permitted under Section 5. Political affiliation and an exclusive vendor relationship are not conditions of this License.

2. Grants and preserved recipient rights

2.1 Permission from the core contributors

Subject to Sections 3–6, each Core Contributor permits You to reproduce, combine and Distribute its Core contribution in the Combined Product and operate that product as a network service while keeping Independent Module source under separate, including proprietary, terms. Commonwealth 1.1 continues to govern the Core and its patent grants. Its whole-program reciprocity is waived only for qualifying Independent Modules, to the extent needed for this permission. Its core-source and installation requirements are not waived.

2.2 Rights in independent modules

A Module Licensor adopting this License for its module grants each lawful Recipient a non-exclusive, worldwide permission for the duration of its rights to install, execute and make operational backup copies of the module as part of the lawfully acquired product, within the objective device/user scope stated at acquisition. If no such scope is stated, this License imposes no device/user limit. An acquired scope cannot later be reduced unilaterally. It also grants the minimum copying and relinking rights needed to combine its supplied binary or object files with a Recipient’s lawful modified Core under Section 3.3. No public source release or general module redistribution permission follows from this grant.

A Module Licensor may instead provide a separate agreement that supplies at least those minimum rights. Additional price, service, device-count or module-support terms may be agreed for the module, but cannot restrict Core rights or those minimum rights in a copy already lawfully acquired. Access to a hosted service need not be perpetual and may use a subscription. No grant requires continuing provision of hosting or third-party services. The Distributor must secure the necessary rights; registry membership alone creates none.

If a Module Licensor adopts this Section 2.2 directly, it also grants a royalty-free patent permission limited to claims it can license that are necessarily infringed by those minimum uses of its module. If it uses a separate agreement, that agreement must provide an equivalent minimum patent permission. This grant does not cover third-party patents or unrelated combinations. It terminates for a Recipient that files a patent claim alleging infringement by that module; it does not terminate the Recipient’s rights in the Core or in unrelated software.

All mandatory legal rights, including applicable backup, observation, study, testing and interoperability decompilation rights, are preserved. No product term may forbid verification of the public Core and evidence. No mandatory human auditor, professional certification or disclosure of Independent Module source to a third party is imposed. Section 4 requires machine-verifiable Release Evidence, not access to proprietary source. Applicable court orders and other mandatory legal obligations remain intact.

3. Open core, notices and practical replacement

3.1 Core source is mandatory

Provide the exact Core Corresponding Source, including all Core changes, under Commonwealth 1.1 to recipients of executable distributions and to users of network deployments as required by Commonwealth Sections 3 and 4. A cryptographic commitment, escrow-only copy or confidential auditor access is not a substitute for this source offer. Do not require a confidentiality agreement for covered Core source.

Supply the Core build scripts, tool/dependency version requirements, interfaces and safe configuration templates. Core source rights are not conditioned on registry membership, verification fees or a valid subscription to a proprietary module. Preserve the applicable Commonwealth, Venture and third-party license texts and copyright/attribution notices.

3.2 Module boundary and information separation

Identify each closed module and its license. Neither labeling a file private nor generating it from a covered file defeats the Core-source requirement. No false module boundary may hide a change to the Core. Ordinary product assets or data remain subject to their own rights; a file implementing covered program logic cannot escape by being called data or a model.

Public manifests and required source must exclude personal user records, live credentials and signing secrets. Use hashes, parameter descriptions and safe templates where appropriate. Such exclusions do not excuse missing covered implementation, undeclared code inputs or a false provenance claim.

3.3 Effective replacement

For a product delivered to a Recipient, provide a technically usable way to rebuild and substitute the open Core while using the supplied module binary. For static links, provide relinkable object files or an equivalent mechanism with the limited permissions necessary for relinking. For dynamic components, a documented replaceable boundary may suffice. A source dump that cannot be used to replace a controlled Core is insufficient.

You need not reveal a production signing key. If a device You distribute blocks replacement, provide safe recipient-key enrollment or another actual installation path. You need not support or warrant modifications, disclose independent module source to the public, provide perpetual compatibility, or permit redistribution of the proprietary module. The limited relinking permission must cover a Recipient’s lawful modified Core, not only identical rebuilds. Hosting-only recipients obtain Core source; this License does not require handing over control of Your hosting infrastructure.

4. Cryptographically verifiable release evidence

4.1 Automatic verification, not expert approval

Before first Distribution or Network Deployment of a Release, produce the machine-readable Release Evidence in Annex A, sign the manifest with Your registered key, and verify it using a publicly specified Verification Implementation. Include the evidence and exact profile identifier with the product; provide an accessible version-specific evidence link for a hosted service. Recipients must be able to run the verification without a human approval, professional membership or discretionary certification decision.

No particular serialization format, file extension, package manager, operating system or vendor is required. Any present or future representation may be used if its Verification Profile and evidence satisfy every applicable requirement of this Section and Annex A. Evidence may comprise one manifest or multiple cryptographically bound objects, provided the same requirements are met. Format validity, a schema fingerprint or a product name alone does not prove that the build claims are true.

Equivalence means preserving each required property, not achieving an overall score. A stronger property cannot compensate for an absent or weaker required property. Publish a requirement-by-requirement mapping identifying the fields, proof mechanisms and checker behavior that satisfy Sections 4 and 5 and Annex A. The mapping explains compliance; it cannot create an exemption. External formats, standards, reference implementations and their later versions are not incorporated as changing license conditions. No implementation is certified as conforming merely by being mentioned in explanatory material.

Each changed executable, closed module, Core version or meaningful build input requires new Release Evidence. Evidence for one artifact cannot be reused to approve a different artifact. Machine-verifiable evidence may replace a human audit completely; no compulsory source inspection or independent human rebuild is required.

4.2 Verification profile and claims

The profile must publicly specify the statements checked, the exact input and output commitments, algorithms, canonical signed bytes, verification procedure, software version/digest, and trust assumptions. Provide the Verification Implementation in inspectable source form with permission to run, study, modify and redistribute that verification code, plus test vectors including altered artifacts, invalid signatures, mismatched build inputs, ambiguous encodings and changes to interpretation-critical fields. Do not require a fee or a proprietary tool merely to check the evidence. An equivalent conforming checker may be used; one vendor has no approval veto.

The evidence must bind the delivered executable to the declared Core source, Independent Module source commitments, dependency closure, toolchain, build instructions, relevant configuration and execution outputs. A profile must explain how its evidence establishes that the claimed build actually produced those outputs under its stated trust model. Suitable mechanisms can include verifiable computation proofs, attested build execution, or automated reproducible-build witnesses. No human identity is required for a verification process; attributable operators and cryptographic identities are required for trust-bearing signing services.

A signature on an arbitrary publisher assertion, a hash of an opaque binary, or a self-reported build_match=true field is not by itself sufficient to establish that build relationship. State which claims are directly checked, which rely on authenticated builders or hardware roots, and which remain Distributor declarations. Pin required trust roots; declare key custody, build isolation, input measurement and output-capture assumptions. A key or pass flag supplied in the same untrusted package is not its own trust anchor. A party may operate its own builder if the profile exposes this fact and supplies the claimed verifiable execution evidence; an additional company or paid expert is not a license condition. Registration authenticates an operator’s identity, not the truth of its build statements. For a Distributor-controlled builder, specify how the mechanism prevents or detects substitution of claimed inputs or outputs. Merely signing operator-controlled logs does not meet this requirement.

Evidence for closed modules may conceal their source while committing to it cryptographically. The mechanism must support verification of its declared relationship to the executable without requiring recipients or outside experts to inspect that source. The Core source offer remains mandatory. Machine verification does not establish ownership, license compatibility, absence of copied Core code, absence of malicious behavior or clinical suitability unless the precise property is separately and validly proved. You remain legally responsible for correct module classification and rights. A signed module-boundary declaration must accompany the technical evidence; cryptography does not turn an incorrect declaration into a lawful exception.

4.3 Acceptance and encoding rules

The checker must recompute digests for artifact bytes supplied to the Recipient, authenticate signers and their status, validate the build/input/ output binding under the profile, and check registry inclusion/checkpoints. For hosted artifacts not supplied to Recipients, identify the digests as attested commitments and verify their authenticated binding to build evidence; do not claim the Recipient independently recomputed those artifact digests. A built-artifact proof does not establish which artifact a live service runs. Any claimed deployment verification needs separately specified deployment evidence. This does not remove the operator’s duty to supply source matching the actual deployed Core. It must reject altered inputs, mismatched artifacts, invalid signatures, missing required evidence, and unknown or unsupported mandatory profile versions. A cached pass, absent network response or unrecognized proof type cannot silently become success. Retained authenticated records may support offline checking under the pinned profile; a profile must state how unavailable or stale key-status evidence is treated and must not misrepresent an unknown status as verified.

The profile must specify an unambiguous mapping between evidence bytes and their meaning, including schema identity/version, framing, signed extent, length bounds and rejection of malformed or conflicting representations. Define ordering, duplicate fields, numeric/text representations, byte order and extension handling wherever applicable. Authenticate all fields that can change interpretation, including the domain/context, profile and schema identity, version, artifact kind, security-relevant flags, complete claimed contents and referenced digests. Direct signature coverage or an authenticated commitment to those fields is required; a filename or an expected parser failure is not a substitute.

Referenced public evidence objects must be bound by authenticated cryptographic commitments and verified before their claims are accepted. All evidence objects required by the profile for recipient verification must be available for checking. This does not require disclosure of confidential inputs or delivery of hosted artifacts permitted to remain unavailable under this License; the profile must instead supply the required verification evidence for their committed relationships. A fetch location alone is not an integrity binding.

The profile may sign exact bytes or a precisely specified canonical form; it must not conflate different security-relevant meanings or discard required claims during canonicalization. Do not sign one representation and verify a lossy re-encoding as if it were the same bytes. Unknown critical extensions must fail verification; ignorable extensions must be explicitly defined as non-critical and cannot change the meaning of a verified required claim.

Where a profile uses a repeat-build comparison, only non-executable packaging metadata or outer signatures may be normalized under a precisely described rule. Code, executable sections, scripts, loaded program/model logic, dependencies and meaningful configuration may not be normalized away. Record original and compared digests. A profile using another verifiable execution mechanism must identify that mechanism rather than falsely claim that an independent repeat build took place.

The profile must define an acyclic evidence structure: an unsigned Release statement, its signature envelope, subsequent registry inclusion evidence, and a result referencing those preceding objects. No object may require its own digest or signature as an input. Artifact identity is distinct from evidence-package identity. Detaching evidence from an artifact does not permit omitting executable contents from that artifact’s commitment.

Record a machine-readable verification result with the checker version, profile digest, checked Release/evidence digests and individual outcomes. Recipients must be able to recompute the result; a signed pass report does not replace the underlying evidence. No result is conclusive against a court, and an ordinary signature is not thereby a qualified electronic signature.

4.4 Retention and continuity

Preserve the public evidence, verification specification/source and matching Core source while distributing or deploying the Release and for three years afterwards, or deliver complete copies as Commonwealth permits. Preserve Your own closed-module source, relevant build inputs and generation logs for that period so that the claimed release can be investigated and its evidence regenerated. This is a retention duty, not a routine public or third-party source-disclosure duty. Encrypted archives are permitted; maintain access and recovery arrangements appropriate to the retention duty.

A new vulnerability does not alone prove that prior provenance was false. Known false evidence, undeclared executable inputs, compromised relevant trust roots or an incorrect module boundary require correction and the response in Section 6. Pin the profile identifier, version and digest for each Release. A changed profile requires a new immutable version and compliance mapping. Preserve the prior evidence; any supplemental evidence must identify what it supplements. A later profile or reference implementation cannot retroactively add to, remove or weaken the license conditions for an existing Release. This does not excuse the compromise response already required by this License or permit an outdated profile to misrepresent a current result.

5. Registry rules, identities and key continuity

Use a registry with a published, versioned charter identifying its legal operator, contact, registration criteria, key-recovery process, evidence retention, fees if any, incident handling, appeal process and continuity arrangements. The charter must implement this Section; it cannot amend Commonwealth or Venture. Preserve the charter version/hash applying to an accepted Release. Later charter amendments govern new enrollment or Releases only when expressly accepted; they cannot retroactively change rights in earlier lawful copies.

Registration records must identify the Distributor as a legal person or individual and bind it to a signing key, algorithm, identifier, validity interval and recorded key changes. Personal home addresses and identity documents need not be public; the operator must verify and retain suitable identity evidence under applicable data-protection law. Public records must provide a legally usable identity and service contact. An unverified alias alone is insufficient. Trust-bearing builder and witness identities and signing keys must likewise be verifiable and included in the records where the profile relies on them. These may be automated services; a human expert registry is not required.

The registry must publish signed, append-only or tamper-evident records of enrollment, Release attestations, key events and incident decisions, with exportable copies and independently checkable history commitments. A timestamp is evidence to be evaluated, not an infallible proof of time. A publicly retrievable checkpoint outside the Distributor’s control is required for each Release before it is first offered. Registry keys and independent checkpoints must not be controlled solely by the Distributor.

Registration criteria must be objective and published. No permission under this License depends on political belief, nationality, business model or exclusive use of a vendor. A registry may charge disclosed reasonable service fees; it cannot charge for the Core license or source rights. An existing conforming registry may be used; no particular named registry is appointed by this License.

A routine key rotation or expiry does not invalidate a signature made while the key was valid. On compromise, publish the affected key, known interval, evidence and affected Releases; a newly enrolled key cannot silently rewrite history. A registry outage creates no permission for new unregistered Releases, but does not by itself revoke a previously compliant Release supported by preserved signed records. Before the next Release, migrate records to a conforming registry if necessary, with linked continuity proof.

6. Noncompliance, urgent action and recipients

A material failure of Sections 3–5 removes qualification for the exception for the affected Release. You must stop new Distribution and, where the failure affects a network deployment, the noncompliant deployment until qualification is restored or another lawful permission applies. You may continue separate lawful use of the open Core. This License never compels involuntary public disclosure of independently owned module source as the only remedy; stopping the noncompliant combination is an alternative.

Registry suspension records an operational trust decision, not a judicial determination or a retroactive cancellation of all licenses. An ordinary adverse decision must identify the evidence, affected Release and clause, provide notice to the designated contact and a 30-day opportunity to cure or contest the finding. For credible key compromise, false provenance or an immediate integrity threat, an operator may immediately mark the affected Release/key as suspended, with reasons and notice within two working days. It must offer review by a competent decision-maker not involved in the initial decision, normally within 30 days of a reasoned challenge. Nothing prevents legally required action or access to court, including urgent relief. An operator cannot immunize itself from applicable law through this License.

Correction requires complete compliant evidence and restoration or replacement of the affected registry record, without deleting the historical incident. Core copyright grant termination and reinstatement follow Commonwealth 1.1 Section 6, not a registry’s unilateral rewrite. An operator’s unexplained or nonconforming refusal cannot itself extinguish rights where substantive compliance is independently established; a different conforming registry may be used. A claim alone does not prove a breach.

Lawful recipients retain the Core rights and minimum module rights already granted, despite upstream default, registry outage or later suspension. No term authorizes remote disabling, erasure, extraction of personal data or revocation of a Recipient’s lawful copy merely on a registry decision. Remedies for infringement, fraud or a genuinely unsafe product remain available under applicable law. Module patent termination has the limited scope stated in Section 2.2.

7. Warranty, liability, law and versions

To the extent permitted by applicable law, Core Contributors and Module Licensors provide material as is, without express or implied warranties of merchantability, fitness, title, accuracy, security or non-infringement, and exclude liability for direct or indirect loss, lost profits, data loss and interruption arising from that material. Nothing excludes non-excludable liability, including intentional misconduct or deliberate recklessness where applicable, or mandatory consumer rights. A build-service or registry operator’s separately agreed service obligations are not disclaimed on its behalf. Extra commercial warranties bind their provider only.

Dutch law applies, subject to mandatory law, including consumer protections. The competent courts in Amsterdam, the Netherlands have exclusive jurisdiction insofar as a valid forum agreement can be made for the dispute. Mandatory jurisdiction rules prevail, and interim relief elsewhere remains available where procedural law allows. Statutory backup, study, testing, interoperability and other non-waivable rights remain intact.

An invalid term is severable only where the remainder can lawfully stand. No summary, registry charter, later version or unilateral policy alters these terms for an existing Release. Version 1.1 applies only through an express grant by the relevant rightsholders; it does not alter prior grants. This English text is operative unless the relevant grantor expressly adopts another language. Courts retain their powers and evidence assessment.

Annex A — Mandatory release-evidence content

This Annex is part of Venture 1.1. It and Sections 4 and 5 establish the fixed minimum evidence requirements for this version, independent of representation. Supply machine-readable evidence plus a human-readable index and the Section 4.1 compliance mapping. Fields may have different names or be distributed among authenticated objects; all required content and verification properties must be preserved. The evidence includes:

1. Profile/schema identifier, version and digest; Release identity; creation time; Distributor identity/contact; registry charter version/hash.
2. Each delivered executable artifact, purpose, byte size and digest; for a container, its manifest digest and referenced executable layers.
3. Exact Core source tree/archive digests, version and retrieval location; modification notices; applicable Core licenses and exception permissions.
4. Each Independent Module’s identity, source commitment, binary digest, declared boundary, Module Licensor, recipient-rights notice and dependencies.
5. Complete build/input dependency closure with versions, digests and licenses; toolchain and environment measurements; build commands and meaningful configuration; commitments to fetched, generated and confidential inputs.
6. Core rebuild/replacement instructions; verification specification/source location and digest; evidence-retention period and continuity arrangements.
7. Execution proofs, authenticated automated build receipts or witness evidence required by the profile; declared trust roots, key custody and isolation assumptions; precise comparison/normalization rules where applicable.
8. Distributor signature; all trust-bearing key identifiers, algorithms and status records; registry inclusion proof/checkpoint and independent anchor.
9. Recomputable machine verification result and a signed Distributor statement that the Core source and independent-module classification are complete and accurate. Clearly identify declarations that are not proved by the execution evidence. No third-party human signature is mandatory.

Use BLAKE3 with a 256-bit output, SHA-256, or a publicly specified cryptographic hash with at least equivalent collision resistance. Use Ed25519, ECDSA P-256, RSA-PSS with at least 3072-bit keys, or a publicly specified signature scheme of at least equivalent security. Specify exact parameters and signed bytes. Encryption alone, a non-cryptographic checksum or an unauthenticated digest is not a signature. If an algorithm is materially compromised, new Releases require an adequate replacement; preserve original evidence and document migration rather than silently substituting earlier digests.

No patient record, customer dataset, private key or credential belongs in public evidence. Hashing low-entropy personal data does not anonymize it.