Legal and Licensing

This folder centralizes the legal and compliance references for Stella Ops Suite.

Which file do I need?

I want to know…Read
What I am allowed to do with Stella OpsLICENSE (repo root)
How many Placements one Installation may manage free of charge, and what a Placement isLEGAL_FAQ_QUOTA.md
Whether an earlier version can be used under the Placement grant instead of its ownbusl/additive-permission-v1.0.0-RC1-YYYYMMDD.md(Annex A carries the exact grant text and its SHA-256)
What an order for more than 20 Placements must statetemplates/placement-order-form.md
What support is free and what a paid support review coversproduct-support-policy.md
Whether I can build and ship a pluginLICENSE-ADDENDUM-COMMUNITY-PLUGIN-GRANT.md (repo root)
When THIS release converts to Apache-2.0LICENSE-CHANGE-DATE.txt in the release bundle, and the licence: block of release-manifest.yaml
Whose code is inside the product, and the attributions I must carry downstreamNOTICE.md (repo root)
The verbatim text of a third-party licensethird-party-licenses/
Every dependency with version, SPDX id and compatibility verdictTHIRD-PARTY-DEPENDENCIES.md
Whether a license I want to pull in is compatible with BUSL-1.1LICENSE-COMPATIBILITY.md
Where the vulnerability data we publish comes from and under what termsthird-party-licenses/DATA-NOTICES.md
How an order produces an attributable, retained Customer Agreement acceptancecustomer-acceptance-procedure.md
What customer acceptance means and how to rehearse it before the first customercustomer-acceptance-rehearsal.md
What real evidence the first and later customer acceptances need, and the onboarding checklistsfirst-customer-acceptance-guidelines.md
What is known about historical publications and what remains uncertainbusl/historical-release-dispositions.md
How an existing recipient can obtain prospective terms without conceding the earlier copy’s positionexisting-recipient-regularisation.md

Why these are separate files

They are not five views of one thing. Each satisfies a different obligation, and that is what decides where it lives and which artifact it travels with.

