Who owns what, answered one question at a time
Six questions a buyer's counsel asks, each with its own heading so none of them can be skipped. Two registers are used throughout and they are labelled: a FACT is a statement about how the system is built and is true whatever a contract says; a TERM is a commercial commitment and binds only once it is in your agreement.
Two registers, and why they are separated
A vendor page that blends architecture with contract reads as though the architecture guarantees the contract. It does not, in either direction.
| Register | What it means | How far it binds |
|---|---|---|
| FACT | A statement about how the system is built and deployed | True of the architecture whatever the agreement says. Checkable against the engineering pages |
| TERM | A commercial commitment | Our starting position; binds when it is written into your agreement. Same labelling as every number on the service levels page |
| Unsettled | Neither — a question with no answer yet | Named on this page as unsettled rather than answered optimistically. There are two, and both are below |
1 — Who owns the source?
TERM, and the honest answer is that it depends on the licence tier. The licensing page has said so since before this section existed: source inclusion is settled in the conversation because it changes both the price and what you are able to do afterwards. Any page telling you the source is simply handed over is describing a tier rather than a rule.
FACT, and unconditional at every tier: the Terraform modules that build the estate, the reference pipeline configuration and the operational runbooks are delivered to you. That is what makes the deployment reproducible without us — you can stand the estate up again, in a new region or on new hardware, from the definitions you hold.
Unsettled, and going to the owner of this business rather than onto this page: whether a licence is perpetual or term-limited, what happens to your right to run the platform after a term ends, whether source escrow is offered, and precisely what a source-inclusive tier covers. Those are commercial decisions nobody has recorded anywhere, and inventing them here would be exactly the failure this site is built to avoid.
2 — Who owns the infrastructure?
FACT: you do, and there is no arrangement in which you do not. The platform is deployed onto hardware you bought or into a cloud account in your name. There is no shared tenancy, no vendor-operated region, and no instance billed through us.
FACT: because the estate is declared in Terraform, what it consists of is readable rather than discoverable. The difference matters at exactly one moment — when somebody who did not build it has to change it — and that moment always arrives.
TERM: who operates the estate day to day is the engagement, and it is separable from who owns it. You can own the infrastructure and have us run it, own it and run it yourself, or move between the two without changing platforms. The first is a managed agreement, the second is a licence, and the boundary between them is written into whichever you sign.
3 — Who owns the subscriber data?
FACT: you do, and more usefully, you hold it. The subscriber records, the payment references, the entitlements and the viewing history are rows in a database on your estate. There is no copy in a system we operate, which means there is nothing to request, nothing to export and nothing to delete on your behalf.
FACT: the same is true of the money. The merchant account at the payment gateway is registered to you and settlement goes to it directly; the platform names a price and records an outcome and is never in the funds path. There is no revenue share because there is no mechanism in the billing service to take one with.
TERM: our access to your production data during an engagement is scoped to what the work needs, written down, and revocable by you — the credentials are issued on your estate, so revoking them is your action and not a request to us.
The practical test of this, and it is the one worth applying to any vendor: if you stopped paying them tomorrow, could they switch off your access to your own subscribers? Here the question does not resolve, because the database was never theirs to switch off.
4 — Who owns the encryption keys?
FACT: the keys are generated and held on your estate, in the vault deployed with it, and they are injected into services at run time rather than committed to a repository or baked into an image. Content encrypted under them is decryptable by you without reference to us.
The narrower truth, and it goes here rather than in a footnote: the vault is deployed and running, and some services still read a secrets file on the estate, with the vault as the migration target. Both locations are inside your perimeter, which is what the ownership question turns on — but the control is partial today and describing it as complete would be a claim this site does not make.
FACT: there is no licence server anywhere in the platform, which has a consequence worth stating on an ownership page specifically. Under licensed DRM, a third party issues the licences that let your viewers decrypt your content, and that third party is a dependency on the playback path. Here there is no such party — which is also why studio-grade DRM is not available, and the trade is stated on both sides.
5 — Who owns the published applications?
FACT: the store listings are published under your own developer accounts, in your legal entity's name. That is how the live Android listing is published today rather than a policy we intend to adopt, and it is the reason the store accounts appear as a client-side dependency on the delivery timeline: only you can open them.
What follows from the account rather than from a promise: the listing, the reviews, the ratings, the install base and the ability to ship an update on a day you choose. An operator who does not hold the developer account holds none of those, whatever the agreement says about branding.
TERM: application source follows the same licence tier as the rest of the platform. The published binary and the store presence are yours either way — those follow the account, not the licence.
FACT, and it is the point of the whole section: if this relationship ended tomorrow, your application would remain in the store, under your account, with its install base intact. There is no version of leaving that begins with asking a vendor to transfer your audience to you.
6 — What happens the day the relationship ends?
FACT: the service keeps running. The estate is on your infrastructure, the database and the keys are inside your perimeter, the applications are in your store accounts, and the Terraform that built all of it is in your repositories. Nothing is switched off by us, because there is nothing in the delivery path that we operate.
FACT: what stops is us. Support, engineering and platform releases end with the agreement. The platform you are running on the last day is the platform you keep running on the day after, and it stops receiving new versions and security patches unless something replaces that.
That is the honest weakness on this page and it belongs next to the strength: a running system with nobody maintaining it is a decaying system. The mitigations are ordinary and worth naming — an operations capability of your own, a licence tier that keeps you receiving releases, or another party you hand the runbooks to. What makes any of them possible is that the estate is declared rather than assembled.
TERM: the wind-down itself — notice period, transition assistance, what a final handover includes — is written into the agreement rather than described here. What this page commits to is the shape: there is no data extraction project, because the data never left; and no migration, because there is nothing to migrate off.
Have your counsel read this page first
It is written to be argued with. Where a term is not settled it says so rather than implying an answer, and those are the clauses worth raising before anything else.