Scraping treści z serwisów WWW w świetle orzecznictwa o bazach danych

Punkt wyjścia: czym jest scraping i jak łączy się z prawem baz danych

Techniczne minimum – jak działa scraping i crawling

Scraping treści z serwisów WWW to zautomatyzowane pobieranie danych ze stron internetowych przy użyciu skryptów lub dedykowanych narzędzi. Robot nie „ogląda” strony jak człowiek – analizuje kod HTML, wyciąga z niego konkretne fragmenty i zapisuje je w lokalnej bazie danych. Można to robić jednorazowo albo w trybie ciągłym, np. co kilka minut lub godzin.

Przydaje się tu rozróżnienie dwóch pojęć:

• crawling – automatyczne przechodzenie po linkach, skanowanie struktury serwisu, budowanie mapy adresów URL; celem jest odnalezienie stron i zasobów,
• scraping – faktyczne „wyjęcie” treści ze strony i zapisanie jej do dalszego wykorzystania (np. jako rekordy w bazie danych, plik CSV, zasilenie algorytmu).

W praktyce te procesy często się łączą: crawler odnajduje nowe podstrony, a moduł scraper wyciąga z nich dane (np. tytuł oferty, cenę, opis, zdjęcia). Z perspektywy prawa baz danych kluczowy jest drugi etap, bo to on prowadzi do pozyskania (extraction) elementów cudzej bazy i ewentualnie ich wtórnego wykorzystania (re-utilisation).

Scraping bywa realizowany na kilka sposobów technicznych:

• prosty parsing HTML (np. z użyciem bibliotek typu BeautifulSoup, Cheerio),
• symulacja przeglądarki (np. z wykorzystaniem headless Chrome, Playwright, Puppeteer),
• bazowanie na oficjalnych API (gdzie „scraping” sprowadza się do wykorzystania udostępnionych punktów końcowych),
• analiza ruchu sieciowego i odtwarzanie zapytań do wewnętrznych API serwisu.

Z punktu widzenia orzecznictwa o bazach danych zwykle nie ma znaczenia, którą technikę zastosowano. Liczy się rezultat: czy w efekcie powstaje kopia istotnej części bazy danych innego podmiotu lub zestaw nieistotnych części pobieranych w sposób systematyczny.

Typowe zastosowania scrapingu a ryzyka prawne

Web scraping jest narzędziem biznesowym, nie tylko „techniczną sztuczką”. Kilka typowych scenariuszy, w których regularnie pojawiają się spory prawne:

• agregatory ofert i ogłoszeń – serwisy, które zaciągają ogłoszenia z wielu portali (nieruchomości, praca, motoryzacja), tworząc własne przeszukiwalne bazy,
• porównywarki cen – automatyczne pobieranie cen z e‑sklepów, często w krótkich interwałach, aby oferować aktualne zestawienia,
• monitoring mediów i social mediów – systemy śledzące publikacje prasowe, wpisy na forach czy platformach, budujące raporty i analizy,
• analityka rynku – narzędzia śledzące dostępność produktów, zmiany cenników, parametry techniczne, które potem zasilają raporty B2B.

W każdym z tych przypadków scraper operuje na zorganizowanych zbiorach informacji utrzymywanych przez inny podmiot. To automatycznie uruchamia pytania o:

• prawo autorskie – czy zbierane elementy (teksty, zdjęcia, grafiki) są utworami,
• sui generis prawo do bazy danych – czy źródłowy serwis jest bazą danych chronioną na gruncie dyrektywy 96/9/WE i polskiej ustawy,
• prawo zobowiązań i umów – naruszenie regulaminu, NDA, licencji, warunków API,
• RODO i dobra osobiste – gdy dane zawierają elementy pozwalające na identyfikację osób lub ich ocenę.

Zderzenie techniki z prawem następuje zatem w kilku warstwach naraz. Zaniedbanie choćby jednej z nich potrafi zniweczyć cały projekt, nawet jeśli pozostałe są przygotowane wzorowo.

Krok 1: identyfikuj, co faktycznie jest pobierane

