The rights vocabulary

Every Work on the platform carries its rights as structured terms, not as a scanned agreement a person has to read. This page is the reference for that structure: the exact words a Contract uses to say where a Work may be sold, how it may be embodied, what may be done with it, by whom, and until when. If you write or review licensing terms, this is your dictionary.

The point of turning contract prose into a fixed vocabulary is that the platform can then answer questions about it — automatically, the same way every time, everywhere the content travels. "May this book be sold as an audiobook in Germany?" and "May an AI assistant train on this?" stop being questions someone has to look up in a PDF and become checks the platform performs at the moment of use. That is only possible if the terms are written in a language a machine can evaluate, which is what this page defines.

Two things anchor everything below. First, rights attach to the Work — the intellectual property — never to individual documents, chapters, or products. A contract governs one or more Works; the resolved rights are held once on each Work and projected onto every Resource under it, then revalidated at the point of use. Second, when several terms or several contracts speak to the same situation, prohibition wins. A grant is permission, but any prohibition that touches the same territory, manifestation, language, channel, and usage overrides it. Those two rules recur in every section.

The vocabulary has five families of term — territorial, manifestation, usage, handling, and duration — plus the merge rules that combine them when a Work is governed by more than one contract. The rest of this page takes each in turn.

flowchart TD
    C["Contract<br/>(the agreement)"] --> T["Territorial rights<br/>where"]
    C --> M["Manifestation rights<br/>how it is embodied"]
    C --> U["Usage terms<br/>what may be done"]
    C --> H["Handling terms<br/>obligations on every use"]
    C --> D["Duration<br/>until when"]
    T --> W["Work<br/>(rights held once here)"]
    M --> W
    U --> W
    H --> W
    D --> W
    W --> R["Resource<br/>(rights projected, revalidated at use)"]

Territorial rights

A territorial grant says where a Work may be used. The unit is the country: territories are named by their ISO 3166-1 alpha-2 code (GB, US, DE, JP), and a grant lists the codes it covers together with a verdict — PERMITTED, PROHIBITED, or CONDITIONAL.

Most trade agreements are worldwide with a handful of exceptions, and the vocabulary has an idiomatic way to write that. You do not list every country on Earth minus a few. Instead you pair a broad permit with a narrower prohibition, and let prohibition wins do the subtraction: a worldwide PERMITTED grant plus a PROHIBITED grant for the excluded countries resolves to "everywhere except those". A worldwide grant may also carry excluded_territories directly as a shorthand for the same carve-out.

Grants may also be scoped by language — "the exclusive right to publish in English throughout the world" is the classic author-contract wording. An optional list of languages narrows a territorial grant to content in those languages; omitted, the grant covers all languages. Language coverage is hierarchical in the same way territory is not: a grant for en also covers en-GB and en-US, but a grant for en-US covers only that variant.

[
  { "worldwide": true, "status": "PERMITTED" },
  { "territory_codes": ["CN"], "status": "PROHIBITED" }
]

[
  {
    "territory_sets": [{ "set": "LATIN_AMERICA" }],
    "languages": ["es"],
    "status": "PERMITTED"
  }
]

Territory sets — and why they are pinned

Hand-listing the 27 EU member codes on every contract is brittle: the list changes as memberships change, and every contract ends up encoding it slightly differently. Instead, the platform maintains a small set of named territory sets — you write EU and the platform expands it to the concrete country codes for you.

The sets are platform-maintained reference data. A tenant cannot define its own set — a house-specific schedule, such as a publisher's own "Commonwealth market" list, is hand-listed as codes.

The single most important thing to understand about territory sets is that expansion is pinned at the moment the term is written. When you author a grant with { "set": "EU" }, the platform looks up what "EU" means right now, resolves it to the concrete list of country codes, and stores that frozen list on the contract. From then on the contract is evaluated against those pinned codes, never against a live lookup.

A renewal or any other change that does not touch a territory term carries its pins forward unchanged. Re-authoring the term is what re-expands its sets against the current registry. And territory sets are accepted everywhere territorial narrowing appears — territorial grants, per-manifestation narrowing, and royalty rate rules — always with the same pinning behaviour.

Manifestation rights

