JRay-public-server/docs/legal-posture.md

# Legal posture

What a JRay public server instance holds, what it structurally cannot do, and
how that sits against EU and international copyright law.

This document exists because [`SPEC.md`](../SPEC.md) §5a calls for it: *"Because
the server stores only integers and references to TMDB entities, it holds no
user-generated content in the sense that intermediary-liability regimes
contemplate. This should be stated plainly in the operator documentation,
alongside a contact address for takedown requests."* It is the operator-facing
half of that.

It documents `SR-004` (no binary content), `SR-005` (gallery data never leaves
the instance) and `PR-005` (leak nothing about what a user owns). Those are
requirements, not aspirations: the posture below is a *consequence* of them, and
it survives exactly as long as they do. §8 is the list of changes that would end
it.

The position is **deliberately not original**: §5 adopts it from the services
that have already operated it for decades, and records what was taken from whom.

> **Not legal advice.** This is an engineering description of what the software
> does, mapped onto the legal frameworks that plausibly apply, written to be
> useful to an operator, a hosting provider's abuse desk, and anyone sending a
> complaint. An operator should confirm the analysis for their own jurisdiction.
> Where the law is unsettled or untested this document says so rather than
> asserting a conclusion.

---

## 1. What an instance holds

Exhaustively. The submitted JSON is parsed, validated, resolved to TMDB person
ids, written as rows, and **discarded**; the document served to a client is
*reconstructed* from those rows, never echoed (SPEC §7 "Storage").

| Stored | Form |
|---|---|
| Title identity | TMDB / IMDB id, regex-constrained. Title name and year |
| Cut identity | A runtime in seconds |
| Audio signature | 1288 bytes: one byte per ~93 ms frame, each a 5-bit band index + 2-bit energy class |
| Actor identity | TMDB person id — an integer |
| Presence | Pairs of integer centisecond offsets |
| Provenance | An anonymous token hash, a status, a cast-match ratio, timestamps |

That is the whole of it. There is no column for anything else, and this is a
deliberate control rather than tidiness: a relational schema **can only represent
what it models**, so whatever a validator might have missed has physically
nowhere to live.

### What it does not hold

- **No audio, video, images, or crops.** No field can carry them (`SR-004`).
- **No embeddings and no gallery data** (`SR-005`, `UR-012`). A 512-float array
  is a 2 KB opaque binary field, which is precisely the extension point the
  design lacks.
- **No subtitles or dialogue.** Nothing derived from the script, and nothing
  that reproduces a line of it. This is the distinction that matters most in
  practice — see §5.
- **No URLs, no links, no source information, no torrent identifiers, no
  filenames, no file paths.** Nothing that could help anyone locate, obtain, or
  identify a copy of anything.