Pierwszy praktyczny krok przed wdrożeniem scrapera to bardzo przyziemna analiza: jakiego typu dane mają być pobierane. Od tego zależy zarówno rodzaj ochrony prawnej, jak i wysokość ryzyka.

Najprościej podzielić pobierane dane na kategorie:

• treści chronione prawem autorskim – rozbudowane opisy, artykuły, zdjęcia, grafiki, elementy layoutu,
• proste informacje i liczby – ceny, daty, parametry techniczne, statusy, które same w sobie nie są utworami,
• struktury i relacje – sposób ułożenia kategorii, powiązania między rekordami, system tagów,
• dane osobowe – nazwiska, numery telefonów, adresy e‑mail, informacje z profili użytkowników.

Od strony prawa baz danych kluczowe jest pytanie, czy serwis źródłowy to baza danych w rozumieniu dyrektywy, czy raczej zestaw pojedynczych utworów lub informacji publikowanych bez złożonej struktury. Inne będzie też ryzyko przy hurtowym kopiowaniu pełnych artykułów prasowych, a inne przy sporadycznym pobieraniu samych cen.

Co sprawdzić na etapie planowania scrapingu

Przy planowaniu projektu web scrapingu pomocna jest krótka checklista. Wprowadzenie jej jako standardu compliance znacząco zmniejsza ryzyko nieświadomego wejścia w konflikt z prawem baz danych.

• Jaki jest rodzaj danych do pobrania: teksty, liczby, zdjęcia, struktury, dane osobowe?
• Jak często dane mają być pobierane: jednorazowo, okresowo, ciągle, w czasie zbliżonym do rzeczywistego?
• Jaki jest zasięg: cała zawartość serwisu, określony segment (tylko wybrane kategorie), czy pojedyncze rekordy?
• Czy dane będą przechowywane i przeszukiwane jako odrębna baza, czy tylko „przeczytane” i użyte do obliczeń/analiz?
• Czy istnieją alternatywne, legalne źródła: oficjalne API, płatne licencje, kanały partnerskie?

Co sprawdzić: czy w planowanym projekcie dominują proste dane i fakty, czy raczej przetwarzane będą kompletnie zorganizowane zbiory cudzych rekordów, w sposób zbliżony do funkcjonowania samego serwisu źródłowego. Im bliżej tego drugiego scenariusza, tym większa szansa, że orzecznictwo o bazach danych będzie miało zastosowanie.

Podstawy prawne: prawo baz danych i prawo autorskie w tle scrapingu

Pojęcie bazy danych w prawie UE i w polskiej ustawie

Dyrektywa 96/9/WE daje wspólnotową definicję bazy danych: to zbiór utworów, danych lub innych materiałów, zgromadzonych w sposób systematyczny lub metodyczny i indywidualnie dostępnych środkami elektronicznymi lub innymi. Polish ustawa o prawie autorskim przejmuje tę konstrukcję. Kluczowe są tu trzy elementy:

• zbiór – musi istnieć pewna mnogość danych lub materiałów, a nie tylko pojedynczy utwór,
• systematyczność lub metodyczność – dane są uporządkowane według określonego kryterium, umożliwiając ich wyszukiwanie,
• indywidualna dostępność – można dotrzeć do każdego elementu z osobna, np. poprzez wyszukiwarkę, filtr, link.

Typowy serwis ogłoszeniowy, katalog produktów czy serwis z ofertami pracy bardzo często spełnia te warunki. Dane są wprowadzone do systemu, oznaczone kategoriami, parametrami, można je filtrować i sortować. To podręcznikowy przypadek bazy danych w rozumieniu dyrektywy.

Z kolei prosta strona typu „wizytówka”, z kilkoma podstronami statycznego tekstu, zwykle nie będzie kwalifikować się jako baza danych, choć mogą na niej występować indywidualnie chronione utwory (np. zdjęcia, teksty, projekty graficzne).

Ochrona twórcza vs ochrona sui generis

Dyrektywa 96/9/WE przewiduje dwa niezależne reżimy ochrony:

• ochronę twórczą – gdy baza danych jako całość spełnia przesłanki utworu (oryginalny dobór, układ, system kategoryzacji),
• ochronę sui generis – niezależną od poziomu twórczości, opartą na istotnej inwestycji w gromadzenie, weryfikację lub prezentację zawartości.

W praktyce scraping najczęściej ociera się o drugą formę ochrony. Przedmiotem sporu jest wtedy nie tyle sam układ czy „pomysł” na bazę, ile nakład pracy i środków finansowych, który właściciel bazy poniósł, aby zebrać i utrzymać dane. Prawo sui generis chroni przed pozyskiwaniem i wtórnym wykorzystywaniem całości lub istotnej części zawartości.

Jeśli baza jest zarazem twórcza, może dojść do kumulacji ochrony: naruszenie może dotyczyć zarówno praw autorskich do „architektury” bazy, jak i prawa sui generis do samej zawartości. Dla scrapera oznacza to większe ryzyko, ale też więcej punktów analizy – niekiedy udaje się wykazać, że kopiowanie dotyczy wyłącznie nietwórczych elementów.

Krok 2: ocena, czy serwis WWW ma charakter bazy danych

Praktyczna analiza serwisu, z którego planowane jest automatyczne pobieranie danych, powinna przejść przez kilka prostych pytań. Można je traktować jak szybki test „czy mam do czynienia z bazą danych w rozumieniu dyrektywy”.

1. Czy użytkownik może wyszukiwać lub filtrować dane? Jeśli w serwisie funkcjonuje wyszukiwarka ogłoszeń, filtr po kategoriach, lokalizacji, parametrach – to zwykle oznacza, że dane są przechowywane jako zorganizowana baza.
2. Czy każdy rekord ma swoje ID/URL i parametry? Dedykowane strony szczegółowe ofert, produktów, artykułów powiązane z metadanymi sugerują bazę danych po stronie serwera.
3. Czy serwis istnieje głównie „dla” tych danych? Portale ogłoszeniowe, katalogi firm, porównywarki są z natury bazami; blog ekspercki, gdzie artykuły są po prostu listą wpisów, bliższy jest kolekcji utworów niż klasycznej bazie.
4. Czy dane są aktualizowane, moderowane, archiwizowane? Rozbudowane procesy utrzymania treści to sygnał istotnej organizacji zbioru.

Jeżeli odpowiedź na większość z powyższych pytań brzmi „tak”, istnieje poważne prawdopodobieństwo, że serwis stanowi bazę danych w rozumieniu przepisów, a scraping wejdzie w obszar ochrony sui generis. Wtedy kluczowe znaczenie nabiera zagadnienie „istotnej inwestycji”.

Istotna inwestycja jako próg ochrony sui generis

Prawo sui generis nie przysługuje automatycznie każdemu zbiorowi danych. Właściciel bazy musi wykazać istotną inwestycję w zgromadzenie, weryfikację lub prezentację zawartości. TSUE w szeregu orzeczeń doprecyzował, że chodzi o realne nakłady:

• finansowe – koszty pozyskania danych, licencji, infrastruktury,
• czasowe – praca zespołów gromadzących, weryfikujących dane,
• organizacyjne – procesy utrzymania, moderacji, aktualizacji bazy.

Co istotne, zgodnie z linią orzeczniczą TSUE (m.in. sprawa British Horseracing Board) nie liczy się inwestycja w samo stworzenie danych, lecz ich zebranie ze źródeł, weryfikacja i ułożenie w strukturę bazy. To rozróżnienie ma ogromne znaczenie np. dla lig sportowych, które tworzą terminarze i tabele – nakład na wymyślenie systemu rozgrywek nie jest „istotną inwestycją” w bazę danych.

Co sprawdzić: czy serwis, z którego planowany jest scraping, wymaga stałego nakładu pracy przy gromadzeniu i utrzymaniu danych (np. ręczna weryfikacja ofert, moderacja wpisów, walidacja informacji). Im większa ta inwestycja, tym większa szansa, że właściciel będzie mógł powołać się na prawo sui generis przed sądem.

