Wydawcy prasowi w Stanach Zjednoczonych przenieśli spór z dostawcami modeli AI na poziom pośrednika, który dostarcza tym modelom dane. New York Times i inne spółki wydawnicze złożyły pozew przeciw Brave Software, zarzucając twórcy przeglądarki i wyszukiwarki nielegalne omijanie paywalli oraz sprzedaż treści firmom AI. Informację o pozwie opisała Ars Technica 3 listopada 2026 r., powołując się na dokument złożony w Sądzie Federalnym dla Południowego Dystryktu Nowego Jorku. To relacja redakcyjna, nie treść samego pozwu — i to rozróżnienie ma znaczenie dla oceny, jak mocne są poszczególne twierdzenia.

Sprawa dotyczy trzech grup: wydawców, którzy tracą kontrolę nad dostępem do swoich treści; pośredników indeksujących i odsprzedających dostęp do danych; oraz firm AI kupujących ten dostęp. Dla polskich odbiorców nie jest to spór, którego są bezpośrednio stroną — ale mechanizm, który opisuje, jest identyczny z tym, na którym opiera się część produktów wyszukiwawczych i asystenckich dostępnych nad Wisłą. Jeśli pozew doprowadzi do zmiany zasad, zmieni się nie tylko sytuacja Brave, ale też warunki, na jakich wydawcy i dostawcy narzędzi AI oceniają legalność źródeł danych.

Co dokładnie zarzuca pozew

Z relacji Ars Technica wynika, że pozew przypisuje Brave trzy rodzaje naruszenia praw autorskich: bezpośrednie, pośrednie (contributory) i zastępcze (vicarious). Zarzut bezpośredni dotyczy zbierania artykułów do indeksu wyszukiwania, funkcji „Ask Brave” oraz API udostępnianego innym firmom. Zarzut pośredni i zastępczy opiera się na twierdzeniu, że Brave „zachęca, ułatwia, kontroluje i czerpie zyski” z kopiowania treści przez użytkowników i klientów AI. Osobno pozew wskazuje na naruszenie DMCA przez obchodzenie technicznych zabezpieczeń dostępu.

W pozwie pojawia się sformułowanie, że Brave jest „dostawcą, dealerem i dystrybutorem” skradzionych treści. To retoryka strony powodowej, nie ustalenie sądu. Warto ją czytać jako tezę prawną do udowodnienia, a nie opis stanu faktycznego. Pozew powołuje się też na szacunki przychodów stron trzecich, według których Brave zarobił ponad 100 mln USD na kopiowaniu i odsprzedaży pracy wydawców. Ars Technica nie weryfikowała tych szacunków niezależnie.

Domyślnie włączona funkcja omijania paywalli

Najbardziej konkretny element relacji dotyczy funkcji przeglądarki. Według pozwu Brave Browser ma domyślnie włączoną opcję, która pozwala przejść za paywall i wyświetlić zastrzeżoną treść. Ars Technica sprawdziła to na macOS: funkcja „paywall blocker” była aktywna w ustawieniach domyślnych, można ją wyłączyć i pozwalała przeczytać artykuł NYT za paywallem. To niezależna obserwacja redakcji, nie deklaracja producenta — i jednocześnie jedyny opisany w materiale test działania funkcji.

Pozew zwraca też uwagę na model reklamowy: przeglądarka blokuje reklamy na stronie NYT i pokazuje własne, oferując użytkownikom udział w przychodach. Dla wydawcy to podwójna strata — brak dostępu do treści i brak przychodu z reklam, które finansują pracę redakcji. To twierdzenie strony powodowej; nie znamy stanowiska Brave, bo Ars Technica zwróciła się o komentarz i zadeklarowała aktualizację tekstu, jeśli firma odpowie.

Tło techniczne prostym językiem

Wyszukiwarka internetowa działa w uproszczeniu tak: robot pobiera strony, zapisuje je w indeksie, a potem na podstawie zapytań zwraca fragmenty i linki. Wydawca może w pliku robots.txt lub przez nagłówki HTTP poprosić o nieindeksowanie części serwisu. Paywall to warstwa techniczna, która ma uniemożliwić odczyt treści bez subskrypcji — realizowana przez serwer, skrypty w przeglądarce albo oba mechanizmy.

