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 Ops | LICENSE (repo root) |
| What I am allowed to do with the Stella Ops Router or Stella Ops Workflow packages | The licence each package carries: src/Router/LICENSE or src/Workflow/LICENSE, with its NOTICE; the Apache-2.0 packages carry the Apache-2.0 texts |
| How many Placements one Installation may manage free of charge, and what a Placement is | LEGAL_FAQ_QUOTA.md |
| Whether an earlier version can be used under the Placement grant instead of its own | busl/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 state | templates/placement-order-form.md |
| What support is free and what a paid support review covers | product-support-policy.md |
| Whether I can build and ship a plugin | LICENSE-ADDENDUM-COMMUNITY-PLUGIN-GRANT.md (repo root) |
| When THIS release converts to Apache-2.0 | LICENSE-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 downstream | NOTICE.md (repo root) |
| The verbatim text of a third-party license | third-party-licenses/ |
| Every dependency with version, SPDX id and compatibility verdict | THIRD-PARTY-DEPENDENCIES.md |
| Which NuGet packages are licensed under Apache-2.0, and what they carry | Apache-2.0 packages below |
| Which Router or Workflow package to install, and its licence | Router packages, Workflow packages |
| What a Router component NuGet package carries, and which third-party packages it brings in | Customer NuGet packages below, and the Router component catalogue |
| Whether a license I want to pull in is compatible with BUSL-1.1 | LICENSE-COMPATIBILITY.md |
| Where the vulnerability data we publish comes from and under what terms | third-party-licenses/DATA-NOTICES.md |
| How an order produces an attributable, retained Customer Agreement acceptance | customer-acceptance-procedure.md |
| What customer acceptance means and how to rehearse it before the first customer | customer-acceptance-rehearsal.md |
| What real evidence the first and later customer acceptances need, and the onboarding checklists | first-customer-acceptance-guidelines.md |
| What is known about historical publications and what remains uncertain | busl/historical-release-dispositions.md |
| How an existing recipient can obtain prospective terms without conceding the earlier copy’s position | existing-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.
| Artifact | Direction | Obligation it satisfies |
|---|---|---|
LICENSE | Outbound | BUSL-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.md | Outbound | A separate operative instrument that grants plugin authors supplemental permissions in addition to BUSL-1.1. It does not override BUSL-1.1. |
NOTICE.md | Inbound | Attribution 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/** | Inbound | MIT/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) | Outbound | The 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 inventories | Internal | Compatibility analysis, review threads and regulatory evidence are not customer acceptance or required distribution notices. |
| Issued Customer Agreement, identified Schedule 2 and acceptance package | Customer-facing | Exact 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. On 2026-11-06, again before any acceptance, the owner amended 1.0.0 in place a second time (amendment record): Schedule 3 (Component Schedule) holds the order terms of the Stella Ops Router and Stella Ops Workflow components, and §2 and §11.1 incorporate it. 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:
- Class A — Software. Code, grammars, schemas, models and images that are part of the product.
- Class B — Data. Upstream vulnerability data folded into the artifacts StellaOps produces. These artifacts are not BUSL-1.1; see
DATA-NOTICES.md. - Class C — Regulatory asset. Regulator-published evidence packages carried under the intake lane.
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 88fab6d314; 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.
LICENSE | Plugin grant | NOTICE.md | third-party-licenses/ | |
|---|---|---|---|---|
Release bundle (devops/release/bundle/) | yes | yes | yes | yes |
| Offline / air-gap kit | — | — | yes | yes |
runtime-assets image (/data/licenses/) | — | — | yes | yes |
Download site (build-site-tree.py) | yes | yes | — | — |
| Apache-2.0 NuGet packages (below) | the Apache-2.0 text instead | — | the package’s own NOTICE instead | none: no Apache-2.0 package embeds third-party material |
| Router component NuGet packages (contract, not published yet; below) | the package’s own licence instead | — | the package’s own notice instead | embedded material only: the gateway .NET tool carries its own third-party-licenses/; no library package embeds any |
Service images and the offline kit include assemblies of the Apache-2.0 packages (for example StellaOps.Canonical.Json), but do not stage their Apache-2.0 LICENSE and NOTICE yet; the gateway .NET tool does, under licences/Apache-2.0/.
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.
Apache-2.0 packages
StellaOps.Canonical.Json, StellaOps.Components.Licensing, StellaOps.Cryptography.Abstractions, StellaOps.Cryptography.DefaultProvider, StellaOps.DependencyInjection, StellaOps.Messaging, StellaOps.Messaging.Transport.InMemory, StellaOps.Messaging.Transport.Postgres, StellaOps.Messaging.Transport.Valkey, StellaOps.Microservice, StellaOps.Microservice.AspNetCore, StellaOps.Microservice.SourceGen, StellaOps.Plugin, StellaOps.Router.Common, StellaOps.Router.Transport.InMemory, StellaOps.Router.Transport.Messaging, StellaOps.Router.Transport.RabbitMq, StellaOps.Router.Transport.Tcp, StellaOps.Router.Transport.Tls and StellaOps.Router.Transport.Udp are licensed under the Apache License, Version 2.0. Each package carries the licence expression Apache-2.0, the unmodified Apache-2.0 text as LICENSE and a NOTICE (src/__Libraries/licences/Apache-2.0/), and none of the Suite LICENSE, the plugin grant or NOTICE.md. A source file of these packages that carries a licence header carries Copyright (c) 2026 Е-САЛЮШЪНС ЕООД (e-Solutions EOOD) followed by SPDX-License-Identifier: Apache-2.0. They depend only on each other and on third-party packages, which the consumer’s NuGet client restores under their own licences. The gateway .NET tool, which embeds some of them, carries the same LICENSE and NOTICE under licences/Apache-2.0/.
Customer NuGet packages (Router component)
Implementation status (2026-11-04): no Router component package has been packed or published, and no Router project sets
<StellaOpsNuGetRelease>. This section is the packaging contract; check a built package against it before relying on it.
The Router component NuGet packages are StellaOps.Router.Common, .Router.Gateway (with the YAML and JSON gateway configuration provider that was the separate .Router.Config project until 2026-11-04), .Router.Gateway.RateLimiting.Valkey (the Valkey store of the gateway’s environment rate limit), .Router.Gateway.Hosting, .Router.Gateway.Host, .Router.Gateway.LocalInMemoryHarness, .Microservice, .Microservice.AspNetCore, .Microservice.SourceGen, .Router.Transport.InMemory, .Router.Transport.Messaging, .Router.Transport.RabbitMq, .Router.Transport.Tcp, .Router.Transport.Tls, .Router.Transport.Udp, the server side of five of these transports in .Router.Transport.Messaging.Server, .Router.Transport.RabbitMq.Server, .Router.Transport.Tcp.Server, .Router.Transport.Tls.Server and .Router.Transport.Udp.Server, .Messaging, .Messaging.Transport.InMemory, .Messaging.Transport.Postgres, .Messaging.Transport.Valkey, .Messaging.RateLimiting and .Messaging.RateLimiting.InMemory, .Postgres and .Valkey, and the metapackage StellaOps.Router.Sdk, which holds no assembly and only names five of them. The Stella Ops integration projects StellaOps.Router.AspNet, StellaOps.Gateway.WebService, StellaOps.Messaging.Plugins and StellaOps.Router.Plugins (the signed transport folder loader) are not among them. A Router component .nupkg is a separate artifact class. When one of these packages is published, it follows these rules:
- Licence and notice. Each package carries the licence its project selects: the nuspec states it, and the matching licence and notice files are inside the package. The Apache-2.0 packages among them are listed above. No package carries the Suite
LICENSEor the plugin grant. A package that selects the Router licence carries the Router licence textsrc/Router/LICENSEas its licence file and the noticesrc/Router/NOTICE; the release path checks that both equal the tree’s files. - Third-party texts: only for what the package embeds. A package carries the licence text of third-party material it contains. No library package contains any: the sixteen projects scanned on 2026-11-02 (recorded in the catalogue) and the first-party projects they keep, and the twelve added to this list on 2026-11-04 (scan of their tracked files), hold only Stella-authored files. The gateway .NET tool (
StellaOps.Router.Gateway.Host, commandstellaops-router-gateway) is the exception: a tool package carries the assemblies it runs, so it embeds fourteen third-party packages and carries one licence text per package underthird-party-licenses/, listed with package, version and licence inthird-party-licenses/index.tsv(register rows). A Stella Ops assembly the tool embeds under another licence than the tool’s brings that licence’s files too, underlicences/<licence>/. A package does not copythird-party-licenses/wholesale: that directory states what the platform artifacts carry, and inside a package that carries none of those components it would misstate the package’s contents. - NuGet dependencies are not redistributed by the package. The nuspec names them; the customer’s NuGet client restores them from the customer’s feed, each under its own licence. The per-artifact catalogue lists every package a restore brings in, with exact version, declared licence and how it arrives (restored dependency, build-time only, shared framework). Embedding a dependency’s assemblies or native files in a Stella package instead would make Stella its distributor and needs that dependency’s licence text inside the package.
- Not the contract-package seam. This class is outbound to customers. It is not the internal
cross-service-client-sdkseam described under “First-party NuGet contract packages”, which the dependency gate recognises for Stella packages consumed inside this repository.
Customer NuGet packages (Workflow component)
The Stella Ops Workflow packages (Workflow packages) are a separate artifact class with the same rules as the Router packages above:
- Licence and notice. A package under the Workflow licence carries the Workflow licence text
src/Workflow/LICENSEas its licence file and the noticesrc/Workflow/NOTICE, and none of the SuiteLICENSE, the plugin grant orNOTICE.md; the release path checks that both equal the tree’s files. The shared foundation packages a Workflow host uses are Apache-2.0 packages. - Third-party texts: only for what the package embeds. No Workflow package embeds third-party material;
StellaOps.ElkSharpis Stella Ops code and contains no Eclipse Layout Kernel code (register). - NuGet dependencies are not redistributed by the package. The customer’s NuGet client restores them, each under its own licence; the Workflow component catalogue lists them.
Canonical documents
Core license files (repository root)
- Project license (BUSL-1.1 + Additional Use Grant):
LICENSE - Stella Ops Router licence (BUSL-1.1 + the Router Additional Use Grant) and its notice:
src/Router/LICENSE,src/Router/NOTICE - Stella Ops Workflow licence (BUSL-1.1 + the Workflow Additional Use Grant) and its notice:
src/Workflow/LICENSE,src/Workflow/NOTICE - Digests of the component licence texts: Component licence texts
- Additional permission for earlier versions (Placement grant as an alternative):
busl/additive-permission-v1.0.0-RC1-YYYYMMDD.md - Community Plugin Grant Addendum:
LICENSE-ADDENDUM-COMMUNITY-PLUGIN-GRANT.md - Third-party attribution notice:
NOTICE.md - Verbatim third-party license texts:
third-party-licenses/
Compliance & compatibility
- Full dependency inventory:
THIRD-PARTY-DEPENDENCIES.md - License compatibility guidance:
LICENSE-COMPATIBILITY.md - Additional Use Grant summary and the free usage limit (Placements):
LEGAL_FAQ_QUOTA.md - Compliance pack mapping:
compliance-pack-mapping.md - Cryptography compliance notes:
crypto-compliance-review.md
Plugin & distribution guidance
- Plugin developer FAQ:
PLUGIN_DEVELOPER_FAQ.md - SaaS and MSP licensing guidance:
SAAS_MSP_GUIDANCE.md - Compliance verification and telemetry policy (nothing in the product enforces licence terms):
ENFORCEMENT_TELEMETRY_POLICY.md - Compliance attestation process:
COMPLIANCE_ATTESTATION_FORM.md - Self-attestation form template:
templates/self-attestation-form.md - Placement capacity order template:
templates/placement-order-form.md
Regulatory posture (per-regime)
- eIDAS / QTSP posture (single-page narrative; reference-only-no-vendoring canonical model):
eidas-qtsp-posture.md - DORA / eIDAS / QTSP customer deployment flow (sales / customer success / customer-facing):
dora-eidas-customer-deployment-flow.md - CRA product classification:
cra-product-classification.md - CRA product-placement anchor:
cra-product-placement-anchor.md - End-of-life policy:
eol-policy.md - Product support policy:
product-support-policy.md - Regulatory asset intake process:
regulatory-asset-intake.md - Legacy capsule retention map:
legacy-capsule-retention-map.md
Decision records and counsel correspondence
- Index + lifecycle guide:
decisions/README.md - EXEC (PM binding decisions), REG (regulatory asset records), VENDOR-BRIEF (vendor-facing artifacts), and
lawyer-request*/lawyer-response*correspondence all live underdecisions/.
Operator-supplied attestation templates
- eIDAS operator agreement attestation skeleton (operator-side, not Stella-Ops-signed):
operator-attestations/eidas-operator-agreement-attestation.template.md