Kluczowe orzeczenia TSUE dotyczące baz danych a scraping

British Horseracing Board i Fixtures Marketing – punkt zwrotny

Orzeczenia TSUE w sprawach C‑203/02 British Horseracing Board oraz C‑444/02 Fixtures Marketing stanowią fundament wykładni prawa baz danych w Unii Europejskiej. Choć formalnie nie dotyczyły scrapingu w dzisiejszym sensie, ich wnioski są bezpośrednio stosowane w sporach o automatyczne pobieranie danych.

W sprawie British Horseracing Board Trybunał rozpatrywał, czy baza z informacjami o wyścigach konnych podlega ochronie sui generis. Podmiot zarządzający wyścigami ponosił duże nakłady na organizację samych zawodów i tworzenie danych (np. które konie biegną, o której godzinie), ale istotą sporu było to, czy te nakłady można uznać za „inwestycję w gromadzenie danych”. TSUE stwierdził, że inwestycja w stworzenie danych nie jest tym samym co inwestycja w ich zgromadzenie w bazie.

Re‑use danych a pojęcie „pozyskiwania” i „wtórnego wykorzystania”

Przy analizie scrapingu kluczowe są dwa pojęcia z dyrektywy 96/9/WE i ustawy: pozyskiwanie (ang. extraction) oraz wtórne wykorzystanie (ang. reutilisation). To na nich budowana jest większość roszczeń przeciwko operatorom narzędzi do web scrapingu.

Pozyskiwanie to trwałe lub czasowe przeniesienie całości lub istotnej części zawartości bazy na inny nośnik, dowolnymi środkami. W praktyce obejmuje m.in.:

• pobranie danych z serwisu do własnej bazy (np. zrzut ofert, archiwizacja treści),
• ciągłe „wysysanie” rekordów w tle, gdy są one zapisywane po stronie scrapera,
• tworzenie kopii bezpieczeństwa cudzej bazy na własnych serwerach.

Wtórne wykorzystanie to z kolei każdy akt publicznego udostępniania całości lub istotnej części zawartości bazy. W sporach o scraping najczęściej chodzi o takie sytuacje jak:

• udostępnienie zeskrapowanych danych w własnej wyszukiwarce lub porównywarce,
• sprzedaż dostępu do danych pozyskanych z cudzego serwisu,
• publikacja hurtowych zestawień (raportów, tabel) odtwarzających znaczną część oryginalnej bazy.

Dla scrapera oba te elementy często występują razem: najpierw dochodzi do pozyskania (pobranie danych z serwisu), następnie do wtórnego wykorzystania (udostępnienie ich klientom, użytkownikom, partnerom). Rozdzielenie tych pojęć jest jednak istotne przy budowaniu strategii obrony i projektowaniu architektury systemu.

Co sprawdzić: krok 1 – czy w projekcie dochodzi do trwałego zapisania danych pochodzących z cudzego serwisu; krok 2 – czy zapisane dane są później udostępniane dalej w sposób zbliżony do oryginalnej bazy (wyszukiwarka, listing, raporty). Im bardziej oba kroki są rozdzielone i ograniczone, tym mniejsze ryzyko sporu o „pozyskiwanie” i „wtórne wykorzystanie”.

Scraping a tymczasowe kopiowanie i cache

W praktyce technicznej część operacji na danych ma charakter czysto techniczny: buforowanie, cache, przechowywanie w pamięci RAM podczas działania procesu. Pojawia się pytanie, czy tego typu działania można kwalifikować jako „pozyskiwanie” w świetle dyrektywy o bazach danych.

TSUE przyjmuje dość szeroką wykładnię, ale jednocześnie wskazuje, że ochrona nie ma blokować normalnego funkcjonowania technologii internetowych. Drobne, ulotne kopie, które są niezbędne do wyświetlenia strony czy chwilowego przetworzenia danych, co do zasady nie będą traktowane jak pozyskanie istotnej części bazy. Problem pojawia się w momencie, gdy:

• kopie mają charakter systemowy (np. całe HTML strony są hurtowo zapisywane),
• istnieje mechanizm ich późniejszego przeszukiwania, filtrowania, eksportu,
• czas przechowywania jest długi i zbliża się bardziej do archiwizacji niż do cache.

Typowym błędem technicznym jest brak jasnego rozgraniczenia w projekcie między logami technicznymi (potrzebnymi do debugowania, bezpieczeństwa) a bazą docelową, która realnie replikuje cudzą bazę. Dla sądu ten podział jest często kluczowy.

Co sprawdzić: krok 1 – jak długo przechowywane są dane zebrane przez scrapera w pamięci operacyjnej i w logach; krok 2 – czy można na nich wykonywać zapytania podobne do tych z serwisu źródłowego; krok 3 – czy istnieją mechanizmy automatycznego czyszczenia cache i logów z treści, które nie są potrzebne biznesowo.

Orzecznictwo krajowe i europejskie dot. web scrapingu i agregatorów treści

Agregatory ogłoszeń i ofert pracy jako modelowy przypadek

Sądy europejskie wielokrotnie mierzyły się ze sporami dotyczącymi agregatorów – serwisów, które zbierają oferty pracy, ogłoszenia sprzedaży nieruchomości czy ceny produktów z różnych źródeł. To najbliższy rynkowy odpowiednik zautomatyzowanego scrapingu.

Typowy schemat sporu wygląda następująco:

1. Serwis A inwestuje w budowę bazy ogłoszeń (pozyskuje klientów, moderuje treści, utrzymuje infrastrukturę).
2. Serwis B automatycznie pobiera z niego dane – czasem na podstawie umowy, częściej jednostronnie, poprzez scrapera.
3. Serwis B udostępnia te dane użytkownikom w formie własnej wyszukiwarki, często monetyzując ruch reklamami lub abonamentami.
4. Serwis A zarzuca naruszenie prawa sui generis do bazy danych, a niekiedy także czyn nieuczciwej konkurencji.

W orzecznictwie wykształciła się ogólna linia: agregator, który w sposób systematyczny i zorganizowany odwzorowuje znaczną część cudzej bazy, wchodzi w kolizję z prawem baz danych. Nawet jeśli robi to etapami, a nie jednorazowym „zrzutem” całej bazy.

Jednocześnie sądy badają, czy agregator wnosi własną wartość dodaną: unikalne filtrowanie, wzbogacanie danych, integrację z innymi źródłami. Im większa odrębność funkcjonalna nowej usługi od serwisu źródłowego, tym łatwiej bronić się przed zarzutem prostego „klonowania” bazy.

Co sprawdzić: krok 1 – czy nowy serwis zeskrapowane dane łączy z innymi źródłami, czy raczej opiera się głównie na jednym podmiocie; krok 2 – czy użytkownik ma motyw, by odwiedzać również serwis źródłowy, czy nowy serwis całkowicie go „zastępuje”; krok 3 – jaka część ofert z oryginalnego serwisu pojawia się w agregatorze (szacunkowo, procentowo).

Skala scrapingu a „systematyczne pozyskiwanie” w praktyce

Istotny element orzecznictwa dotyczy skali i częstotliwości scrapingu. Dyrektywa i ustawy krajowe mówią nie tylko o jednorazowym pozyskaniu istotnej części bazy, ale też o powtarzającym się i systematycznym pozyskiwaniu nieistotnych części, które łącznie prowadzą do odtworzenia istotnej części.

W praktyce sądowej analizuje się m.in.:

• częstotliwość zapytań scrapera (np. co minutę, co godzinę, raz dziennie),
• czas trwania kampanii scrapingu (kilka dni vs. wiele miesięcy),
• model biznesowy scrapera (czy kluczowy zasób pochodzi z jednej bazy),
• mechanizmy omijania limitów (praca na wielu IP, rozproszenie ruchu).

Serwisy broniące się przed scrapingiem próbują wykazać, że nawet jeśli w pojedynczym cyklu pobierane są tylko fragmenty bazy, to w skali miesiąca czy kwartału dochodzi do de facto pełnej replikacji. Dla scrapera oznacza to, że nie wystarczy ograniczyć jednorazowego pobrania; trzeba też zarządzać całkowitą, długookresową objętością zebranych danych.