Funkcja omijania paywalli w przeglądarce działa na innym poziomie niż indeksowanie. Przeglądarka może modyfikować to, co widzi użytkownik, albo wykorzystywać luki w sposobie dostarczania treści. Z punktu widzenia prawa autorskiego istotne jest nie tylko to, czy treść została pobrana, ale czy doszło do obejścia skutecznego zabezpieczenia technicznego. Właśnie na tym opiera się zarzut z DMCA.

Drugi element to API wyszukiwania. Firma AI nie musi sama crawlingować całego internetu — może kupić dostęp do gotowego indeksu i otrzymywać wyniki w czasie rzeczywistym. Wtedy pojawia się pytanie o łańcuch odpowiedzialności: kto odpowiada za treść, którą pośrednik dostarczył klientowi. Pozew NYT odpowiada na to pytanie własną tezą: odpowiedzialność rozciąga się na pośrednika, bo czerpie zyski i kontroluje proces.

Dlaczego to ważne dla polskich wydawców i dostawców AI

Polski wydawca nie jest stroną tego pozwu i nie może na jego podstawie dochodzić roszczeń. Znaczenie sprawy jest pośrednie, ale realne. Po pierwsze, kształtuje narrację prawną wokół pośredników danych — a ta narracja przenika do orzecznictwa i praktyki regulatorów w Unii Europejskiej. Po drugie, pokazuje, że spór o treści dla AI nie kończy się na relacji wydawca–model, ale obejmuje ogniwa pośrednie: indeksy, API, funkcje przeglądarkowe.

Dla dostawcy narzędzi AI w Polsce oznacza to pytanie o due diligence dostawcy danych. Jeśli produkt korzysta z zewnętrznego indeksu, warto wiedzieć, jak ten indeks pozyskuje treści i czy respektuje ograniczenia dostępu. To nie jest kwestia wyłącznie prawna — to także kwestia ryzyka reputacyjnego i ciągłości produktu, jeśli dostawca zmieni warunki lub zostanie objęty zakazem.

Deklaracje producenta a niezależne obserwacje

W materiale nie ma stanowiska Brave. Są twierdzenia powodów i jedna niezależna obserwacja redakcyjna dotycząca działania funkcji. To asymetria, którą trzeba jawnie zaznaczyć: nie wiemy, jak Brave opisuje tę funkcję w dokumentacji, jakie ma uzasadnienie prawne i czy uznaje ją za domyślnie włączoną w każdym scenariuszu instalacji. Wszelkie wnioski o intencjach firmy byłyby spekulacją.

Realne konsekwencje

Skutki prawne rozstrzygnie sąd, a sprawa jest na wczesnym etapie. Realne konsekwencje rynkowe są jednak widoczne już teraz, niezależnie od wyroku.

Wzrost kosztu pozyskania danych. Jeśli pośrednicy będą musieli licencjonować treści lub ograniczać zakres indeksowania, dostęp do danych stanie się droższy i bardziej sformalizowany.
Większa nieufność do gotowych indeksów. Firmy budujące produkty AI będą częściej pytać o pochodzenie danych i mechanizmy respektowania paywalli.
Presja na funkcje przeglądarkowe. Domyślnie włączone mechanizmy ingerujące w treść strony stają się elementem oceny ryzyka, nie tylko funkcją marketingową.
Efekt domina w pozwach. Ars Technica opisuje podobny pozew złożony tego samego dnia przez New York Daily News, Chicago Tribune i Orlando Sentinel. To sygnał, że wydawcy testują wspólną strategię procesową.

Warto odróżnić odpowiedzialność karną od cywilnej. Pozew NYT ma charakter cywilny: żąda stałego zakazu, odszkodowania ustawowego i rzeczywistego oraz zwrotu zysków. To roszczenia finansowe i strukturalne, nie sankcje karne.

Scenariusze ryzyka

Poniższa tabela porządkuje scenariusze, nie przesądza o ich prawdopodobieństwie. To narzędzie do planowania, nie prognoza.

Scenariusz	Co się zmienia	Kto odczuwa skutek
Sąd nakazuje wyłączenie funkcji omijania paywalli	Przeglądarka traci funkcję lub zmienia domyślne ustawienie	Użytkownicy, wydawcy, pośrednicy
Ugoda obejmująca licencjonowanie treści	Pojawia się model opłat za dostęp do indeksu	Dostawcy AI, wydawcy, pośrednicy
Oddalenie powództwa w części dotyczącej pośrednika	Umacnia się model „pośrednik nie odpowiada za klienta”	Wydawcy, dostawcy AI
Brak rozstrzygnięcia przez lata	Niepewność utrzymuje się, umowy są ostrożniejsze	Wszyscy w łańcuchu

