Is a torrent client legal?

The tool, and what moves through it

The tool is a transfer mechanism and the content is a separate matter, which is why the two have to be described separately before anything else makes sense. A useful way to see it is as layers, because each layer has a different character and the arguments people conflate belong to different ones.

The protocol

A published specification, first described in 2001, for splitting a file into pieces, hashing each piece with SHA-1 and exchanging them between peers. It is a document. It describes no content and holds none.

The client

A program that implements the specification, such as qBittorrent, Transmission or Deluge. It opens sockets, requests numbered pieces, verifies hashes and writes to disk.

The tracker

A server that answers a question of the form "who else is working on this info hash". It stores addresses, not files, and it never sees the content.

The swarm

The set of peers exchanging pieces of one particular torrent at one particular moment. It is a temporary condition of a network, not an entity.

The file

The actual bytes. This is the only layer at which the question of copyright arises at all, and it is the layer everything else is indifferent to.

The same client carries all of it without distinction. The Internet Archive publishes torrents for its collection deliberately, Linux and BSD projects publish their install images the same way, and the program moving those is the identical program somebody else is running for a different purpose. The words in that list, peer, piece, info hash and tracker, are set out in the Glossary.

Why a general purpose program is treated as a program

A general purpose program is treated as a program because it has substantial uses that nobody disputes, and that has been the pivot in reasoning about tools since long before the internet. Photocopiers, recording equipment and general computers all raised the same question in their turn, and the 1984 American decision on the home video recorder is the one usually cited: a device that can be used to infringe is not for that reason a device whose existence is unlawful, so long as it has real and legitimate uses. Peer to peer clients have those uses in abundance and in public, from operating system images on release day to archive collections to code deployed inside companies.

Packaging does not change any of this. The same client compiled for Linux, installed on Android, or run headless inside a Docker container on a server is the same software doing the same thing, and the form it is delivered in has never been what any of this turns on.

What the reported disputes have actually concerned

The reported disputes have concerned conduct rather than code, and this is the pattern worth understanding. The file sharing services of the Napster era were centrally operated: a company ran the index, the lookup passed through its systems, and the arguments were about what that company knew and what it did. In the years since, from the Grokster decision of 2005 to the case that ended LimeWire in 2010, legal attention has fallen on operators of services and on individual acts of copying, while the specifications and the general purpose client programs have continued to be written, published and packaged openly by projects working in the open.

How different legal systems reason about knowledge, encouragement, profit and control varies a great deal. Some questions settled in one country are unsettled in another, and outcomes have differed between cases with similar facts. That variation is not a detail to be flattened into a summary, and no page can resolve it for a particular situation in a particular place.

Trackers, and the two questions hiding inside one

Are trackers illegal is really two questions, and separating them dissolves most of the confusion. The first question is what a tracker is, technically. A tracker is a coordination server: a client sends it an info hash and an address, and it returns a list of other addresses working on that same info hash. It stores no files, transfers no content, and cannot tell what the pieces contain. When a tracker stops answering, the client keeps the peers it already has and retries on a schedule, which is why a transfer may sit stalled rather than fail outright, and that is a network condition rather than anything else.

The second question is about specific services and the people who operate them, which is a matter of conduct in a particular jurisdiction and not a property of the mechanism. This page describes the mechanism and names no service of any kind.

The tracker list attached to a torrent is a field the client exposes, and most clients allow an address to be added to it. Doing so changes only which servers are asked for peers. It adds nothing to a torrent, removes nothing from it, and leaves the info hash and the file list exactly as they were, so it is a connectivity setting and not a change to what a torrent is.

What varies, and what this page cannot tell anyone

What varies is nearly everything except the distinction at the top of the page. Copyright terms differ by country and by kind of work. Exceptions and limitations differ, and what one system allows for private copying, quotation, research or preservation another does not. Enforcement practice differs again, and can change without the underlying law changing at all. A work in the public domain in one country can be protected in another on the same day.

None of this is legal advice and no general page could be, because the answer to any real question depends on a jurisdiction, a work and a set of facts. What can be said plainly is the technical part: the protocol is a specification, a client is a program, a tracker is an address server, and the content is the separate question that everything else is indifferent to. For moving files between machines that all belong to one person there is no such question at all, which is the situation Syncthing was built for.