Co sprawdzić: krok 1 – jaką liczbę rekordów z danego serwisu realnie przechowuje system w horyzoncie 3–6 miesięcy; krok 2 – czy istnieje polityka rotacji danych (np. usuwanie starych ogłoszeń po określonym czasie); krok 3 – czy wewnętrzne logi pozwalają w razie sporu wykazać, że skala scrapingu nie prowadziła do odtworzenia zdecydowanej większości bazy.

Polskie orzeczenia a korzystanie z cudzych baz online

Polskie sądy stosunkowo rzadko używają wprost terminu „web scraping”, ale rozstrzygnięcia dotyczące nieuprawnionego korzystania z cudzych baz i serwisów WWW mają bezpośrednie przełożenie na praktykę. W licznych sprawach pojawiają się trzy filary argumentacji:

1. prawo sui generis do bazy danych – gdy administrator wykaże istotną inwestycję,
2. prawo autorskie do elementów twórczych – layout, opisy, grafiki, układ strony,
3. ustawa o zwalczaniu nieuczciwej konkurencji – jako dodatkowy „bezpiecznik”.

Szczególnie interesujące dla scrapingu są spory, w których sąd badał:

• czy kopiowanie tabel i zestawień z serwisu eksperckiego narusza prawo do bazy,
• czy hurtowe „przeklejanie” ofert z portalu ogłoszeniowego przez konkurencyjny serwis jest czynem nieuczciwej konkurencji,
• czy korzystanie z oficjalnego API w sposób niezgodny z regulaminem można traktować jak nadużycie prawa do bazy.

Sądy często akcentują, że brak technicznych zabezpieczeń przed scrapowaniem nie oznacza zgody na dowolne korzystanie z bazy. To ważny sygnał dla zespołów technicznych: sam fakt, że serwis jest publicznie dostępny i nie wymaga logowania, nie wyłącza ochrony prawnej jego bazy.

Co sprawdzić: krok 1 – jakie regulaminy i zastrzeżenia prawne obowiązują w serwisie, z którego dane są pobierane; krok 2 – czy projekt scrapingu może zostać zakwalifikowany jako czyn nieuczciwej konkurencji (np. żerowanie na cudzych nakładach, przejmowanie klientów); krok 3 – czy administrator serwisu wdrożył choć minimalne środki ochrony (CAPTCHA, limity zapytań), które są później omijane.

Rola regulaminów serwisów i zgód kontraktowych

Obok przepisów o bazach danych coraz większe znaczenie mają postanowienia regulaminów serwisów. Administratorzy próbują nimi ograniczyć albo warunkować scraping – np. zakazując użycia robotów bez uprzedniej zgody lub wprowadzając wymóg korzystania wyłącznie z oficjalnego API.

Relacja między regulaminem a prawem baz danych wygląda najczęściej tak:

• prawo baz danych określa ramy ustawowe (czego nie wolno robić niezależnie od umowy),
• regulamin może te ramy uszczegóławiać i np. dopuścić określony zakres re‑use,
• naruszenie regulaminu bywa kwalifikowane jako naruszenie umowy lub czyn nieuczciwej konkurencji.

Dla scrapera oznacza to dwa poziomy analizy: nawet jeśli projekt mieści się poniżej progu „istotnej części” w rozumieniu prawa sui generis, nadal może naruszać regulamin serwisu. W skrajnym wariancie administrator może powoływać się jednocześnie na przepisy o bazach danych, prawie autorskim i naruszeniu zobowiązania kontraktowego.

Co sprawdzić: krok 1 – czy w regulaminie serwisu znajdują się wprost postanowienia dotyczące robotów i scrapingu; krok 2 – czy przewidziano w nim sankcje (blokada konta, odszkodowanie, kary umowne); krok 3 – czy można uzyskać pisemne zezwolenie lub zawrzeć umowę licencyjną, która wprost reguluje zakres dozwolonego pobierania danych.

