Чи може 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 не дає прозорому кешу будь-що зберігати, але цей результат не створює права розповсюджувати матеріал і не скасовує того, що ви вже мали. Поведінка протоколу пояснює, що пристрій може; вона ніколи не надає повноважень.
Що записати до запуску сервісу
Опишіть схему словами, які стороння людина могла б перевірити. Назвіть матеріал і його джерело, перелічіть дії, які виконує система, і зазначте, скільки живе кожен збережений об'єкт.
Тримайте цей опис разом із розгортанням, а не в чиїйсь пам'яті. Коли надходить скарга, розрив між захищеною позицією й здогадом зазвичай є абзацом, написаним місяці тому, у якому названо строк зберігання й ліцензію.
Короткий список перевірки охоплює повторювані прогалини:
- Джерело матеріалу та пов'язані з ним умови.
- Кожна виконувана дія: пересилання, зберігання, редагування, надання.
- Зберігання за класами об'єктів, у годинах або днях.
- Дозвіл або обмеження, на яке спирається крок надання.
- Контакт і шлях видалення для правовласників.
Проженіть список за робочою конфігурацією, а не за схемою архітектури. Там, де відповіді немає, ця прогалина є наступним завданням: або отримайте дозвіл на дію, або припиніть її виконувати. Для комерційного сервісу дайте юристу прочитати письмовий опис щодо юрисдикції, у якій ви працюєте, бо саме опис уможливлює цю перевірку. Усе, що ви не можете описати письмово, є позицією, яку ви не можете захистити.