Pode unha VPN ou un proxy copiar contido protexido por dereitos de autor? Tres actos
O reenvío de paquetes, a caché de respostas e a republicación formulan cuestións distintas de dereitos de autor. Relacione o acto que realiza o seu servizo coa norma que o rexe.
O reenvío de paquetes, a caché e a republicación parecen iguais nun panel e compórtanse de xeito totalmente distinto cando chega unha cuestión de dereitos. Un servizo que move bytes entre un usuario e un servidor realiza un acto, mentres que un que garda unha resposta e a entrega ao seguinte visitante realiza outro. Publicar material alleo baixo o seu propio nome é un terceiro, e só ese terceiro acto é distribución no sentido ordinario.
Determine cal deses tres fai realmente a súa pila e despois aplique a regra que lle corresponde. As etiquetas de produto non deciden nada aquí, e o protocolo empregado tampouco é a proba.
Tres actos que pode realizar un proxy ou unha VPN
Unha pasarela acepta un fluxo TCP, reescribe enderezos e reenvía segmentos en ambos sentidos. Nada sobrevive á conexión no disco, e a carga útil permanece opaca para a pasarela a non ser que o cliente negocie TLS coa pasarela en lugar de coa orixe.
Un intermediario de caché funciona doutro xeito: analiza a petición, almacena a resposta durante un tempo de vida que calcula ou le das cabeceiras, e logo reproduce ese obxecto gardado a clientes posteriores. Agora existe algo fóra do cable, indexado por URL e validador, e a súa retención é unha decisión de configuración e non un efecto secundario.
A republicación vai un paso máis aló. O material está nunha infraestrutura que vostede controla, dirixido a un público que escolleu, a miúdo despois de editalo. Os dous primeiros actos describen transporte, mentres que o terceiro describe distribución.
| Acto | Que existe despois | Pregunta que decide o resultado |
|---|---|---|
| Levar un fluxo | Estado de tradución e buffers que duran segundos | Que disposición sobre intermediarios cobre a transmisión transitoria? |
| Gardar unha resposta | Un obxecto máis metadatos de frescura e validador | Estaban autorizadas a retención e a reprodución, e ata cando? |
| Servir a obra baixo a súa URL | Unha copia publicada dirixida a un público novo | Que permiso cobre a distribución a ese público? |
Onde un proxy que descifra converte o transporte en copia
A distinción que decide a maioría das discusións é se a caixa chega a ter texto en claro. Un túnel puro, xa sexa WireGuard, un dispositivo OpenVPN tun ou un reenvío SSH -L, move texto cifrado entre os extremos e non deixa nada lexible. Un proxy que remata TLS fai o contrario: completa o saúdo, almacena a resposta en memoria e despois volve cifrar o fluxo cara ao cliente. Entre esas operacións a obra existe nunha forma que o operador pode inspeccionar e conservar.
17 USC 106 enumera a reprodución e a distribución entre os dereitos exclusivos, cada un suxeito ás limitacións establecidas no mesmo título. Un buffer dun milisegundo pode encaixar nunha limitación sen discusión; un obxecto retido e reproducible é moito máis difícil de situar alí. A duración e a finalidade pesan máis que o feito de que se tocase a memoria.
Nada diso converte unha VPN nunha licenza, nin fai de todo proxy un infractor. O transporte é un feito entre varios, e a pregunta avaliable segue a ser a mesma: que acto, sobre material de quen, con que permiso.
As cabeceiras de caché describen permiso de protocolo, non permiso legal
Unha caché HTTP decide que pode almacenar a partir dos metadatos da resposta, e a RFC 9111 fixa as regras que segue. Cache-Control: no-store di a toda caché conforme que descarte a resposta, mentres que private limita a reutilización a un único usuario e un max-age longo convida ao almacenamento compartido. Unha soa petición dille que política escolleu unha orixe. Execútea antes de discutir calquera outra cousa.
curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'
Unha resposta que anuncia unha vida longa está a dicir ás cachés que a reprodución é aceptable no nivel do protocolo. Esa afirmación non di nada sobre se pode tomar o mesmo obxecto, realoxalo e integralo no seu propio servizo. Dous permisos distintos veñen de dous mecanismos distintos, e satisfacer un deixa o outro exactamente onde estaba.
O caso espello falla do mesmo xeito. HTTPS de extremo a extremo impide que unha caché transparente almacene nada, pero ese resultado nin crea un dereito a distribuír o material nin elimina un que xa tivese. O comportamento do protocolo explica que pode facer unha caixa; nunca outorga autorización.
Que deixar por escrito antes de que o servizo entre en produción
Describa o acordo en termos que un terceiro poida comprobar. Nomee o material e a súa fonte, enumere os actos que realiza o sistema e indique canto vive cada obxecto almacenado.
Garde esa descrición co despregamento e non na memoria de ninguén. Cando chega unha queixa, a diferenza entre unha posición defendible e unha suposición adoita ser un parágrafo escrito meses antes que nomea o período de retención e a licenza.
Unha lista breve de revisión cobre os ocos recorrentes:
- Fonte do material e as condicións asociadas.
- Cada acto realizado: reenviar, almacenar, editar, servir.
- Retención por clase de obxecto, en horas ou días.
- Permiso ou limitación en que se basea o paso de servir.
- Contacto e vía de retirada para os titulares de dereitos.
Pase a lista pola configuración en vivo, non polo diagrama de arquitectura. Onde falte unha resposta, ese oco é a seguinte tarefa: ou obtén permiso para o acto ou deixa de realizalo. Para un servizo comercial, faga que un avogado lea a descrición escrita fronte á xurisdición na que opera, porque a descrición é o que fai posible esa revisión. Todo o que non poida describir por escrito é unha posición que non pode defender.