The canonical Stella Ops licence

LICENSE.canonical in this directory is the single source of the licence Stella Ops grants. Every published copy is generated from it and must be byte-identical to it. Do not hand-edit any of the copies.

This is the licence we grant. It is not AGENTS.md §2.6, which governs the third-party licences we consume — that is tools/scripts/validate/check-dependency-licenses.sh and docs/legal/LICENSE-COMPATIBILITY.md. Different authority, different failure mode.

Why one source

On 2026-08-23 counsel reviewed the two published copies of our own licence and found they were not the same licence (reply §4–§5). Measured in-tree before that review was acted on, not relayed from it:

parameterrepo LICENSE (as shipped)www.stella-ops.org/LICENSE
Licensorstella-ops.org — a domain, which cannot hold or grant rightsa Bulgarian legal entity
Additional Use Grantfree production use, subject to five conditionsevaluation, development and testing only
Change Date2030-01-20, fixedfour years per version
Change Licenseabsent entirelyApache-2.0
Terms bodypresent, in fullabsent — a link to mariadb.com

So one product was published under two materially different licences; the copy that shipped with the software named a domain as Licensor and never said what the BUSL grant converts to; and the copy on the website was a parameter block plus a hyperlink to a third party, for a product whose customers are air-gapped by design and cannot reach it.

Three hand-maintained copies is what produced that. There is now one.

The publications

publicationpathgenerated
repositoryLICENSEyes
release bundledevops/release/bundle/LICENSEyes
websiteLICENSE in the www.stella-ops.org repositoryyes

devops/release/site/build-site-tree.py uploads the bundle’s copy to the release site unchanged, so the download page is a copy of a generated publication rather than a fourth thing to maintain.

publications.sha256 records the digest of every publication, including the website one. It is how a checkout that cannot see the website repository still states what that copy is required to be. It is generated — never hand-edit it, and never regenerate it to silence a finding.

Regenerating

# writes all three publications + both digest pins from LICENSE.canonical
bash tools/scripts/validate/check-licence-publications.sh --write

# verifies; exits non-zero on any mismatch
bash tools/scripts/validate/check-licence-publications.sh

# proves the detectors can still go red
bash tools/scripts/validate/check-licence-publications.sh --self-test

The website copy is written when that repository is checked out beside this one, or at STELLAOPS_WEBSITE_ROOT. It is enforced on its own side by scripts/test-licence-canonical.cjs there, wired into its build-and-deploy lane.

Line endings are LF, pinned by .gitattributes in both repositories. This is load-bearing, not cosmetic: the website repository had no .gitattributes at all until 2026-08-23, so with core.autocrlf=true its copy was CRLF while the product copy was LF, and cross-repository byte-identity was unreachable.

The settled parameters

Owner-settled 2026-08-23, recorded in SPRINT_20260823_002 LIC-C1:

The owner also confirmed on 2026-08-23 that e-Solutions EOOD owns the Stella Ops code, documentation, and product name. That settles the ownership identity used by the canonical licence. The separate factual question — whether any external contributor participated without an effective assignment — is also settled: the owner confirmed on 2026-08-25 (Q-18) that no externally contributed code was accepted without a written assignment or other authority allowing the EOOD to license it. Supporting census, same date: git shortlog -sne HEAD shows exactly one author identity (master, 518 commits); the reachable history was evidently squashed, so the census supports but does not alone prove the answer — the owner’s confirmation covers pre-squash and vendored material. The chain-of-title condition before first external distribution is met.

Commercial-instrument representation (Q-17, ruled 2026-08-25: remove-until-instrument-exists). The instrument now exists: CUSTOMER_AGREEMENT.md 1.0.0 was issued 2026-09-16 (SPRINT_20260825_016 LRS-3), so the ruling’s condition is met and public surfaces may name the Customer Agreement. The phantom claim is still prohibited, and the distinction is the whole point of the ruling: Q-17 forbade stating that a “Stella Ops Commercial Licence/EULA” exists, and no instrument by that name exists now either. The website’s phantom claim was excised 2026-07-28 and must not be re-added under any version. Conditional licensing-policy wording (“use beyond the Additional Use Grant requires a commercial arrangement with e-Solutions EOOD”) remains truthful and stays. Restoring the deferred wording across the docs LRS-5 swept is LRS-24; the www mirror is LRS-11’s.

The BUSL-1.1 body below the parameter block is MariaDB’s text, carried verbatim. The covenants forbid modifying it, so the generator preserves those bytes untouched and only ever composes the parameter block above them.

What is NOT resolved here

Counsel warned that “do not assume that publication of a corrected website page retroactively changes their grant” and “do not narrow rights already granted under A without affirmative acceptance.” Both premises concern existing recipients holding a defective copy. The owner ruled on 2026-08-23 that no such recipients exist — the product is not yet distributed to an external audience — so the corrective-notice obligation does not arise and the canonical text simply stands as the truth from the start. Reopen the corrective-notice and affirmative-acceptance analysis only if evidence shows that a defective copy reached an external recipient before the canonical text.