Может ли 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 не позволяет прозрачному кэшу что-либо хранить, но этот результат не создаёт права распространять материал и не отменяет того, что у вас уже было. Поведение протокола объясняет, что устройство может; оно никогда не даёт полномочий.
Что записать до запуска сервиса
Опишите схему словами, которые посторонний мог бы проверить. Назовите материал и его источник, перечислите действия, которые выполняет система, и укажите, сколько живёт каждый сохранённый объект.
Храните это описание вместе с развёртыванием, а не в чьей-то памяти. Когда приходит жалоба, разрыв между защитимой позицией и догадкой обычно представляет собой абзац, написанный месяцами раньше, в котором названы срок хранения и лицензия.
Короткий список проверки охватывает повторяющиеся пробелы:
- Источник материала и связанные с ним условия.
- Каждое выполняемое действие: передача, хранение, редактирование, предоставление.
- Хранение по классам объектов, в часах или днях.
- Разрешение или ограничение, на которое опирается шаг предоставления.
- Контакт и порядок удаления для правообладателей.
Прогоните список по работающей конфигурации, а не по схеме архитектуры. Там, где ответа нет, этот пробел и есть следующая задача: либо получите разрешение на действие, либо прекратите его выполнять. Для коммерческого сервиса попросите юриста прочитать письменное описание применительно к юрисдикции, в которой вы работаете, потому что именно описание делает такую проверку возможной. Всё, что вы не можете описать письменно, это позиция, которую вы не можете защитить.