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.

Licence epochs: each image keeps the licence of its version

BUSL-1.1 applies separately to each version of the Licensed Work (LICENSE: “This License applies separately for each version of the Licensed Work”). A published image carries the licence text of its own version and keeps it after LICENSE.canonical changes, so the image register cannot compare every row with today’s text.

licence-epochs.sha256 lists each canonical licence digest with the UTC time from which it governs new image publications. Each image in image-publications.sha256 is held to the epoch in force at its first observation in the register; later rows for the same image digest keep that epoch. tools/scripts/validate/check-image-licence-register.py enforces the following:

The first epoch, 2ff94c50…, starts at commit dbf987b29d (2026-08-23) and covers every licence-carrying row recorded before the licence revision; the two rows dated earlier carry the no-licence sentinel. The second epoch, 9febee768b22bdc8c688ea89da04673eb8fe7a8af2ba034581b9cf9498d6d35d (2026-10-27), was publicly distributed in source and on the website’s licence page, and no image register row carries it. The third, ebd869191b46c2be818695ec338dbd95a083330fe2ceddad8c05b821bb714e3a, adopts the final section 2 definitions; a version distributed under the second epoch keeps that text. A licence change is an owner- and counsel-approved act. To adopt one:

  1. Replace LICENSE.canonical and run check-licence-publications.sh --write.
  2. Copy LICENSE.canonical to licence-texts/<new sha256>.txt.
  3. Append <new sha256> <adoption time, UTC> source:<commit or sprint row> to licence-epochs.sha256. The adoption time must be later than every register row that carries the earlier text.

An image that is first recorded after an epoch opens counts as a publication of that epoch. An earlier-version image that was published but recorded only after the change therefore fails until a sprint row baselines it.

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. LRS-24 completed the product-document naming update. The full website mirror refresh is closed in archived SPRINT_20260916_004: staging was verified and the owner accepted the launched production promotion as the closure criterion. That receipt does not claim the queued promotion succeeded.

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.

Earlier versions: additional permission

From release v1.0.0-RC1-<YYYYMMDD> (date set at publication) the Additional Use Grant limits Placements instead of Environments and New Hash Scans. Each earlier version keeps the grant it shipped with. The additional permission for earlier versions lets their recipients use them under the Placement grant instead, as a whole. Its Annex A is an immutable copy of that grant with its SHA-256, so the permission never depends on whatever LICENSE.canonical says later. If the canonical text changes before the permission takes effect, Annex A and both digests are regenerated with it.

Historical distribution remains a separate question

The 2026-08-23 no-external-distribution assumption is not the current distribution record. The 2026-09-16 assessment found anonymously retrievable image publications without the Stella licence material; recipients are possible, but no retained per-pull record establishes whether anyone obtained a copy or what they received with it. See the historical evidence, per-release dispositions and component assessment.

Correcting a current website page or attaching a notice to a replacement does not establish the grant, communication or acceptance associated with an earlier copy. The historical assessment records uncertainty rather than declaring earlier copies public domain or declaring that every recipient lacked lawful use rights. Preserve the original immutable digests and their mapping to any corrected distribution.

The prospective recipient process can identify terms for future use without backdating acceptance or imposing retrospective fees. The current remediation plan records the approved v1.0.0 channel decision and the outstanding publication evidence. This documentation is not a claim that the corrected release has been published.