Ці можа 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 не дазваляе празрыстаму кэшу нешта захоўваць, але гэты вынік не стварае права распаўсюджваць матэрыял і не адмяняе права, якое ў вас ужо было. Паводзіны пратаколу тлумачаць, што можа рабіць вузел; ён ніколі не дае дазволу.
Што запісаць да запуску сэрвісу
Апішыце ўмовы так, каб старонні чалавек мог іх праверыць. Назавіце матэрыял і яго крыніцу, пералічыце дзеянні, якія выконвае сістэма, і ўкажыце, колькі жыве кожны захаваны аб'ект.
Трымайце гэтае апісанне разам з разгортваннем, а не ў чыёйсьці памяці. Калі прыходзіць скарга, розніца паміж абараняльнай пазіцыяй і здагадкай — звычайна абзац, напісаны некалькі месяцаў таму, дзе названы тэрмін захавання і ліцэнзія.
Кароткі спіс для агляду закрывае тыповыя прабелы:
- Крыніца матэрыялу і ўмовы, якія да яго далучаны.
- Кожнае дзеянне: перадача, захаванне, рэдагаванне, падача.
- Тэрмін захавання па кожным класе аб'ектаў, у гадзінах або днях.
- Дазвол або абмежаванне, на якое абапіраецца этап падачы.
- Кантакт і шлях выдалення для праваўладальнікаў.
Праверце спіс супраць жывой канфігурацыі, а не супраць схемы архітэктуры. Дзе адказу не хапае, гэты прабел — наступная задача: або атрымайце дазвол на дзеянне, або перастаньце яго выконваць. Для камерцыйнага сэрвісу няхай юрыст прачытае пісьмовае апісанне ў святле юрысдыкцыі, у якой вы працуеце, бо менавіта апісанне робіць такі агляд магчымым. Усё, што вы не можаце апісаць пісьмова, — гэта пазіцыя, якую вы не можаце абараніць.