VPN이나 프록시가 저작권이 있는 콘텐츠를 복제할 수 있을까? 세 가지 행위
패킷 전달, 응답 캐싱, 재게시는 서로 다른 저작권 문제를 제기합니다. 서비스가 수행하는 행위를 그에 적용되는 규칙과 맞춰 보십시오.
패킷 전달, 캐싱, 재게시는 대시보드에서는 비슷해 보이지만 권리 문제가 닥치면 전혀 다르게 작동합니다. 사용자와 서버 사이에서 바이트를 옮기는 서비스는 한 가지 행위를 하고, 응답을 보관해 다음 방문자에게 건네는 서비스는 다른 행위를 합니다. 남의 자료를 자기 이름으로 게시하는 것은 세 번째 행위이며, 통상적인 의미의 배포는 오직 그 세 번째 행위뿐입니다.
여러분의 스택이 실제로 그 세 가지 중 무엇을 하는지 파악한 뒤, 그에 맞는 규칙을 붙이십시오. 제품 라벨은 여기서 아무것도 결정하지 못하며, 사용하는 프로토콜도 판단 기준이 아닙니다.
프록시나 VPN이 할 수 있는 세 가지 행위
게이트웨이는 TCP 흐름을 받아 주소를 다시 쓰고 세그먼트를 양방향으로 전달합니다. 연결이 끝나면 디스크에 남는 것은 없으며, 클라이언트가 원 서버가 아니라 게이트웨이와 TLS 협상을 하지 않는 한 페이로드는 게이트웨이에 불투명하게 남습니다.
캐싱 중개자는 다르게 작동합니다. 요청을 분석하고, 스스로 계산하거나 헤더에서 읽은 수명 동안 응답을 저장한 뒤, 저장된 객체를 이후 클라이언트에게 다시 제공합니다. 이제 회선 밖에 무언가가 존재하며 URL과 검증자로 식별되고, 그 보존은 부수 효과가 아니라 설정상의 선택입니다.
재게시는 한 걸음 더 나아갑니다. 자료는 여러분이 통제하는 인프라에, 여러분이 고른 대상에게, 흔히 편집을 거친 뒤 놓입니다. 처음 두 행위는 전송을 설명하고, 세 번째는 배포를 설명합니다.
| 행위 | 그 뒤에 남는 것 | 결과를 결정하는 질문 |
|---|---|---|
| 흐름 전달 | 몇 초 동안 유지되는 변환 상태와 버퍼 | 일시적 전송을 어떤 중개자 조항이 포괄하는가? |
| 응답 저장 | 객체와 신선도 및 검증자 메타데이터 | 보존과 재생이 허가되었는가, 그리고 언제까지인가? |
| 자기 URL 아래에서 저작물 제공 | 새로운 대상에게 보내는 게시된 사본 | 그 대상에게 배포하는 것을 어떤 허락이 포괄하는가? |
복호화 프록시가 전달을 복제로 바꾸는 지점
대부분의 논쟁을 결정하는 구분은 그 장비가 과연 평문을 보유하는가입니다. 순수한 터널은 WireGuard든 OpenVPN tun 장치든 SSH -L 포워드든, 종단 사이로 암호문을 옮기고 읽을 수 있는 것은 아무것도 남기지 않습니다. TLS를 종료하는 프록시는 정반대로 작동합니다. 핸드셰이크를 완료하고, 응답을 메모리에 버퍼링한 뒤, 클라이언트 쪽으로 스트림을 다시 암호화합니다. 그 작업들 사이에 저작물은 운영자가 들여다보고 보관할 수 있는 형태로 존재합니다.
17 USC 106은 복제와 배포를 배타적 권리로 열거하며, 각각 같은 법전에 규정된 제한을 받습니다. 밀리초 단위 버퍼는 별다른 논란 없이 제한 안에 들어갈 수 있지만, 보존되어 재생 가능한 객체는 그 자리에 놓기가 훨씬 어렵습니다. 지속 시간과 목적이 메모리를 스친 사실 자체보다 더 큰 무게를 가집니다.
그 어느 것도 VPN을 라이선스로 만들지 않고, 모든 프록시를 침해자로 만들지도 않습니다. 전송은 여러 사실 중 하나일 뿐이며, 평가 가능한 질문은 그대로입니다. 어떤 행위를, 누구의 자료에, 어떤 허락 아래에서 했는가.
캐시 헤더는 법적 허락이 아니라 프로토콜상의 허락을 설명한다
HTTP 캐시는 응답 메타데이터를 보고 무엇을 저장할 수 있는지 판단하며, RFC 9111이 그 규칙을 정합니다. Cache-Control: no-store는 규격을 따르는 모든 캐시에 응답을 버리라고 지시하고, private는 재사용을 한 사용자로 제한하며 긴 max-age는 공유 저장을 초대합니다. 요청 하나면 원 서버가 어떤 정책을 골랐는지 알 수 있습니다. 다른 논쟁을 하기 전에 그것부터 실행해 보십시오.
curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'
긴 수명을 알리는 응답은 재생이 프로토콜 수준에서 허용된다고 캐시들에게 말하는 것입니다. 그 진술은 같은 객체를 가져다 다시 호스팅하고 자기 서비스에 끼워 넣어도 되는지에 대해서는 아무 말도 하지 않습니다. 서로 다른 두 허락은 서로 다른 두 장치에서 나오며, 하나를 충족해도 다른 하나는 있던 자리에 그대로 있습니다.
반대의 경우도 같은 방식으로 실패합니다. 종단 간 HTTPS는 투명 캐시가 아무것도 저장하지 못하게 하지만, 그 결과가 자료를 배포할 권리를 새로 만들지도, 이미 가진 권리를 없애지도 않습니다. 프로토콜 동작은 장비가 무엇을 할 수 있는지 설명할 뿐, 권한을 공급하지는 않습니다.
서비스를 공개하기 전에 적어 둘 것
외부인이 확인할 수 있는 용어로 그 배열을 설명하십시오. 자료와 그 출처를 밝히고, 시스템이 수행하는 행위를 나열하고, 저장된 객체마다 얼마나 오래 사는지 적으십시오.
그 설명은 누군가의 기억이 아니라 배포와 함께 보관하십시오. 이의 제기가 들어왔을 때 방어 가능한 입장과 추측 사이의 간격은 대개 몇 달 전에 적어 둔, 보존 기간과 라이선스를 명시한 한 문단입니다.
짧은 점검 목록이 되풀이되는 구멍을 덮습니다.
- 자료의 출처와 그에 붙은 조건.
- 수행하는 각 행위: 전달, 저장, 편집, 제공.
- 객체 등급별 보존 기간, 시간 또는 일 단위.
- 제공 단계에서 의존하는 허락 또는 제한.
- 권리자 연락처와 게시 중단 경로.
목록은 아키텍처 다이어그램이 아니라 실제 운영 구성에 대고 돌려 보십시오. 답이 빠진 곳이 있다면 그 틈이 다음 과제입니다. 그 행위에 대한 허락을 받거나, 행위를 그만두십시오. 상업 서비스라면 변호사에게 작성된 설명을 여러분이 서비스하는 관할과 대조해 읽게 하십시오. 그 설명이 있어야 검토가 가능해지기 때문입니다. 글로 설명할 수 없는 것은 방어할 수 없는 입장입니다.