Osobny wątek to równoległe sprawy. Perplexity nie jest pozwanym w sprawie Brave, ale jest pozwanym w odrębnym pozwie NYT z grudnia 2025 r. i zaprzecza zarzutom. W materiale Ars Technica cytuje oświadczenie Perplexity, które nazywa pozew „dezinformacją”, ale nie wskazuje konkretnych nieścisłości. To istotne: spór o fakty w sprawie Brave i spór o fakty w sprawie Perplexity to dwa różne postępowania, których nie należy mieszać.

Jak sprawdzić, czy problem dotyczy Twojej organizacji

Nie chodzi o to, czy jesteś pozwanym — prawdopodobnie nie jesteś. Chodzi o to, czy Twoje produkty lub procesy zależą od mechanizmów opisanych w pozwie.

Zidentyfikuj zewnętrzne indeksy. Wypisz wszystkie źródła danych wyszukiwawczych i treściowych, z których korzystają Twoje produkty, w tym API i gotowe indeksy.
Sprawdź warunki dostawcy. Przeczytaj, jak dostawca opisuje pozyskiwanie treści, respektowanie robots.txt i paywalli oraz odpowiedzialność za naruszenia.
Sprawdź własne funkcje przeglądarkowe. Jeśli masz rozszerzenie lub przeglądarkę, ustal, czy jakakolwiek funkcja modyfikuje treść strony lub obchodzi zabezpieczenia dostępu i czy jest włączona domyślnie.
Sprawdź umowy z klientami. Ustal, czy klauzule o odpowiedzialności za treści pokrywają scenariusz, w którym źródło danych zostanie zakwestionowane.
Sprawdź procesy redakcyjne. Jeśli publikujesz treści, ustal, czy masz wdrożone techniczne środki ograniczania dostępu i czy są skuteczne.

Plan reakcji krok po kroku

Plan jest celowo ostrożny. Nie zakłada winy żadnej ze stron ani rozstrzygnięcia prawnego.

Dzień 1: inwentaryzacja. Sporządź listę dostawców danych i funkcji, które mogą wchodzić w zakres opisanego ryzyka.
Dzień 2–3: analiza umów. Sprawdź klauzule o odpowiedzialności, prawach własności i procedurach zgłaszania naruszeń.
Dzień 4–5: pytania do dostawców. Wyślij pisemne pytania o sposób pozyskiwania treści i respektowanie ograniczeń dostępu. Zachowaj odpowiedzi.
Tydzień 2: ocena funkcji produktowych. Ustal, czy jakakolwiek funkcja domyślnie ingeruje w treść stron, i udokumentuj decyzję o jej pozostawieniu lub wyłączeniu.
Tydzień 3: plan awaryjny. Przygotuj wariant produktu lub komunikacji na wypadek nagłej zmiany warunków przez dostawcę.
Na bieżąco: monitoring. Śledź rozwój sprawy i podobnych postępowań, ale nie podejmuj decyzji wyłącznie na podstawie nagłówków.

Typowe błędy

Traktowanie relacji prasowej jak wyroku. Pozew to twierdzenia strony powodowej. Nie ma jeszcze rozstrzygnięcia.
Mylenie spraw. Pozew przeciw Brave, pozew przeciw Perplexity i pozew przeciw OpenAI i Microsoft to odrębne postępowania z różnymi zarzutami.
Zakładanie, że pośrednik „tylko przekazuje dane”. Właśnie ten model odpowiedzialności jest przedmiotem sporu.
Pomijanie funkcji domyślnych. Ustawienie domyślne zmienia ocenę ryzyka, bo działa bez świadomej decyzji użytkownika.
Brak dokumentacji. Bez pisemnych odpowiedzi dostawców trudno wykazać należytą staranność.

Działania krótkoterminowe i długoterminowe

Krótkoterminowo (do 30 dni)