- **No file-level fingerprint.** `cut.video_hash` was withdrawn (SPEC §3 "Why
  there is no file-level signal"). Every remaining signal describes a **cut** — the
  edit — and is therefore shared by everyone who holds that edit, however they
  came by it. Nothing in the format individuates one person's particular copy.
- **No accounts, no email addresses, no personal data by design.** Contribution
  uses an anonymous bearer token, stored only as a hash; the server cannot
  enumerate who holds tokens.
- **No free-form text.** Actor names submitted on upload are used for matching
  and then dropped; display names are served from the instance's own
  TMDB-derived table. The only attacker-controlled values reaching the database
  are integers.

---

## 2. What an instance structurally cannot do

Stated as capabilities the software lacks, because that is the form a hosting
provider and a complainant both need.

1. **It cannot store or transmit any part of a copyrighted work** in perceptible
   form. There is no field of any kind that accepts binary or attacker-chosen
   content.
2. **It cannot help anyone obtain a copy of anything.** No links, no sources, no
   swarm identifiers, no search-by-release. A Jmanifest is inert with respect to
   acquisition: knowing one tells you when an actor is on screen and nothing
   whatsoever about where a file might be found.
3. **It cannot identify which copy a user holds.** Post-withdrawal of
   `video_hash`, the server cannot distinguish a client holding the very file a
   manifest was extracted from and one holding a different encode of the same
   cut. This is the intended property, not a limitation.
4. **It cannot reconstruct audio from a signature.** See §4.
5. **It cannot be used as a general content host.** The abuse defence is
   structural: there is nowhere to put a payload (`SR-004`).

---

## 3. Is a Jmanifest a reproduction of the work?

The core question. The answer rests on the idea/expression dichotomy, which is
one of the few genuinely universal principles in this area.

**International.** TRIPS Art. 9(2) and the WIPO Copyright Treaty Art. 2 both
provide that copyright protection "extend[s] to expressions and not to ideas,
procedures, methods of operation or mathematical concepts as such." A Jmanifest
records: *this TMDB person is present in this cut from 191.60 s to 209.20 s.*
That is a proposition about a fact, expressed in integers. It contains no
dialogue, no image, no music, no plot, and no authorial choice belonging to the
film's makers.

**EU.** Under the InfoSoc Directive (2001/29/EC) Art. 2, the reproduction right
covers reproduction of the author's own intellectual creation. *Infopaq*
(C-5/08) established that even an 11-word extract can qualify — but on the
express condition that what is taken *expresses the author's own intellectual
creation*. The relevant test is therefore qualitative, not quantitative, and it
is the test a Jmanifest passes comfortably: an actor's presence interval
expresses nothing of the film's creative content. *Football Dataco* (C-604/10)
points the same way from the other direction — where the content of a dataset is
dictated by technical rules leaving no room for creative freedom, it does not
attract copyright.

**Elsewhere.** In the US, *Feist v. Rural Telephone* (1991) holds that facts are
uncopyrightable regardless of the effort spent gathering them, and there is no
US database right. The analysis is if anything simpler outside the EU.

**Honest caveat.** The set of presence windows across a whole title is derived
*from* the work by watching it, and no court has ruled on precisely this
artefact. The argument above is strong and rests on settled principles, but it
is an argument, not an adjudicated holding.

---

## 4. The audio signature — the one content-derived artefact

This is the field a careful lawyer would examine, so it is addressed directly
rather than buried.

**What it is.** A 120-second window at the midpoint of the media is decoded,
downmixed to mono and resampled to 11025 Hz. Per ~93 ms frame, the log-magnitude
spectrum over 300–3000 Hz is divided into 32 log-spaced bins and **only the index
of the loudest bin** is kept, plus a 2-bit coarse energy class. One byte per
frame; 1288 bytes total (SPEC §3 "Construction").

**Why it is not a reproduction.** The construction discards essentially
everything:

- All phase information is gone.
- All magnitude information is gone except one 2-bit class per frame.
- 31 of 32 bands per frame are discarded; only *which* band was loudest survives.
- Everything outside 300–3000 Hz is discarded.
- Everything outside the central 120 seconds is discarded.

The transform is one-way by construction, not merely difficult to invert. **No
audio can be recovered from it, and nothing about it is perceptible to a human.**
It is roughly 1.3 KB standing in for two minutes of audio — a compression ratio
against the source PCM of about four thousand to one, achieved by throwing away
the signal rather than by coding it efficiently.

**Supporting EU reasoning.** *Pelham* (C-476/17) held that where a sound sample
is included in another work "in a modified form unrecognisable to the ear", there
is no reproduction of the phonogram. That case concerned artistic sampling rather
than fingerprinting, so it is reasoning by analogy rather than a holding on
point — but the principle it turns on, that unrecognisability defeats the
reproduction claim, applies with far greater force here: a Pelham sample is at
least still audio.

**The industry's own premise.** Content-recognition fingerprinting — YouTube
Content ID, Audible Magic, and the compliance ecosystem that grew up around
Art. 17 CDSM — depends on the proposition that a fingerprint of a work is not a
copy of it. Rights holders operate and rely on such systems at scale. A claim
that a fingerprint is itself an infringing reproduction would be in tension with
that practice.

**Where it is computed.** On the user's own machine, from their own file, by the
FFmpeg binary Jellyfin already ships. The transient decode is an ordinary
technological process of the kind InfoSoc Art. 5(1) exempts, and it happens on
the client — the server never decodes anything.

---

## 5. Alignment with comparable services

**This posture is deliberately not novel.** The closest analogues have decades of
operating history between them, and a bespoke argument — however sound — is worth
less than one an ecosystem has already run on. So the position below is adopted
from theirs, and this section records what was taken from whom, and what was
deliberately left.

| Service | Indexes | Litigated? |
|---|---|---|
| CDDB / freedb | Disc IDs computed from track offsets | No copyright litigation. Its controversy was Gracenote's commercial closure of the database, a licensing dispute |
| AcoustID / Chromaprint | Compact per-frame spectral features of recordings | None known. Operated openly alongside MusicBrainz for years |
| MusicBrainz / AcousticBrainz | Recording metadata; crowdsourced acoustic features | None on the data itself |
| OpenSubtitles | **Subtitle files**, plus a file-hash index | **Yes — over the subtitles** |

### Adopted from MusicBrainz, AcoustID and AcousticBrainz

These are the strongest models, and the elements worth copying are structural
rather than rhetorical:

- **An explicit, permissive licence on the data.** MusicBrainz core data and all
  of AcousticBrainz are CC0; AcoustID's data is CC BY-SA 3.0. Every one of them
  states a licence rather than leaving contributed data in an unstated condition.
  JRay had no such statement at all until §6 below, which was the largest single
  gap in this posture.
- **An open-source implementation.** The algorithm and the server are both
  inspectable, so no part of the argument above rests on a claim a reader has to
  take on trust. `JRay-public-server` is `GPL-3.0-or-later`; the audio signature
  is specified in the open, down to a golden fixture an independent
  implementation can be written from (§3).
- **The fingerprint framed as identification, never as content.** Chromaprint is
  presented as a compact mathematical representation for matching near-identical
  audio — not as a compressed recording. §4 makes the same claim about the JRay
  signature, and makes it more strongly, since the JRay construction discards
  strictly more.

### Adopted from OpenSubtitles

Their operational practice is sound even where their drafting is thin:

- **A named copyright contact**, with stated requirements for what a valid notice
  must contain and in what form. Theirs is `copyright@opensubtitles.org`.
- **A plain statement of what is and is not hosted.** Theirs: subtitles
  translated by users, *not* video, movie or audio files. JRay's equivalent is
  §1, and it is a far shorter list.
- **Prompt removal on doubt, without adjudicating the merits.** They remove on
  request rather than litigating whether the request is well-founded; §10 below
  does the same, and SPEC §5a makes delisting a single `UPDATE` precisely so it
  costs the operator nothing to be cooperative.
- **An honest statement of what a takedown can reach.** They say plainly that
  they can remove a file from their own site and cannot remove it from anywhere
  else. The federated equivalent is stated in §10 below.

### Deliberately not adopted

Three things in the ecosystem should **not** be copied, and are named here
because they are the parts most likely to be copied by reflex:

- **OpenSubtitles' "if you are affiliated with any government or ANTI-Piracy
  group … you CANNOT enter this web site" clause.** It has no legal effect
  whatsoever, and its real cost is what it signals: a service that needs to
  exclude scrutiny is asserting something about its own view of itself. This
  posture depends on the opposite claim — an instance holds nothing it would
  mind anyone reading, and §1 is published in full precisely so that a
  complainant can check it. Nothing here should suggest otherwise.
- **Their silence on contributor licensing.** OpenSubtitles' published legal
  pages say nothing about the rights users grant on upload. That is a gap in
  their model rather than a feature of it, and §6 exists because federation
  makes it one JRay cannot afford.
- **"Files we believe are free to redistribute."** A belief-based standard about
  the provenance of contributions. JRay needs no such standard, because the
  structural argument in §§1–4 does not depend on any belief about where a
  contributor's media came from — and the design deliberately cannot know.

### Their published legal reasoning is not a model — only their practice is

Worth stating explicitly, because "align with OpenSubtitles" is an obvious
instruction to give and a bad one to follow literally.

The OpenSubtitles community does publish legal material — a legal-information
page, a DMCA page, a blog post on the legality of subtitle sites, and recurring
forum threads. But what it publishes is **advocacy rather than analysis**, and it
rests on three arguments none of which JRay should borrow:

- **"Fair use."** The service and its user base are substantially European, and
  **there is no fair use in EU law.** InfoSoc Art. 5 provides a *closed list* of
  permitted exceptions, not an open-ended balancing test. Invoking a US doctrine
  against an EU claim is not a weak argument, it is an argument addressed to the
  wrong system — and the Amsterdam court in 2017 was not applying it.
- **Cultural and educational benefit.** True, and irrelevant to whether the
  reproduction right is engaged. It is a case for reforming the law, not a
  defence under it.
- **"The legality is debated / uncertain."** For the specific question of
  unauthorised fan subtitles in the Netherlands it is not uncertain: it was
  decided against them in April 2017. Sweden's seizure of Undertexter.se points
  the same way. Describing a settled adverse holding as an open question is the
  single thing in that material most worth not imitating.

**The asymmetry that matters:** OpenSubtitles must argue that copying protected
expression is *excused*. JRay argues that it copies **no protected expression at
all** (§§3–4). Those are different kinds of position, and the second does not
need the first's arguments — borrowing them would import a weakness this design
does not have, and would implicitly concede the point they are conceding.

So: take their **operational practice**, which is sound and battle-tested, and
take MusicBrainz's and AcoustID's **structural posture**, which is what a service
that genuinely holds no protected expression should look like. Take neither
community's excuses.

### The OpenSubtitles answer specifically

The user-facing question — *"OpenSubtitles has been doing this for twenty years,
what happened to them?"* — has a clean answer, and it is favourable.

**The legal exposure was always the subtitles, never the hash index.** In April
2017 the Amsterdam District Court ruled, in proceedings brought by the Free
Subtitles Foundation (Stichting Laat Ondertitels Vrij) against the Dutch
anti-piracy body BREIN, that fan-made subtitles may be created and distributed
only with the rights holder's permission, and that doing so otherwise is
infringement. The reasoning is unremarkable once stated: **a subtitle file is a
transcription or translation of the film's dialogue.** Dialogue is the
screenwriter's expression; a translation of it is a derivative work. That is
squarely within the reproduction and adaptation rights, and the fact that the
subtitles were made from scratch and given away free did not save them.

**JRay carries none of that exposure**, because it carries no dialogue. This is
the single sharpest distinction available:

> OpenSubtitles distributes the *words characters say*. JRay distributes *when a
> credited actor is on screen*. The first is authored expression. The second is
> a fact about the performance.

The OpenSubtitles **hash index** — the same first+last-64 KiB-plus-size
construction JRay used to use — has to my knowledge never been the subject of a
copyright claim in its own right, in any jurisdiction, in about two decades of
operation. That is an absence of litigation rather than an adjudicated
clearance, and it should be described that way. JRay no longer carries such a
hash in any case (§3), so the question is now moot for this design.

### The distinguishing case on the other side

*Ziggo* (C-610/15, "The Pirate Bay") held that indexing and categorising torrent
files **is** a communication to the public, so an index can certainly infringe.
The distinction is precise and JRay sits clearly on the safe side of it: TPB
indexed *the works*, via identifiers that let a user obtain them, and the Court's
reasoning turned on the platform playing "an essential role" in making the works
available. A Jmanifest plays no role in availability whatsoever — it contains
nothing that can retrieve a byte of anything. *GS Media* (C-160/15) is likewise
inapplicable for the simple reason that there are no links.

---

## 6. The licence Jmanifests are published under

**Adopted: CC0 1.0 Universal** — recorded in SPEC §5b, full text in
[`LICENSE-DATA`](../LICENSE-DATA). This matches MusicBrainz core data and
AcousticBrainz exactly, and it is the one choice consistent with the rest of this
document.

Note the separation, which must not be blurred: the **code** is
`GPL-3.0-or-later`, the **data** is CC0. The code licence says nothing about the
manifests, and the manifests are the part that replicates between instances.

**Why CC0 and not a share-alike licence.** AcoustID uses CC BY-SA 3.0, and the
temptation is to follow it — but a share-alike licence works by *asserting* a
right in the data and then conditioning its use. §3 argues at length that
presence timings are facts rather than protectable expression. Asserting
copyright in them in order to license them would contradict that argument in the
same repository, and a contradiction of that kind is worth more to an opponent
than the licence is worth to the project. CC0 asserts nothing, which is the
position §3 actually takes.

**Three things it buys, beyond consistency:**

- **It waives the sui generis database right explicitly.** CC0 1.0 covers
  database rights by name, not merely copyright. That closes, from the
  contributor's side, precisely the EU-specific residual exposure §7 identifies —
  and it closes it in the one jurisdiction where a database right exists to be
  waived.
- **It makes federation lawful without a negotiation.** SPEC §9a has independent
  operators replicating each other's catalogues wholesale. Replication is a
  reproduction and a making-available of whatever right subsists in the
  compilation; without a grant flowing from the contributor through every peer,
  each hop is an unlicensed one. A viral or non-commercial licence would make
  each peering an agreement to be checked. CC0 makes it a non-event.
- **It removes the incentive to fork the network.** Nobody needs to negotiate
  with an instance operator to mirror a catalogue, so no instance can become a
  chokepoint. That is the same property that let freedb be forked when CDDB was
  closed commercially — which is the failure mode this whole ecosystem learned
  from.

**The grant is taken at token issuance.** A licence the server declares is worth
nothing if contributors never granted it, so `POST /tokens` returns the licence
and its terms alongside the token — there are no accounts, so acquiring the
contribute capability is the only moment at which a grant can be made. The JRay
plugin's contribution opt-in (SPEC §9) is where a user encounters it: already an
explicit, off-by-default choice, so this adds a sentence to a decision the user
is making anyway rather than a new one.

**Scope, stated precisely.** The licence covers *the manifest* — the timings,
identifiers and signature contributed. It does not and cannot purport to license
the underlying film, which is not the contributor's to license and which the
server does not hold. This distinction is the whole of §§1–4 restated in a
sentence, and it belongs in the terms in exactly that form.

> **Status: adopted.** Recorded in SPEC §5b as `UR-019`, with the text in
> [`LICENSE-DATA`](../LICENSE-DATA) and the grant delivered by `POST /tokens`.

### Code licences, for completeness

Distinct from the above, and settled across all three repositories:

| Repository | Code licence | File |
|---|---|---|
| `JRay-public-server` | `GPL-3.0-or-later` | `LICENSE` — verified byte-identical to the FSF text |
| `jRay` (plugin) | `GPL-3.0` | `LICENSE` |
| `scene-actor-extraction` | `MIT`, with a model/third-party addendum | `LICENSE` |

Two notes an operator or contributor may need:

- **The MIT/GPL split is directionally fine.** MIT-licensed extraction output and
  code can be used by the GPL components; the reverse would not hold. Nothing in
  the current data flow runs the wrong way.
- **`scene-actor-extraction`'s addendum is the one to actually read.** It records
  that some bundled models are licensed for **non-commercial research use only**,
  which is a restriction on *deploying the extraction pipeline* and has no
  bearing on the manifests it produces or on this server. The distinction matters
  precisely because CC0 manifests could otherwise be mistaken for a statement
  about the tooling that generated them.

---

## 7. The other frameworks

### Database right (EU-specific — Directive 96/9/EC)

The one people forget, because it has no counterpart in most of the world.

**Does an instance infringe anyone else's?** The sui generis right protects
substantial investment in *obtaining, verifying or presenting* the contents of a
database. *British Horseracing Board v William Hill* (C-203/02) drew the decisive
line: the right protects investment in **obtaining** existing data, not in
**creating** it. JRay's timings are *created* — by running a CV pipeline over a
file — not extracted from anyone's database. The TMDB identifiers are a different
matter, and the governing instrument there is **TMDB's own API terms, not
copyright law**. An operator must hold a valid TMDB API key and comply with its
terms, including attribution. Treat that as an operational obligation, because it
is the most likely source of a real complaint.

**Does an instance acquire one?** Possibly, in the operator's favour, over the
catalogue as compiled. Not relied upon here.

### Intermediary liability — DSA (Regulation (EU) 2022/2065)

Art. 6 carries forward the hosting safe harbour formerly in e-Commerce Directive
Art. 14; Art. 8 preserves the prohibition on general monitoring obligations.

**The safe harbour is a fallback here, not the primary defence** — an instance
holds no user-generated content of the kind the regime contemplates. But the
obligations that establish it are cheap, and an operator should meet them anyway:
a published point of contact (Arts. 11–12) and a notice-and-action mechanism
(Art. 16). Note that Art. 19 exempts micro and small enterprises from the heavier
Section 3 obligations, and a volunteer-run non-commercial instance sits well
outside the tiers aimed at large platforms.

In France specifically, this is the *hébergeur* status under the LCEN (loi
n° 2004-575 du 21 juin 2004, art. 6), and a published contact address is what
establishes it.

### Art. 17 CDSM (Directive (EU) 2019/790) — does not apply

Someone will raise it, so it is worth disposing of. Art. 17 binds an "online
content-sharing service provider", defined in Art. 2(6) as one that stores and
gives the public access to **a large amount of copyright-protected works uploaded
by its users**. A manifest server stores no works at all, so it is not an OCSSP
and Art. 17 does not engage. Art. 2(6) additionally carves out not-for-profit
services.

### Technological protection measures

InfoSoc Art. 6, and in France the DADVSI. The server never circumvents anything,
ships no circumvention tool, and holds nothing that could not equally have been
derived from a lawfully obtained copy. Whatever a user does locally to read their
own media is independent of the server, which has no way to know it and — since
`video_hash` was withdrawn — no way to record which encode a contributor held
even incidentally.

### Data protection (GDPR)

Personal data held is minimal by design: no accounts, no email, token hashes
only, and rate-limit counters that live in process memory and reset on restart.
Two items deserve an operator's attention:

- **`reports.source_ip_hash` is salted but not secret.** It is
  `SHA-256(server_id ‖ 0x00 ‖ ip)`, and `server_id` is a public value — the
  instance's hostname. That salt does what its code comment claims, which is to
  make hashes non-comparable *across instances*; it does **not** make them
  irreversible, because anyone knowing the hostname can enumerate the whole IPv4
  space in minutes. Treat these as pseudonymous personal data, set a retention
  period, and switch to an HMAC under a secret key if the value is worth
  protecting.
- **Reverse-proxy access logs are the real linkage risk**, not the schema. A
  default nginx or Caddy configuration correlates bearer token to IP address for
  free, which reconstructs exactly the contributor identity the token design goes
  to some trouble to avoid. Disable or truncate them.

Actor names are personal data, but concern public figures acting in a
professional capacity, are sourced from TMDB rather than from uploads, and are
served rather than stored from user submissions.

---

## 8. What would destroy this posture

Every statement above is a consequence of a design property. These changes would
each remove one, and should be treated as proposals to delete the posture rather
than as incremental features:

| Change | What it destroys |
|---|---|
| Shipping images, face crops, or embeddings | §1, §2.1. Ends `SR-004` and `SR-005` at a stroke; introduces a moderation obligation and a rights exposure over the crops themselves |
| Adding any free-form string field | §1 "no free-form text". Reopens the payload channel `SR-004` closes |
| Adding a URL field of any kind | §2.2 and the *Ziggo* distinction in §5 — the one that actually matters |
| Storing the uploaded JSON verbatim | §1. A blob is an opaque container; whatever the validator missed gets persisted and served back |
| Reintroducing a file-level fingerprint | §1, §2.3. Restores the release-level oracle and makes a contributor's uploads an inventory of their own files |
| Carrying subtitles or dialogue | §5. Moves the design from JRay's position to OpenSubtitles' — the one that *has* been litigated, and lost |

---

## 9. Operator checklist

1. **Publish a contact address for notices**, and publish this document. This is
   what makes a complaint resolvable by email rather than by escalation, and
   what establishes hosting-provider status under the LCEN / DSA.
2. **Hold a valid TMDB API key and comply with its terms**, attribution
   included. This is the most likely source of a genuine complaint.
3. **Disable or truncate reverse-proxy access logs.** See §6.
4. **Set a retention period on `reports.source_ip_hash`**, and use an HMAC under
   a secret key rather than the public `server_id` salt if the linkage matters.
5. **Do not contribute manifests from the instance you operate.** Aggregate
   deniability — that a manifest may have been replicated from any peer, and
   says nothing about what its host holds — is real and load-bearing, and it
   does not survive a traceable linkage from your instance to your own uploads.
   Contribute through the ordinary token path, from elsewhere, if at all.
6. **Keep the kill switch usable.** SPEC §5a makes delisting a single `UPDATE`:
   one manifest, every manifest from a token, or every manifest for a title.
   Delisting is instant and reversible; deletion is a separate, logged action.
7. **Do not modify the contribution terms without re-reading §6.** The data
   licence is CC0 1.0 (SPEC §5b), delivered by `POST /tokens`. Its scope limit —
   the manifest, never the underlying work — is the operative half, and a
   reworded term that blurs it grants something no contributor can grant.
8. **Ship both licence files with any distribution.** `LICENSE` (code,
   `GPL-3.0-or-later`) and `LICENSE-DATA` (manifests, CC0 1.0) answer different
   questions, and a package containing only the first leaves the question that
   actually matters for federation unanswered.

---

## 10. Responding to a notice

A valid notice should identify the title and, if it concerns a specific
manifest, its `manifest_id`. The operator can then:

- **Delist that manifest**, or every manifest for that title, immediately
  (SPEC §5a "Residual risk and the operator's lever").
- **Confirm what was held**, using §1 — which for any manifest is a list of
  integers, and can be stated in full.

What the operator cannot do is remove a copy of the work, because there is not
one. A notice demanding takedown of infringing *content* is answerable in one
sentence: the service holds no content of the complainant's, and §1 is the
complete list of what it does hold. Federation retractions (SPEC §9a) can propagate a
withdrawal to peers, and `TrustAbuseRetractions` exists precisely so that a
legally-motivated withdrawal can be honoured across instances that opt into it.

---

## Sources

**The 2017 Amsterdam ruling (§5):**

- [Unauthorized Subtitles For Movies & TV Shows Are Illegal, Court Rules — TorrentFreak](https://torrentfreak.com/unauthorized-subtitles-for-movies-tv-shows-are-illegal-court-rules-170421/)
- [Dutch Court Rules That Freely Given Fan-Subtitles Are Copyright Infringement — Techdirt](https://www.techdirt.com/2017/04/25/dutch-court-rules-that-freely-given-fan-subtitles-are-copyright-infringement/)
- [Fansubbing: Dutch Court Rules Fan-Made Subtitles Are Illegal And Copyright Infringement — IBTimes](https://www.ibtimes.com/fansubbing-dutch-court-rules-fan-made-subtitles-are-illegal-copyright-infringement-2529162)

**OpenSubtitles' own published material (§5) —** cited as the position being
declined, not adopted:

- [Legal Information — OpenSubtitles Help Center](https://opensubtitles.tawk.help/article/legal-information)
- [Terms of Service — OpenSubtitles Help Center](https://opensubtitles.tawk.help/article/terms-of-service)
- [DMCA — OpenSubtitles Help Center](https://opensubtitles.tawk.help/article/dmca)
- [Legality of Subtitle Websites — Open Subtitles Blog](https://blog.opensubtitles.com/opensubtitles/legality-of-subtitle-websites-how-open-subtitles-enhances-global-media-accessibility)

**Fingerprinting and data licensing (§§4, 6):**

- [Chromaprint — AcoustID](https://acoustid.org/chromaprint)
- [Database — AcoustID](https://acoustid.org/database)
- [About / Data License — MusicBrainz](https://musicbrainz.org/doc/About/Data_License)
- [AcousticBrainz — MusicBrainz](https://musicbrainz.org/doc/AcousticBrainz)
- [AcoustID — Wikipedia](https://en.wikipedia.org/wiki/AcoustID)