„Istotna część” bazy i „nieistotne części” – gdzie przebiega granica ryzyka

Kryteria ilościowe: liczba rekordów i objętość danych

Najbardziej intuicyjne jest kryterium ilościowe: jaki procent rekordów bazy został pobrany. Ani dyrektywa, ani ustawa nie podają sztywnego progu (np. 10% czy 50%). TSUE przyjmuje podejście elastyczne, analizując każdorazowo znaczenie pobranej części dla całości bazy.

W praktyce sądowej jako „istotną część ilościową” traktowano m.in. sytuacje, gdy:

• pobrano większość rekordów z bazy (np. katalogu produktów lub ogłoszeń),
• pobrano kluczowy segment bazy (np. wszystkie oferty z dużego miasta lub z najbardziej popularnej kategorii),
• w sposób ciągły pobierano nowe rekordy, tak że w każdym momencie własna baza scrapera zawierała zdecydowaną większość aktualnych danych.

Nie oznacza to, że pobranie kilkuset rekordów z milionowej bazy zawsze będzie bezpieczne. Jeżeli zebrane dane obejmują np. „Top 100” produktów stanowiących trzon biznesu serwisu źródłowego, sąd może uznać, że naruszony został segment o jakościowo dużym znaczeniu, mimo niewielkiego udziału procentowego.

Co sprawdzić: krok 1 – oszacować wielkość całej bazy serwisu źródłowego (choćby orientacyjnie: rząd wielkości); krok 2 – porównać ją z liczbą rekordów przechowywanych w systemie scrapera; krok 3 – zidentyfikować, czy pobrane dane dotyczą obszarów kluczowych biznesowo dla serwisu źródłowego (najpopularniejsze kategorie, lokalizacje, usługodawcy).

Kryteria jakościowe: znaczenie biznesowe i informacyjne

„Istotna część” ma nie tylko wymiar ilościowy, ale także jakościowy. TSUE wielokrotnie podkreślał, że część bazy może być istotna, jeśli ma szczególne znaczenie dla funkcjonowania całości – nawet jeśli liczbowo jest niewielka.

Przykładowo:

• pobranie pełnej historii wyników danego zawodnika z bazy sportowej, jeśli ta historia jest kluczowa dla działalności bazy,
• pobranie aktualnych stawek z niewielkiej grupy indeksów finansowych, gdy to one stanowią główny produkt serwisu,
• pobranie listy „top ofert dnia”, która w praktyce skupia najcenniejsze ogłoszenia z całej bazy.

Najważniejsze punkty

• Krok 1: rozróżnij crawling od scrapingu – crawling tylko szuka i mapuje adresy, natomiast scraping faktycznie wyciąga dane i tworzy z nich własny zbiór; to ten drugi etap jest kluczowy z punktu widzenia ochrony baz danych.
• Odpowiedzialność prawna zależy głównie od efektu, a nie techniki – sądy patrzą na to, czy powstaje kopia istotnej części cudzej bazy (albo systematycznie pobierane są jej fragmenty), niezależnie od tego, czy użyto prostego parsowania HTML, headless przeglądarki czy oficjalnego API.
• Największe ryzyko generują projekty „naśladujące” cudzą bazę – agregatory ogłoszeń, porównywarki cen czy narzędzia do monitoringu rynku, które budują własne przeszukiwalne zbiory na podstawie cudzego serwisu, łatwo wchodzą w zakres ochrony sui generis baz danych.
• Krok 2: zidentyfikuj typ danych przed startem – trzeba jasno ustalić, czy pobierane są chronione utwory (teksty, zdjęcia), proste fakty (ceny, daty), struktury i relacje, czy dane osobowe; każda z tych kategorii uruchamia inny zestaw przepisów i ryzyk.
• Scraping dotyka kilku reżimów prawnych naraz – oprócz prawa do baz danych mogą wchodzić w grę prawo autorskie, regulaminy i umowy (NDA, warunki API), RODO oraz dobra osobiste, więc skupienie się tylko na jednym aspekcie (np. „to są przecież tylko ceny”) jest typowym i kosztownym błędem.