Zbierz dokumentację dostawców danych i warunków API.
Ustal, czy w Twoich produktach istnieją funkcje ingerujące w treść stron, i opisz ich działanie.
Przejrzyj klauzule umowne pod kątem odpowiedzialności za treści.
Przygotuj wewnętrzną notatkę o ryzyku — bez publicznych deklaracji, dopóki nie znasz stanowiska dostawców.

Długoterminowo (3–12 miesięcy)

Wprowadź zasadę oceny dostawców danych przed wdrożeniem nowego produktu.
Rozważ dywersyfikację źródeł danych, aby ograniczyć zależność od jednego indeksu.
Ustal proces reagowania na zgłoszenia wydawców i właścicieli treści.
Śledź orzecznictwo i praktykę regulatorów w UE, bo krajowe ramy prawne mogą się zmieniać szybciej niż sprawa w Nowym Jorku.

Praktyczna checklista

Mam listę wszystkich zewnętrznych indeksów i API wykorzystywanych w produktach.
Znam warunki, na jakich dostawca pozyskuje treści.
Wiem, czy jakakolwiek funkcja działa domyślnie i ingeruje w treść stron.
Mam pisemne odpowiedzi dostawców na pytania o respektowanie paywalli i robots.txt.
Umowy z klientami określają odpowiedzialność za treści.
Mam plan awaryjny na wypadek zmiany warunków przez dostawcę.
Wiem, kto w organizacji odpowiada za zgłoszenia naruszeń.

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy: potraktuj to jako pytanie o zależność, nie o winę. Ustal, jaka część produktu opiera się na zewnętrznych danych i jak szybko można ją zastąpić. Zapytaj zespół, czy znamy warunki dostawcy i czy mamy dowody na należyte sprawdzenie źródła. Nie ogłaszaj publicznie stanowiska, dopóki nie masz odpowiedzi od dostawców — pośpiech w komunikacji przy niepewnym stanie prawnym zwykle szkodzi.

Administrator: sprawdź konfigurację funkcji przeglądarkowych i rozszerzeń w organizacji. Ustal, czy jakiekolwiek narzędzie domyślnie modyfikuje treść stron lub obchodzi zabezpieczenia dostępu, i udokumentuj decyzję. Zabezpiecz logi i konfiguracje, które mogą być potrzebne, jeśli dostawca zmieni warunki. Zweryfikuj, czy polityki wewnętrzne obejmują korzystanie z zewnętrznych indeksów w produktach.

Czego nie wiadomo

Materiał opiera się na relacji Ars Technica, nie na treści samego pozwu. Nie znamy pełnej listy zarzutów, załączników ani stanowiska Brave. Nie wiemy, jak sąd oceni zarzut z DMCA ani czy uzna funkcję przeglądarki za obejście skutecznego zabezpieczenia. Nie wiemy, czy szacunki przychodów powołane w pozwie są rzetelne. Nie wiemy też, jak zakończą się równoległe sprawy. Każde twierdzenie o „przełomie” byłoby przedwczesne — to spór, który dopiero się otwiera.

Weryfikacja praktyczna: jak przełożyć zarzuty na testy w organizacji

Weryfikacja nie polega na ocenie, kto ma rację w sporze. Polega na sprawdzeniu, czy mechanizmy opisane w pozwie występują w Twoim środowisku i czy potrafisz to udokumentować. Poniższe testy wykonuj na kopii środowiska lub w kontrolowanych warunkach, nie na produkcji.

Test 1: czy funkcja przeglądarki ingeruje w treść strony

Zainstaluj przeglądarkę lub rozszerzenie w wersji, którą realnie dopuszczasz w organizacji.
Sprawdź ustawienia domyślne bez ich zmiany — w materiale Ars Technica funkcja omijania paywalli była włączona domyślnie i można ją było wyłączyć.
Otwórz stronę z ograniczonym dostępem i ustal, czy treść jest widoczna bez autoryzacji.
Zapisz wynik: nazwa funkcji, stan domyślny, efekt, data testu, osoba wykonująca.
Powtórz test po wyłączeniu funkcji, aby mieć punkt odniesienia.

Wynik testu nie rozstrzyga o legalności. Daje jednak fakt, a nie domysł. W sporze opisanym przez Ars Technica kluczowe było właśnie to, że funkcja działała domyślnie.

Test 2: czy produkt korzysta z zewnętrznego indeksu