ArtifactDirectionObligation it satisfies
LICENSEOutboundBUSL-1.1 verbatim + the Additional Use Grant in its Parameters block. BUSL is reproduced unmodified; only the Parameters are ours.
LICENSE-ADDENDUM-COMMUNITY-PLUGIN-GRANT.mdOutboundA separate operative instrument that overrides BUSL for plugin authors. It cannot be folded into LICENSE without editing BUSL’s body, which would stop it being BUSL-1.1.
NOTICE.mdInboundAttribution we owe upstream — chiefly Apache-2.0 §4(d), which requires the notice content to be carried in the distribution, plus MIT/BSD attribution.
third-party-licenses/**InboundMIT/BSD/Apache require the license text itself to be included in redistributions. A link is not inclusion — and for an air-gap customer it is nothing at all.
LICENSE-CHANGE-DATE.txt (release bundle)OutboundThe Change Date computed for that specific version, so a recipient holding one copy can read off when it converts rather than deriving it from a mechanism. Generated per release by devops/release/bundle/tools/write-manifest.py; its bytes are checksummed into release-manifest.yaml, which the release signature covers.
Legal review records and inventoriesInternalCompatibility analysis, review threads and regulatory evidence are not customer acceptance or required distribution notices.
Issued Customer Agreement, identified Schedule 2 and acceptance packageCustomer-facingExact issued texts are retained in the release bundle and delivered through the acceptance procedure. These have canonical sources under docs/legal/.

The practical boundary is ships with the artifact vs stays in the repo — not “root vs docs”. The issued contractual package ships from canonical sources here; internal reviews do not become part of that package merely by sharing the directory.

Nothing here may be replaced by a redirect. Turning NOTICE.md or the license texts into pointers would fail the obligation they exist for, and would fail it hardest for exactly the offline / air-gap customers the product targets.

First-party ownership and chain of title

The owner confirmed on 2026-08-23 that e-Solutions EOOD owns the Stella Ops code, documentation, and product name; the canonical outbound licence therefore names that entity as Licensor. The supporting publication controls and legal identity are documented in busl/README.md. The narrower contributor-history check 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: the entire reachable git history carries exactly one author identity (master, 518 commits; the 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). Settlement receipt: q16-settlement-record.md.

Commercial instrument status

Ruled (Q-16, owner 2026-08-25): the full Customer Agreement is the instrument, drafted now — governing law, disputes, liability, withdrawal, merchant-of-record, confidentiality, and support-data terms in one versioned, affirmatively accepted agreement, with the eIDAS Operator Addendum content (eidas-operator-terms.md) as a schedule. No interim standalone addendum is produced. The agreement is ISSUED: CUSTOMER_AGREEMENT.md1.0.0, adopted for release by the manufacturer of record on 2026-09-16 (adoption record, SPRINT_20260825_016 LRS-3). On 2026-09-26, before any acceptance, the owner amended 1.0.0 in place (amendment record): §3a (Third-Party Data) states that vulnerability and advisory data delivered with or obtained by the product is not part of the Licensed Work, stays under its sources’ terms as stated in third-party-licenses/DATA-NOTICES.md, and that a customer who redistributes it outside its organisation carries the attribution duties. It carries counsel’s eleven-section minimum content, the verbatim Operator Material schedule, the operator terms as Schedule 2 identified by version and digest, and a versioned acceptance record. Release rests on the owner’s ADOPTED decision: both counsel rounds are ASSESSED, no named legal professional reviewed the operative text, and a signed opinion is not a precondition to forming a B2B agreement — see decisions/README.md for what those labels mean.

Issued is not accepted, and two consequences follow. Issuance alone establishes no customer’s acceptance. Support must not request customer logs or evidence without a separately documented confidentiality/data-protection basis (§8.2) — that constraint is keyed to acceptance, not to the instrument’s existence. And Q-17’s prohibition stands on its own terms: what Q-17 forbade was claiming that a “Stella Ops Commercial Licence/EULA” exists, and no such instrument exists now either — the instrument is the Customer Agreement. The website’s phantom claim was excised on 2026-07-28 (www Mission 1) and must not be re-added. What changes is that public surfaces may now name the Customer Agreement; restoring that wording across the docs LRS-5 swept is filed as LRS-24 (completed in archived sprint 016). The full www mirror refresh is closed in archived SPRINT_20260916_004: staging was verified and the owner accepted the launched production promotion as completion while it waits for a CI slot. No production HTTP verification is implied by that owner-accepted closure. The acceptance procedure implements the order-to-retained-record gates. Publication of a procedure is not evidence that a customer accepted.

First-party NuGet contract packages

docs/legal/THIRD-PARTY-DEPENDENCIES.md inventories code obtained from other authors. It must not acquire a row merely because StellaOps-authored source is consumed through a NuGet package boundary instead of a ProjectReference.

The dependency-license gate recognizes that boundary narrowly. A central pin is first-party only when its exact id and version match a committed devops/offline/nuget/contract-packages/manifests/*.manifest.json entry, that entry maps to an existing committed src/**/*.csproj, the named committed .nupkg exists in the offline mirror, and the package’s own nuspec repeats the same id/version with BUSL-1.1. The package manifest must classify the artifact as cross-service-client-sdk; the architecture pack separately verifies its digest, source freshness, and closed-graph purity. A StellaOps.* name alone, an unattested local project, a missing source/package/manifest, or mismatched package metadata does not bypass third-party registration.

Third-party license texts: three distribution classes

third-party-licenses/ is copied wholesale into the offline kit (devops/offline/kit/build_offline_kit.py) and into a shipped image (devops/runtime-assets/Dockerfile.runtime-assets). So its contents are a statement to the customer about what they received. Each text is filed under one class saying which artifact it travels with — see third-party-licenses/README.md:

A fourth category exists but is not in that directory: components vendored for development/test only, which ship nowhere. Their license text is kept beside the vendored tree (e.g. tools/conformance/oci-distribution-spec/LICENSE) precisely because the shipped directory would carry it into customer artifacts. ShippedLicenceDirectoryConformanceTests enforces the classification.

Which artifact carries which file

Packaging-source contract, verified 2026-09-16. This table does not attest the contents of an already published archive or image. A dash means this notice-focused table makes no assertion. Verified against product commit 36424c1ff5; re-check with rg -n 'LICENSE|NOTICE|third-party' devops/release/bundle/tools/stage-config.py devops/offline/kit/build_offline_kit.py devops/runtime-assets/Dockerfile.runtime-assets devops/release/site/build-site-tree.py.

LICENSEPlugin grantNOTICE.mdthird-party-licenses/
Release bundle (devops/release/bundle/)yesyesyesyes
Offline / air-gap kit——yesyes
runtime-assets image (/data/licenses/)——yesyes
Download site (build-site-tree.py)yesyes——

The earlier three gaps are historical findings in SPRINT_20260820_003. Current stage-config.py includes NOTICE.md in ROOT_FILES and the licence directory in ROOT_DIRS; build_offline_kit.py’s copy_third_party_licenses() stages both notice and texts. Published historical images have their separate component assessment: corrected source packaging does not establish that older distributed bytes contained the same materials.

Canonical documents

Core license files (repository root)

Compliance & compatibility

Plugin & distribution guidance

Regulatory posture (per-regime)

Decision records and counsel correspondence

Operator-supplied attestation templates