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 §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

Recommended: CC0 1.0 Universal. This matches MusicBrainz core data and AcousticBrainz exactly, and it is the one choice consistent with the rest of this document.

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 must be taken at upload. A licence the server declares is worth nothing if contributors never granted it. The contribution terms must state that submitting a manifest places its content under CC0, and the JRay plugin's contribution opt-in (SPEC §9) is where a user encounters that — it is already an explicit, off-by-default choice, so this adds a sentence to a decision the user is already making 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: recommended, not yet adopted. No repository currently carries a LICENSE file, and nothing outside this document states a data licence. Adopting this means a recorded decision, a LICENSE file, a line in the contribution terms, and a sentence in the plugin's contribution opt-in.

---

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. Adopt a data licence and add a LICENSE file. §6 recommends CC0 1.0. No repository currently carries one, and the server's GPL-3.0-or-later covers the code only — it says nothing about the manifests, which are the thing that actually replicates between instances. This is the largest outstanding gap in the posture.
8. State the licence in the contribution terms, so contributors grant it rather than the server merely declaring it (§6).

---

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
• Dutch Court Rules That Freely Given Fan-Subtitles Are Copyright Infringement — Techdirt
• Fansubbing: Dutch Court Rules Fan-Made Subtitles Are Illegal And Copyright Infringement — IBTimes

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

• Legal Information — OpenSubtitles Help Center
• Terms of Service — OpenSubtitles Help Center
• DMCA — OpenSubtitles Help Center
• Legality of Subtitle Websites — Open Subtitles Blog

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

• Chromaprint — AcoustID
• Database — AcoustID
• About / Data License — MusicBrainz
• AcousticBrainz — MusicBrainz
• AcoustID — Wikipedia