Wypisz każdy komponent, który pobiera dane wyszukiwawcze lub treściowe z zewnątrz.
Dla każdego komponentu wskaż dostawcę, wersję API i sposób uwierzytelniania.
Ustal, czy umowa lub dokumentacja dostawcy opisuje pochodzenie treści.
Zaznacz komponenty, dla których nie masz żadnej pisemnej odpowiedzi dostawcy.

Pozew cytowany przez Ars Technica wskazuje na model, w którym dostawca indeksu sprzedaje dostęp do treści firmom AI. Jeśli Twój produkt korzysta z podobnego indeksu, pytanie o pochodzenie danych nie jest teoretyczne.

Test 3: czy umowy pokrywają scenariusz zakwestionowania źródła

Zbierz umowy z dostawcami danych i klientami.
Zaznacz klauzule o prawach własności, odpowiedzialności za treści i procedurach zgłaszania naruszeń.
Sprawdź, czy umowa przewiduje skutki, gdy dostawca zmieni warunki lub zostanie pozwany.
Zanotuj luki: brak klauzuli to też wynik weryfikacji.

Monitoring po wdrożeniu: co śledzić i jak często

Monitoring nie może opierać się na nagłówkach. Potrzebujesz rytmu i źródła. Poniższy harmonogram zakłada, że masz już wdrożony produkt lub proces i chcesz utrzymać kontrolę nad ryzykiem opisanym w materiale Ars Technica.

Rytm tygodniowy

Przegląd nowych doniesień o sprawie Brave i sprawach równoległych — bez wyciągania wniosków prawnych.
Sprawdzenie, czy dostawcy indeksów nie zmienili warunków lub dokumentacji.
Zapis w rejestrze ryzyka: data, źródło, co się zmieniło, czy dotyczy naszych komponentów.

Rytm miesięczny

Weryfikacja, czy lista zewnętrznych indeksów i API jest aktualna.
Przegląd zgłoszeń od wydawców lub właścicieli treści — nawet pojedyncze zgłoszenie jest sygnałem.
Test kontrolny funkcji przeglądarkowych i rozszerzeń dopuszczonych w organizacji.
Aktualizacja planu awaryjnego: czy mamy alternatywne źródło danych i ile czasu zajmie przełączenie.

Rytm kwartalny

Przegląd umów pod kątem nowych klauzul i zmian regulaminów dostawców.
Ocena, czy równoległe postępowania (m.in. pozew NYT przeciw Perplexity z grudnia 2025 r.) zmieniają krajobraz ryzyka.
Szkolenie zespołu: co wolno włączać w produktach, czego nie wolno domyślnie.

Rejestr monitoringu — minimalne pola

Data wpisu i osoba odpowiedzialna.
Źródło informacji i link.
Czego dotyczy: funkcja, dostawca, umowa, zgłoszenie.
Ocena: dotyczy / nie dotyczy / do wyjaśnienia.
Działanie podjęte i termin ponownej weryfikacji.

Rejestr ma znaczenie praktyczne: bez niego nie wykażesz należytej staranności, gdy pojawi się pytanie o to, jak sprawdzałeś źródło danych.

Checklisty operacyjne po wdrożeniu

Checklisty są krótkie celowo. Mają być wykonane, nie przeglądane. Każda pozycja wymaga wyniku „tak”, „nie” lub „brak danych” — trzecia odpowiedź jest równie ważna jak dwie pierwsze.

Checklista dla zespołu produktu

Czy każdy zewnętrzny indeks ma przypisanego właściciela wewnętrznego?
Czy znamy wersję API i warunki jej użycia?
Czy wiemy, czy dostawca respektuje ograniczenia dostępu do treści?
Czy jakakolwiek funkcja działa domyślnie i modyfikuje treść strony?
Czy decyzja o pozostawieniu takiej funkcji jest udokumentowana?
Czy mamy alternatywne źródło danych dla każdego krytycznego komponentu?
Czy klauzule umowne pokrywają scenariusz zakwestionowania źródła?
Czy wiemy, kto odbiera zgłoszenia od wydawców?

Checklista dla administratora

Czy inwentarz przeglądarek i rozszerzeń w organizacji jest aktualny?
Czy sprawdzono ustawienia domyślne tych narzędzi?
Czy logi konfiguracji są zabezpieczone i dostępne na wypadek sporu?
Czy polityki wewnętrzne obejmują korzystanie z zewnętrznych indeksów?
Czy istnieje procedura szybkiego wyłączenia funkcji ingerującej w treść stron?

