Czy VPN lub proxy może kopiować treści chronione prawem autorskim? Trzy działania
Przekazywanie pakietów, buforowanie odpowiedzi i ponowne publikowanie rodzą odrębne pytania z zakresu prawa autorskiego. Dopasuj działanie wykonywane przez Twój serwis do reguły, która je reguluje.
Przekazywanie pakietów, buforowanie i ponowne publikowanie wyglądają tak samo na pulpicie, a zachowują się zupełnie inaczej, gdy pojawia się pytanie o prawa. Usługa, która przenosi bajty między użytkownikiem a serwerem, wykonuje jedno działanie, a ta, która zachowuje odpowiedź i podaje ją kolejnemu odwiedzającemu, wykonuje inne. Publikowanie cudzego materiału pod własnym nazwiskiem to trzecie działanie i tylko ono jest rozpowszechnianiem w zwykłym sensie.
Ustal, które z tych trzech naprawdę wykonuje Twój stos technologiczny, a następnie przypisz do niego pasującą regułę. Etykiety produktów nic tu nie rozstrzygają, a używany protokół też nie jest kryterium.
Trzy działania, które może wykonać proxy lub VPN
Brama przyjmuje strumień TCP, przepisuje adresy i przekazuje segmenty w obu kierunkach. Po połączeniu nic nie zostaje na dysku, a ładunek pozostaje dla bramy nieprzejrzysty, chyba że klient negocjuje TLS z bramą, a nie z serwerem źródłowym.
Pośrednik buforujący działa inaczej: analizuje żądanie, przechowuje odpowiedź przez czas życia, który wylicza lub odczytuje z nagłówków, a następnie odtwarza ten zapisany obiekt kolejnym klientom. Coś istnieje teraz poza łączem, oznaczone adresem URL i walidatorem, a jego przechowywanie jest wyborem konfiguracyjnym, nie efektem ubocznym.
Ponowne publikowanie idzie o krok dalej. Materiał leży na infrastrukturze, którą kontrolujesz, zaadresowany do wybranej przez Ciebie publiczności, często po edycji. Pierwsze dwa działania opisują transport, trzecie opisuje rozpowszechnianie.
| Działanie | Co istnieje potem | Pytanie, które rozstrzyga wynik |
|---|---|---|
| Przenoszenie strumienia | Stan tłumaczenia i bufory trwające sekundy | Który przepis o pośrednikach obejmuje przekaz przejściowy? |
| Przechowywanie odpowiedzi | Obiekt oraz metadane świeżości i walidatora | Czy przechowywanie i odtwarzanie były dozwolone, i do kiedy? |
| Udostępnianie utworu pod własnym adresem URL | Opublikowana kopia zaadresowana do nowej publiczności | Które pozwolenie obejmuje rozpowszechnianie tej publiczności? |
Gdzie proxy odszyfrowujące zamienia przekaz w kopiowanie
Różnica, która rozstrzyga większość sporów, dotyczy tego, czy urządzenie kiedykolwiek przechowuje tekst jawny. Czysty tunel, czy to WireGuard, urządzenie OpenVPN tun, czy przekierowanie SSH -L, przenosi tekst zaszyfrowany między punktami końcowymi i nie zostawia nic czytelnego. Proxy kończące TLS robi odwrotnie: kończy uzgadnianie, buforuje odpowiedź w pamięci, a następnie ponownie szyfruje strumień w stronę klienta. Między tymi operacjami utwór istnieje w formie, którą operator może obejrzeć i zachować.
17 USC 106 wymienia zwielokrotnianie i rozpowszechnianie wśród praw wyłącznych, a każde z nich podlega ograniczeniom wskazanym w tym samym kodeksie. Bufor milisekundowy może bez sporu zmieścić się w ograniczeniu; zachowany obiekt, który można odtworzyć, dużo trudniej tam umieścić. Czas trwania i cel ważą więcej niż sam fakt dotknięcia pamięci.
Nic z tego nie czyni z VPN licencji ani z każdego proxy naruszającego prawa. Transport jest jednym faktem wśród kilku, a pytanie podlegające ocenie pozostaje to samo: jakie działanie, na czyim materiale, na jakim pozwoleniu.
Nagłówki pamięci podręcznej opisują pozwolenie protokołu, a nie pozwolenie prawne
Pamięć podręczna HTTP decyduje z metadanych odpowiedzi, co może zapisać, a RFC 9111 ustala reguły, których przestrzega. Cache-Control: no-store każe każdej zgodnej pamięci odrzucić odpowiedź, a private ogranicza ponowne użycie do jednego użytkownika i długi max-age zaprasza do współdzielonego przechowywania. Jedno żądanie pokaże, jaką politykę wybrał serwer źródłowy. Uruchom je, zanim zaczniesz spierać się o cokolwiek innego.
curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'
Odpowiedź reklamująca długi czas życia mówi pamięciom, że odtwarzanie jest dopuszczalne na poziomie protokołu. To stwierdzenie nie mówi nic o tym, czy możesz wziąć ten sam obiekt, przenieść go na własny hosting i włączyć do własnej usługi. Dwa różne pozwolenia pochodzą z dwóch różnych mechanizmów, a spełnienie jednego zostawia drugie dokładnie tam, gdzie było.
Przypadek lustrzany zawodzi tak samo. HTTPS od końca do końca uniemożliwia przezroczystej pamięci cokolwiek zapisać, ale ten wynik nie tworzy prawa do rozpowszechniania materiału ani nie odbiera prawa, które już miałeś. Zachowanie protokołu wyjaśnia, co urządzenie może; nigdy nie dostarcza upoważnienia.
Co zapisać, zanim usługa ruszy
Opisz ten układ słowami, które osoba z zewnątrz mogłaby sprawdzić. Wskaż materiał i jego źródło, wymień działania wykonywane przez system i podaj, jak długo żyje każdy zapisany obiekt.
Trzymaj ten opis razem z wdrożeniem, a nie w czyjejś pamięci. Gdy nadchodzi skarga, luka między pozycją do obrony a domysłem to zwykle akapit napisany miesiące wcześniej, który nazywa okres przechowywania i licencję.
Krótka lista przeglądowa obejmuje powtarzające się dziury:
- Źródło materiału i warunki z nim związane.
- Każde wykonywane działanie: przekazywanie, przechowywanie, edycja, udostępnianie.
- Przechowywanie według klasy obiektów, w godzinach lub dniach.
- Pozwolenie lub ograniczenie, na którym opiera się krok udostępniania.
- Kontakt i ścieżka usunięcia dla posiadaczy praw.
Przejrzyj listę pod kątem działającej konfiguracji, a nie schematu architektury. Tam, gdzie brakuje odpowiedzi, ta luka jest następnym zadaniem: albo uzyskaj pozwolenie na działanie, albo przestań je wykonywać. W usłudze komercyjnej każ prawnikowi przeczytać pisemny opis w świetle jurysdykcji, w której działasz, bo to ten opis umożliwia przegląd. Wszystko, czego nie umiesz opisać na piśmie, jest pozycją, której nie umiesz obronić.