Un VPN ou un proxy peut-il copier un contenu protégé par le droit d’auteur ? Trois actes

Le transfert de paquets, la mise en cache et la republication se ressemblent depuis un tableau de bord et se comportent tout autrement dès qu’une question de droits se pose. Un service qui déplace des octets entre un utilisateur et un serveur accomplit un acte, tandis que celui qui conserve une réponse et la remet au visiteur suivant en accomplit un autre. Publier le matériel d’autrui sous votre propre nom est un troisième acte, et seul ce troisième est une distribution au sens ordinaire.

Déterminez lequel de ces trois votre pile technique accomplit réellement, puis rattachez-lui la règle correspondante. Les étiquettes de produit ne tranchent rien ici, et le protocole employé n’est pas non plus le critère.

Trois actes qu’un proxy ou un VPN peut accomplir

Une passerelle accepte un flux TCP, réécrit les adresses et transfère les segments dans les deux sens. Rien ne survit à la connexion sur disque, et la charge utile reste opaque pour la passerelle, à moins que le client ne négocie TLS avec la passerelle plutôt qu’avec l’origine.

Un intermédiaire de cache fonctionne autrement : il analyse la requête, stocke la réponse pour une durée qu’il calcule ou lit dans les en-têtes, puis rejoue cet objet stocké auprès des clients ultérieurs. Quelque chose existe désormais hors du réseau, indexé par URL et par validateur, et sa conservation relève d’un choix de configuration plutôt que d’un effet de bord.

La republication va plus loin. Le matériel se trouve sur une infrastructure que vous contrôlez, adressé à un public que vous avez choisi, souvent après édition. Les deux premiers actes décrivent le transport, tandis que le troisième décrit la distribution.

Où un proxy qui déchiffre transforme le transport en copie

La distinction qui tranche la plupart des débats est de savoir si la boîte détient un jour du texte en clair. Un tunnel pur, qu’il s’agisse de WireGuard, d’un périphérique OpenVPN tun ou d’un transfert SSH -L, déplace du texte chiffré entre les extrémités et ne laisse rien de lisible. Un proxy qui termine TLS fait l’inverse : il achève la poignée de main, met la réponse en mémoire tampon, puis rechiffre le flux vers le client. Entre ces opérations, l’œuvre existe sous une forme que l’opérateur peut inspecter et conserver.

17 USC 106 range la reproduction et la distribution parmi les droits exclusifs, chacun soumis aux limitations prévues par le même titre. Un tampon d’une milliseconde peut entrer dans une limitation sans discussion ; un objet conservé et rejouable s’y loge beaucoup plus difficilement. La durée et la finalité pèsent davantage que le fait d’avoir touché la mémoire.

Rien de tout cela ne transforme un VPN en licence, et rien ne fait de tout proxy un contrefacteur. Le transport est un fait parmi d’autres, et la question évaluable reste la même : quel acte, sur le matériel de qui, sous quelle permission.

Les en-têtes de cache décrivent une permission de protocole, pas une permission légale

Un cache HTTP décide de ce qu’il peut stocker à partir des métadonnées de la réponse, et la RFC 9111 fixe les règles qu’il suit. Cache-Control: no-store ordonne à tout cache conforme de rejeter la réponse, tandis que private limite la réutilisation à un seul utilisateur et qu’un max-age long invite au stockage partagé. Une seule requête vous dit quelle politique une origine a choisie. Lancez-la avant de discuter de quoi que ce soit d’autre.

curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'

Une réponse qui annonce une longue durée de vie dit aux caches que le rejeu est acceptable au niveau du protocole. Cette déclaration ne dit rien sur le fait que vous puissiez prendre le même objet, le réhéberger et l’intégrer à votre propre service. Deux permissions différentes viennent de deux mécanismes différents, et satisfaire l’une laisse l’autre exactement où elle était.

Le cas miroir échoue de la même manière. HTTPS de bout en bout empêche un cache transparent de stocker quoi que ce soit, mais ce résultat ne crée pas un droit de distribuer le matériel et n’en retire pas un que vous déteniez déjà. Le comportement du protocole explique ce qu’une boîte peut faire ; il ne fournit jamais d’autorisation.

Ce qu’il faut consigner avant la mise en service

Décrivez l’arrangement en des termes qu’un tiers pourrait vérifier. Nommez le matériel et sa source, énumérez les actes que le système accomplit et indiquez combien de temps vit chaque objet stocké.

Gardez cette description avec le déploiement plutôt que dans la mémoire de quelqu’un. Quand une plainte arrive, l’écart entre une position défendable et une supposition est généralement un paragraphe écrit des mois plus tôt qui nomme la durée de conservation et la licence.

Une courte liste de revue couvre les trous récurrents :

• Source du matériel et conditions qui y sont attachées.
• Chaque acte accompli : transférer, stocker, modifier, servir.
• Conservation par classe d’objet, en heures ou en jours.
• Permission ou limitation invoquée pour l’étape de mise à disposition.
• Contact et procédure de retrait pour les titulaires de droits.

Passez la liste au crible de la configuration en production, pas du schéma d’architecture. Là où une réponse manque, cet écart est la tâche suivante : obtenez une permission pour l’acte ou cessez de l’accomplir. Pour un service commercial, faites lire la description écrite par un avocat au regard de la juridiction où vous servez, car c’est la description qui rend cette revue possible. Tout ce que vous ne pouvez pas décrire par écrit est une position que vous ne pouvez pas défendre.