A manifestation grant says how a Work may be embodied and sold — as a print book, an ebook, an audiobook, and so on. To follow it, it helps to know the three rungs the platform uses for "what we sell": the Work is the IP the contract governs; an Expression realises it in a medium and language (a text edition, an audiobook narration, a French translation); and a Manifestation is one Expression made concrete as a sellable SKU. Grants live at the top of that chain.

A grant names a manifestation class, optionally narrowed to a form. Crucially, a grant never names an individual product or a product type. "PRINT permitted" covers every print embodiment the Work ever produces; you do not — and cannot — grant rights over a specific paperback SKU or over a "Course" or "Certification". Product types are a commercial layer built on top of manifestations, and a grant that names one has leaked a layer (see what is deliberately not here).

Coverage is hierarchical. A class grant automatically covers every form within it — grant PRINT and you have granted both paperback and hardback. Narrow to a form only when the contract draws that line: a PRINT/PAPERBACK grant covers paperbacks and says nothing about hardbacks. Forms exist precisely because real contracts and royalty schedules split on them — hardback and paperback routinely carry different rates, and splitting the two between publishers is a classic deal. Everything below the form — trim size, binding, ebook file format, DRM — is product configuration, not a rights axis. DRM in particular is a condition, not a form (see usage conditions).

A manifestation grant may be narrowed by territory (with the same territory-set pinning as above), by language, and — for the open classes ONLINE and SCORM_PACKAGE, which can embody any medium — by medium. It may also carry a structured quantity (a print run is a COPIES limit) and structured conditions (such as a DRM requirement).

{
  "manifestation_type": "PRINT",
  "form": "PAPERBACK",
  "status": "PERMITTED",
  "territory_codes": ["GB"],
  "exclusivity": "EXCLUSIVE",
  "quantity": { "max": 10000, "unit": "COPIES" }
}

What is deliberately not here

• INTERACTIVE is a medium, not a class. An interactive Expression is delivered through ONLINE (or packaged as SCORM_PACKAGE); which media a grant covers is scoping, never its own class.
• COURSE and CERTIFICATION are product types, not manifestation classes (Product types). Building a course from a Work is a derivation authorised by a DERIVE usage term, and the result is a new Work with its own rights. A grant that names a product type has leaked a layer.

Usage terms

A usage term says what a consumer may do with the content. This is the richest part of the vocabulary, and the part that carries the platform's headline AI story. There are sixteen usage types, and each term gives one of them a verdict — PERMITTED, PROHIBITED, or CONDITIONAL — optionally narrowed by a set of qualifiers.

The channel-partner verbs deserve a note, because they are easy to confuse. DISTRIBUTE is copies passing onward to someone who then holds them (a retail sale is DISTRIBUTE with a commercial purpose — there is deliberately no SELL type). MAKE_AVAILABLE is a partner hosting the content for its own users without handing copies over (a subscription platform). MANUFACTURE is the physical act of producing copies, as distinct from an end consumer's PRINT. And ACCESS is what the end consumer does once content has been made available — the other side of MAKE_AVAILABLE.

The qualifier set

Any usage term can be narrowed along these axes. An omitted qualifier means "any" — the term applies to everything on that axis.

user_types (the who) and purpose (the why) are separate axes and never overlap. A "no commercial use" clause is always purpose: COMMERCIAL prohibited — never a user type. One clause, one encoding.

There is no territorial exclusion field on usage terms. "Permitted everywhere except Germany" is written the same idiomatic way territorial grants use: a broad permit plus a narrow prohibition, with prohibition winning where they overlap.

[
  { "usage_type": "COPY", "status": "PERMITTED" },
  { "usage_type": "COPY", "status": "PROHIBITED", "territory_codes": ["DE"] }
]

Channel scoping

Real licensing deals scope grants by distribution channel as routinely as by territory — "Excluded Channels: Udemy, Skillshare" is one of the most common clauses in licensing paper. Usage terms and manifestation grants take three channel fields, mirroring the territory pattern:

