Can a VPN or Proxy Copy Copyrighted Content? Three Acts
Forwarding packets, caching responses and republishing raise separate copyright questions. Match the act your service performs to the rule that governs it.
Packet forwarding, caching and republication look alike from a dashboard and behave nothing alike once a rights question arrives. A service that moves bytes between a user and a server performs one act, while one that keeps a response and hands it to the next visitor performs another. Publishing someone else's material under your own name is a third, and only that third act is distribution in the ordinary sense.
Work out which of those three your stack actually does, then attach the rule that matches it. Product labels settle nothing here, and the protocol in use is not the test either.
Three acts that a proxy or VPN can perform
A gateway accepts a TCP flow, rewrites addresses and forwards segments in both directions. Nothing survives the connection on disk, and the payload stays opaque to the gateway unless the client negotiates TLS with the gateway rather than with the origin.
A caching intermediary works differently: it parses the request, stores the response under a lifetime it computes or reads from headers, and replays that stored object to later clients. Something now exists off the wire, keyed by URL and validator, and its retention is a configuration choice rather than a side effect.
Republishing goes one step further. The material sits on infrastructure you control, addressed to an audience you picked, often after editing. The first two acts describe transport, while the third describes distribution.
| Act | What exists afterwards | Question that decides the outcome |
|---|---|---|
| Carry a flow | Translation state and buffers lasting seconds | Which intermediary provision covers transient transmission? |
| Store a response | An object plus freshness and validator metadata | Was retention and replay authorised, and until when? |
| Serve the work under your URL | A published copy addressed to a new audience | What permission covers distribution to that audience? |
Where a decrypting proxy turns carriage into copying
The distinction that decides most arguments is whether the box ever holds plaintext. A pure tunnel, whether WireGuard, an OpenVPN tun device or an SSH -L forward, moves ciphertext between endpoints and leaves nothing readable behind. A TLS-terminating proxy does the opposite: it completes the handshake, buffers the response in memory, then re-encrypts the stream toward the client. Between those operations the work exists in a form the operator can inspect and keep.
17 USC 106 lists reproduction and distribution among the exclusive rights, each subject to the limitations set out in the same title. A millisecond buffer may fit inside a limitation without argument; a retained, replayable object is much harder to place there. Duration and purpose carry more weight than the fact that memory was touched at all.
None of that turns a VPN into a licence, and none of it makes every proxy an infringer. Transport is one fact among several, and the assessable question stays the same: which act, on whose material, under what permission.
Cache headers describe protocol permission, not legal permission
An HTTP cache decides what it may store from response metadata, and RFC 9111 sets the rules it follows. Cache-Control: no-store tells every compliant cache to drop the response, while private confines reuse to a single user and a long max-age invites shared storage. One request tells you which policy an origin chose. Run it before arguing about anything else.
curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'
A response advertising a long lifetime is telling caches that replay is acceptable at the protocol level. That statement says nothing about whether you may take the same object, rehost it and fold it into your own service. Two different permissions come from two different mechanisms, and satisfying one leaves the other exactly where it was.
The mirror case fails the same way. End-to-end HTTPS stops a transparent cache from storing anything, yet that outcome neither creates a right to distribute the material nor removes one you already held. Protocol behaviour explains what a box can do; it never supplies authorisation.
What to write down before the service goes live
Describe the arrangement in terms an outsider could check. Name the material and its source, list the acts the system performs, and state how long each stored object lives.
Keep that description with the deployment rather than in someone's memory. When a complaint arrives, the gap between a defensible position and a guess is usually a paragraph written months earlier that names the retention period and the licence.
A short review list covers the recurring holes:
- Source of the material and the terms attached to it.
- Each act performed: forward, store, edit, serve.
- Retention per object class, in hours or days.
- Permission or limitation relied on for the serving step.
- Contact and takedown path for rights holders.
Run the list against the live configuration, not the architecture diagram. Where an answer is missing, that gap is the next task: either obtain permission for the act or stop performing it. For a commercial service, have a lawyer read the written description against the jurisdiction you serve in, because the description is what makes that review possible. Anything you cannot describe in writing is a position you cannot defend.