Checklista dla zespołu prawnego i zakupów

Czy każda umowa z dostawcą danych zawiera opis pochodzenia treści?
Czy umowy przewidują skutki zmiany warunków przez dostawcę?
Czy mamy pisemne odpowiedzi dostawców na pytania o paywalle i robots.txt?
Czy wiemy, jak odróżnić sprawę Brave od sprawy Perplexity i innych postępowań?
Czy plan komunikacji na wypadek pozwu lub zgłoszenia jest gotowy?

Jak dokumentować weryfikację, żeby miała wartość

Dokumentacja bez daty i autora jest bezużyteczna. W materiale Ars Technica kluczowe znaczenie mają fakty: funkcja była włączona domyślnie, można ją było wyłączyć, podobny pozew złożono tego samego dnia. Twoja dokumentacja powinna mieć podobną precyzję.

Zapisuj datę i godzinę testu oraz wersję narzędzia.
Dołączaj zrzuty ekranu lub zrzuty konfiguracji.
Oddzielaj fakty od ocen — ocena prawna nie należy do zespołu technicznego.
Przechowuj odpowiedzi dostawców w formie, w jakiej je otrzymałeś.
Wersjonuj dokumentację, aby było widać, co się zmieniło i kiedy.

Nie zakładaj, że dostawca „na pewno” respektuje ograniczenia. W sporze opisanym przez Ars Technica to właśnie założenia stały się przedmiotem zarzutów. Dokumentacja zamienia założenie w sprawdzony fakt albo w jawnie oznaczoną lukę.

Progi eskalacji wewnętrznej

Nie każda informacja wymaga reakcji. Potrzebujesz progów, które zdejmują decyzję z barków jednej osoby.

Poziom informacyjny: nowe doniesienie o sprawie, bez wpływu na nasze komponenty — wpis do rejestru.
Poziom uwagi: dostawca zmienia warunki lub dokumentację — pytanie pisemne i przegląd umowy.
Poziom działania: zgłoszenie od wydawcy lub zmiana funkcji u dostawcy — analiza wpływu i plan awaryjny w ciągu dni, nie tygodni.
Poziom krytyczny: pozew lub wezwanie dotyczące naszego produktu — natychmiastowe zaangażowanie zespołu prawnego i wstrzymanie zmian w komponencie.

Progi działają tylko wtedy, gdy są znane zespołowi przed zdarzeniem. Ustal je teraz, nie w momencie otrzymania pisma.

Pytania kontrolne do dostawców danych

Pytania zadawaj pisemnie i zachowuj odpowiedzi. Nie muszą być konfrontacyjne — mają ustalić fakty.

Jak pozyskujecie treści do indeksu i czy respektujecie ograniczenia dostępu?
Czy Wasza dokumentacja opisuje sposób traktowania paywalli i robots.txt?
Jakie są skutki umowne, jeśli źródło treści zostanie zakwestionowane?
Czy informujecie klientów o zmianach w sposobie pozyskiwania danych?
Kto odpowiada za zgłoszenia właścicieli treści po Waszej stronie?

Brak odpowiedzi jest informacją. Odnotuj ją w rejestrze i uwzględnij w ocenie ryzyka.

Utrzymanie po wdrożeniu: zasady trwałe

Żadna nowa funkcja ingerująca w treść stron nie wchodzi domyślnie bez udokumentowanej decyzji.
Każdy zewnętrzny indeks ma właściciela, umowę i wpis w rejestrze ryzyka.
Zgłoszenia od wydawców trafiają do jednej osoby i mają termin odpowiedzi.
Plan awaryjny jest testowany, nie tylko opisany.
Monitoring sprawy Brave i postępowań równoległych jest częścią rutynowego przeglądu, nie reakcją na nagłówek.

Te zasady nie rozstrzygają sporu prawnego. Ograniczają jednak sytuację, w której organizacja dowiaduje się o ryzyku dopiero z pozwu — a to jest cały sens weryfikacji i monitoringu po wdrożeniu.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

NYT demands Brave shut down its paywall blocker and end deals with AI firms (arstechnica.com)

Zdjęcie wyróżniające: Sora Shimazaki / Pexels.

Pozew NYT przeciw Brave: czy odsprzedaż treści firmom AI to nowy model ryzyka dla wydawców i dostawców AI