• channel_ids — the term applies only through these named channels (the allowlist). IDs come from the platform's channel registry and are stored exactly as written.
• channel_classes — coarse narrowing: DIRECT (Packt's own properties) or THIRD_PARTY.
• excluded_channel_ids — carve-outs from an otherwise unscoped term (the everyday "everywhere except Udemy" case). This is the one axis with an exclusion field, and it works exactly like worldwide + excluded territories: carve-outs are only valid when no allowlist is set.

Omitted means every channel. The common special case — "exclusive everywhere, except non-exclusive on named channels" — is written as two grants: an exclusive grant excluding the channels, plus a non-exclusive grant naming them.

{
  "usage_type": "MAKE_AVAILABLE",
  "status": "PERMITTED",
  "excluded_channel_ids": ["udemy", "skillshare"]
}

When a rights check names a channel, the verdict is channel-precise; a check that omits the channel against a channel-scoped grant comes back CONDITIONAL with the narrowing spelled out — never a bare "yes" that a carve-out could contradict. See Complete examples for the full walk-through.

Quantities

Numeric limits are structured so "10 concurrent users", "3 chapters per user", and "10% of the Work" stay distinguishable — a bare number is not actionable. A quantity carries a max, a unit (ACTIONS, COPIES, CHAPTERS, PAGES, WORDS, PERCENT, CONCURRENT_USERS), and an optional per referent (USER, RESOURCE, WORK, DAY, MONTH, YEAR). Limits in different units are independent and all apply.

Conditions

A CONDITIONAL term (and sometimes a PERMITTED one) carries structured conditions, each a typed object the platform can evaluate. Prose belongs in a free-text exception, never in place of a type.

The condition vocabulary is closed — adding a type is a schema change, because every type has to be something the platform can actually enforce. A clause that fits no type is recorded as the most restrictive applicable verdict with the wording quoted in exception.

AI usage

This is the vocabulary's headline, and it is deliberately not one question. "Can an AI use this content?" hides several very different deals: feeding content to a model to fact-check a claim, to draft a new chapter, to answer a reader, to license to a third-party model, or to train model weights are materially different things, and a rights holder routinely permits some while prohibiting others. So — exactly as the channel-partner verbs above name each channel action separately — the model names each AI action as its own usage type, rather than one coarse "AI use". There are six.

Each verb is independent, and a contract mixes them freely. The common shape for a cautious author agreement permits AI_GROUNDING and AI_RETRIEVAL — verify the content, and cite it to readers — while prohibiting AI_TRAINING and AI_DISTRIBUTION — never train on it, never license it to a third-party model.

Who performs the AI use stays on user_types, not on the verb — the same one-clause-one-encoding rule the rest of the model follows. PLATFORM scopes a grant to Packt-operated systems; INDIVIDUAL / INSTITUTIONAL scope it to external consumers. There is a single exception: AI_DISTRIBUTION, where "onward to a third party" is intrinsic to the verb — exactly as it is for DISTRIBUTE — so it needs no user type to say "third-party".

Two rules make AI safe by default:

• Silence denies. If no term mentions an AI verb, that AI action is PROHIBITED. There is no implicit permission. None of the platform's default licence contracts carry an AI_TRAINING term, so training permission is always an explicit, deliberate grant on a specific contract — never something a Work drifts into.
• The PLATFORM user type scopes first-party use to Packt. A grant with user_types: ["PLATFORM"] permits Packt-operated systems only. Equivalent third-party use stays prohibited, because no term covers it — silence denies.

By default, first-party essentials are on. The standard author-agreement template grants AI_GROUNDING and AI_RETRIEVAL to PLATFORM only, so Packt's own assistant may verify and cite a Work; every other AI verb stays silence-denied until granted. Pricing is not special either — a metered AI use produces ordinary royalty events: a served surface settles as a subscription attribution, a deal as a fee or revenue share. See AI & your content for the plain-English policy.

[
  { "usage_type": "AI_GROUNDING", "status": "PERMITTED" },
  {
    "usage_type": "AI_RETRIEVAL",
    "status": "PERMITTED",
    "method": "MCP",
    "exception": "Authenticated, metered access only"
  },
  { "usage_type": "AI_TRAINING", "status": "PROHIBITED" },
  { "usage_type": "AI_DISTRIBUTION", "status": "PROHIBITED" }
]

{
  "usage_type": "AI_TRAINING",
  "status": "PERMITTED",
  "user_types": ["PLATFORM"],
  "source": { "document_id": "srcdoc_addendum_1", "clause": "2.1" }
}

Handling terms

A handling term is an obligation or prohibition that travels with any use of the content, rather than describing a particular thing a consumer may do. Where a usage term answers "may I?", a handling term answers "and whenever I do, what must I always honour?".

Handling terms take a status of REQUIRED, PROHIBITED, or PERMITTED. AUTOMATED_PRODUCT_INCLUSION is a deliberate escape hatch: set it to PROHIBITED when licensing terms are too ambiguous to model confidently, and the content is kept out of every automated product pathway until a human signs off.

Duration

Duration says until when a contract is in force, and what happens at the edges. A contract can be:

• Perpetual — no end date; the grant never lapses.
• Dated — an effective_date and an expiry_date; the grant is in force between them.
• Auto-renewing — an auto_renew_months interval. When the expiry date arrives and no termination notice has been recorded, the platform extends the term automatically and writes a new version. A contract never lapses by accident while the paper agreement has renewed.
• Under notice — a notice_period_days window before expiry within which either party must serve notice to stop an auto-renewal. When that cutoff approaches on an auto-renewing contract with no notice recorded, the platform raises a renewal_approaching signal so licensing staff can act while notice can still be served.

A dated or terminated contract can also grant continuing access — a window after the contract ends during which some rights survive. The classic case is post-cancellation ebook access for existing subscribers. Within the window, territorial, usage, and handling terms continue unchanged, but manifestation rights narrow twice: to the classes named in the continuing-access terms, and to fulfilling entitlements that already existed before the contract ended. Continuing access narrows, never widens — it can only preserve a subset of what was granted while the contract was live.

stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> ACTIVE
    DRAFT --> TERMINATED
    ACTIVE --> SUSPENDED
    ACTIVE --> EXPIRED
    ACTIVE --> TERMINATED
    SUSPENDED --> ACTIVE
    SUSPENDED --> EXPIRED
    SUSPENDED --> TERMINATED
    EXPIRED --> [*]
    TERMINATED --> [*]

When several contracts govern one Work

A Work is usually governed by exactly one contract, but it need not be. Co-authors sometimes sign separate agreements; a translation-rights deal can be acquired on its own; and during a succession window — between an expired agreement and its renegotiated replacement — two contracts may briefly overlap on the same Work. The platform resolves all in-force contracts into a single set of effective rights, and the rules for combining them are what this section covers.

Only inbound rights contracts contribute — those are the rights the platform has acquired. Outbound contracts (the platform granting rights onward to a distributor or reseller) never widen a Work's resolved rights; they are validated against those rights instead. And a services engagement — a reviewer letter, a training call-off (overview) — carries no rights terms at all, so it contributes nothing to resolution however many Works it references.

The governing rule, once more, is prohibition wins. For any given territory, manifestation, language, and usage, the merge follows a fixed precedence: PROHIBITED beats CONDITIONAL beats PERMITTED. A conditional grant carries its conditions into the resolved rights, and those conditions must be honoured even if another contract grants the same use unconditionally. Terms only interact where their scopes overlap — a prohibition on commercial distribution does not erase a separate permission for educational distribution.

A few consequences worth remembering:

• A prohibition cannot be cancelled by another contract's silence. If one contract prohibits a use, no second contract lifts it merely by not mentioning it. Prohibitions and required obligations accumulate.
• Where two contracts both permit with different quantity limits, the broader limit wins — a grant is an authority, and the widest authority governs; the restrictive direction is always handled by the prohibition precedence, never by comparing quantities.
• Royalty accrues per contract. A single sale of a translated edition can accrue royalty under both the author agreement and the translation agreement — each contract earns on the sales its grant scope covers.

Related pages

• Contracts & Rights overview — how contracts fit the platform, and the contract lifecycle.
• Contract examples — worked contracts for common deal shapes and default licences.
• Royalties — the commercial terms that sit alongside the rights vocabulary.
• Works & rights — how these terms reach content as resolved, projected rights.
• Core concepts — the Work → Expression → Manifestation → Product ladder these grants address.
• Explorer — Chapter III — contracts and rights, visualised.