Prawa autorskie i otwarta sztuczna inteligencja: asymetria prawna blokująca transparentność

Reprodukcja danych chronionych prawem autorskim do uczenia sztucznej inteligencji jest legalna, ale ich dystrybucja nie – ta asymetria blokuje rozwój prawdziwie otwartej sztucznej inteligencji.

Krytyczna asymetria prawna: dlaczego prawdziwie otwarta sztuczna inteligencja jest niemożliwa

Mamy problem fundamentalny: prawo autorskie pozwala mi trenować model na chronionych danych w ramach dozwolonego użytku (fair use), ale nie mogę opublikować tych samych danych jako otwartego zbioru danych. To różnica między reprodukcją a dystrybucją – i właśnie ta asymetria uniemożliwia rozwój prawdziwie otwartego oprogramowania w dziedzinie sztucznej inteligencji.

Kiedy trenujesz model w swoim centrum danych, reprodukujesz dane lokalnie na potrzeby obliczeniowe. W wielu krajach jest to uznawane za w pełni legalne. Ale gdy chcesz udostępnić cały zbiór danych publicznie? Musisz spełnić wymogi prawne wszystkich jurysdykcji, z których ten zbiór może zostać pobrany [1]. W praktyce jest to niemal niewykonalne. Programiści często zakładają, że dane dostępne w sieci należą do domeny publicznej i publikują je jako otwarte zasoby, podczas gdy w wielu innych krajach te same materiały pozostają pod ścisłą ochroną prawnoautorską [1].

Inicjatywa na rzecz Otwartego Oprogramowania (Open Source Initiative – OSI) definiuje prawdziwie otwartą sztuczną inteligencję jako strukturę składającą się z trzech kluczowych komponentów: danych treningowych, kodu architektury oraz parametrów (wag) modelu – przy czym wszystkie te elementy muszą być udostępnione na licencji gwarantującej cztery podstawowe wolności (używania, studiowania, modyfikowania i udostępniania) [2]. Bez pełnego zbioru danych wejściowych mamy do czynienia jedynie z rozwiązaniem o otwartym dostępie, a nie z prawdziwie otwartym oprogramowaniem. To nie są tylko spory o nazewnictwo – ta różnica w kontekście unijnego Aktu o sztucznej inteligencji (Aktu o AI) może decydować o konieczności poniesienia milionowych nakładów na zapewnienie zgodności z przepisami.

Urząd ds. Praw Autorskich USA (U.S. Copyright Office) potwierdził w swoim oficjalnym raporcie, że rezultaty generowane wyłącznie przez sztuczną inteligencję nie podlegają ochronie prawnej, ponieważ brakuje im elementu ludzkiego autorstwa [2]. Choć na pierwszy rzut oka brzmi to korzystnie, niesie za sobą poważną pułapkę. Oznacza to, że kod źródłowy napisany w całości przez model językowy nie może być licencjonowany na zasadach otwartego oprogramowania (ponieważ licencje te opierają się na prawie autorskim), chyba że człowiek dokona w nim istotnych i twórczych modyfikacji [2].

Dobrym przykładem jest sprawa MongoDB, w której deweloperzy użyli sztucznej inteligencji do przepisania tysięcy linii kodu z projektu opartego na licencji LGPL i opublikowali go ponownie na liberalnej licencji MIT [2]. Oryginalny autor żądał przywrócenia pierwotnej licencji, wskazując, że zasada dziedziczenia licencji (copyleft) wymaga zachowania tych samych warunków w dziełach pochodnych. Pojawia się pytanie: czy sztuczna inteligencja może być legalnie wykorzystywana do usuwania restrykcyjnych licencji z cudzego kodu? Debata wciąż trwa, ale sam precedens budzi niepokój w społeczności programistów.

Konsekwencje tego stanu prawnego są poważne. Bez dostępu do oryginalnego zbioru danych treningowych nie da się w pełni zreplikować modelu, zweryfikować jego błędów i uprzedzeń ani zbadać, czym model był zasilany podczas nauki. Nazywanie takich rozwiązań „otwartymi” to jedynie fasada – otrzymujemy wagi i kod, ale brakuje nam kluczowego ogniwa w postaci danych. To jak otrzymać gotowy lek bez znajomości jego dokładnego składu chemicznego.

Obecny stan prawny strukturalnie uniemożliwia spełnienie standardów otwartości dla sztucznej inteligencji. Możemy udawać transparentność, publikując modele z otwartymi wagami. Jednak dopóki reprodukcja danych na potrzeby treningowe jest dozwolona, a ich publiczne udostępnianie zabronione – prawdziwie otwarta sztuczna inteligencja pozostaje jedynie prawną fikcją.

Definicja otwartej sztucznej inteligencji: trzy komponenty i cztery wolności

Branża sztucznej inteligencji ma ogromny problem z nazewnictwem. To, co większość firm określa mianem „otwartej AI”, w rzeczywistości jest jedynie otwartym dostępem. Otrzymujemy wgląd w wagi modelu, ale bez praw i wolności, które stanowią fundament klasycznego otwartego oprogramowania.

Inicjatywa na rzecz Otwartego Oprogramowania (OSI) pracuje nad standardem określającym, że prawdziwie otwarte rozwiązanie AI wymaga publicznego udostępnienia trzech elementów [6]:

1. Dane treningowe – kompletne zbiory danych, opis metodologii ich przygotowania oraz techniki wstępnego przetwarzania. 2. Kod źródłowy – pełna architektura modelu, implementacja w środowiskach takich jak PyTorch czy TensorFlow oraz skrypty treningowe. 3. Parametry modelu – wagi sieci neuronowej, współczynniki oraz punkty kontrolne (zapisy stanu modelu).

Brak jakiegokolwiek z tych elementów degraduje projekt do poziomu oprogramowania o otwartym dostępie – możemy pobrać model i go uruchomić, ale nie mamy możliwości jego pełnego zrozumienia, modyfikacji czy powtórzenia procesu szkolenia.

Cztery fundamentalne wolności

OSI adaptuje klasyczne zasady wolnego oprogramowania do specyfiki sztucznej inteligencji [6]:

Użytkowanie – możliwość uruchamiania systemu w dowolnym celu, bez ograniczeń umownych.
Studiowanie – pełny dostęp do analizy architektury, danych treningowych i procesów uczenia.
Modyfikacja – możliwość dostrajania modelu, wprowadzania zmian w architekturze i ponownego szkolenia.
Udostępnianie – dystrybucja zarówno wersji oryginalnej, jak i zmodyfikowanej.

Te definicje mają wymiar czysto praktyczny. Unijny Akt o sztucznej inteligencji przewiduje wyraźne zwolnienia z obowiązków regulacyjnych dla systemów wydanych na licencjach wolnego i otwartego oprogramowania [6]. Jeśli model spełnia te kryteria, firma unika kosztownych procesów badania zgodności z przepisami, co przekłada się na ogromne oszczędności finansowe i czasowe.

Problem z danymi: asymetria prawna

Największą przeszkodą jest to, że prawo pozwala na trenowanie modeli na danych chronionych prawem autorskim (w ramach dozwolonego użytku), lecz zabrania ich późniejszego rozpowszechniania w otwartych zbiorach danych. Urząd ds. Praw Autorskich USA potwierdził tę asymetrię: powielanie danych na etapie nauki maszyny to zupełnie inny proces prawny niż ich późniejsza dystrybucja [4].

W efekcie deweloperzy chcący stworzyć w pełni otwarte oprogramowanie nie mogą legalnie udostępnić zbioru danych treningowych. To z kolei łamie zasadę wolności studiowania kodu – bez oryginalnych danych nikt nie jest w stanie w pełni zweryfikować ani odtworzyć zachowania modelu.

Klasyfikacja ma znaczenie prawne

Wiele zespołów inżynieryjnych traci czas na analizę zgodności z wymogami prawnymi tylko dlatego, że błędnie oznaczono dany model jako otwarte oprogramowanie, podczas gdy udostępniono jedynie jego wagi. Prawidłowa klasyfikacja projektu to nie kwestia marketingu, lecz ważna decyzja prawna wpływająca na harmonogram wdrożenia i budżet.

Jeśli planujesz publikację swojego modelu, najpierw zweryfikuj: czy możesz w pełni udostępnić wszystkie trzy wymagane komponenty? Jeśli nie, właściwym określeniem dla Twojego projektu są „otwarte wagi” lub „otwarty dostęp”, a nie „otwarte oprogramowanie”. Unikniesz w ten sposób problemów z audytami i instytucjami nadzorczymi.

Zdolność do ochrony prawnoautorskiej kodu generowanego przez AI

Prawo autorskie w USA opiera się na zasadzie, że każde dzieło musi posiadać ludzkiego autora [2]. Ta reguła wprost uderza w kod generowany przez sztuczną inteligencję. Kod napisany samodzielnie przez model językowy nie spełnia tego kryterium i nie podlega ochronie prawnej [2]. Ma to fundamentalne znaczenie dla licencji otwartego oprogramowania.

Licencje takie jak MIT, Apache czy GPL wymagają istnienia praw autorskich, aby mogły wywołać skutki prawne. Udzielasz licencji na kod, ponieważ jesteś jego właścicielem. Jeśli kod został stworzony przez sztuczną inteligencję i nie posiada właściciela w świetle prawa, nie można go skutecznie licencjonować [5]. Powstaje luka prawna: oprogramowanie istnieje i działa, ale jego status licencyjny jest niemożliwy do zdefiniowania.

Urząd ds. Praw Autorskich USA jednoznacznie wskazał, że projektowanie zapytań (inżynieria promptów) nie tworzy autorstwa [2]. Nawet najbardziej zaawansowane instrukcje wpisywane przez użytkownika nie czynią go twórcą kodu, ponieważ to model decyduje o ostatecznej strukturze generowanego tekstu. Stanowi to wyzwanie dla nowoczesnego programowania opartego na sztucznej inteligencji, gdzie deweloperzy masowo korzystają z asystentów programowania.

Kolejną barierą są krótkie fragmenty kodu. Wiele instrukcji generowanych przez sztuczną inteligencję to proste funkcje pomocnicze lub standardowe algorytmy. Zgodnie z prawem USA bardzo krótkie frazy i powtarzalne struktury kodu nie podlegają ochronie autorskiej [3]. Nawet jeśli programista dokona w nich drobnych poprawek, mogą one być zbyt mało twórcze, by zyskać ochronę. W efekcie duża część kodu współtworzonego przez sztuczną inteligencję znajduje się w prawnej szarej strefie.

Praktycznym przykładem tych napięć jest przypadek MongoDB. Firma wykorzystała narzędzie sztucznej inteligencji do przepisania kodu z projektu opartego na licencji LGPL i opublikowała go pod licencją MIT [8]. Zasada dziedziczenia licencji (copyleft) nakazuje, aby dzieła pochodne dziedziczyły licencję pierwotną. Jednak MongoDB uznało, że kod wygenerowany i przepisany przez sztuczną inteligencję nie jest dziełem pochodnym w rozumieniu prawa. Autor oryginału zażądał wycofania zmian [8]. Sprawa ta dowodzi, że sztuczna inteligencja może służyć do usuwania restrykcyjnych licencji – wystarczy przepisać kod za pomocą modelu i ogłosić go jako zupełnie nowe, niepowiązane dzieło.

Jak w tym kontekście zdefiniować rolę programisty? Jedynym bezpiecznym punktem oparcia dla praw autorskich pozostaje twórcza modyfikacja i integracja wygenerowanego kodu [2]. Jeśli traktujesz kod stworzony przez sztuczną inteligencję jako bazę, którą następnie samodzielnie edytujesz, reorganizujesz i łączysz w większą całość, tworzysz dzieło złożone, w którym Twój wkład podlega ochronie. Granica ta jest jednak płynna – prosta zmiana nazw zmiennych to za mało, ale całkowite przeprogramowanie logiki biznesowej oznacza, że to Ty jesteś autorem.

Deweloperzy powinni traktować kod z narzędzi AI wyłącznie jako surowiec, który zawsze wymaga weryfikacji i autorskiego dopracowania. To nie tylko dbałość o jakość oprogramowania, ale przede wszystkim strategia zabezpieczenia prawnego przed zarzutami o naruszenie licencji.

Analiza przypadku: MongoDB kontra copyleft – czy sztuczna inteligencja może zmienić licencję?

Firma MongoDB wywołała duże poruszenie w środowisku programistycznym, korzystając z asystenta sztucznej inteligencji do przepisania kodu z projektu objętego licencją typu copyleft (LGPL) i wydając go pod licencją permisywną (MIT) [8]. Twórca oryginalnego rozwiązania oskarżył firmę o próbę obejścia prawa, argumentując, że licencje chroniące wolność oprogramowania nie mogą być zmieniane bez zgody wszystkich autorów projektu [8].

Sprawa ta ujawniła systemowy problem: czy sztuczna inteligencja może służyć do oczyszczania kodu z zobowiązań licencyjnych? Ponieważ kod stworzony wyłącznie przez sztuczną inteligencję nie podlega prawu autorskiemu, teoretycznie nie można go objąć licencjami opierającymi się na tym prawie [2]. W praktyce jednak MongoDB użyło sztucznej inteligencji do odtworzenia identycznej funkcjonalności w nowej formie tekstowej.

Zasada dziedziczenia licencji (copyleft) ma charakter ciągły – każdy projekt bazujący na takim kodzie musi pozostać wolny. Jeśli przepisywanie kodu przez sztuczną inteligencję pozwala na zignorowanie tej zasady, cała idea ochrony wolnego oprogramowania traci rację bytu. Dodatkowo w projektach tworzonych przez społeczność zmiana licencji wymaga jednomyślnej zgody wszystkich współtwórców, co przy setkach autorów jest technicznie niewykonalne [8].

Większość deweloperów ostrzega, że akceptacja takich praktyk zniszczy kulturę dzielenia się kodem. Z drugiej strony, część biznesu postrzega to jako szansę na uwolnienie się od restrykcyjnych licencji blokujących komercjalizację. Sprawa ta jasno pokazuje, że obecne ramy prawne nie są dostosowane do realiów, w których modele AI potrafią w kilka sekund zmienić formę zapisu kodu przy zachowaniu jego logiki działania.

Wyzwania jurysdykcyjne: publikacja zbiorów danych w globalnej sieci

Publikując zbiory danych w internecie, wkracza się w prawną pułapkę jurysdykcyjną. Różnica między lokalnym prawem do reprodukcji danych a globalnym prawem do ich rozpowszechniania to kluczowy problem uniemożliwiający zachowanie pełnej transparentności w projektach AI.

Reprodukcja a dystrybucja: asymetria prawna

Pobieranie i przetwarzanie chronionych danych na potrzeby uczenia maszynowego w obrębie własnej infrastruktury jest zazwyczaj legalne w danej jurysdykcji (dzięki wyjątkom dla eksploracji tekstów i danych – TDM). Sytuacja zmienia się diametralnie, gdy ten sam zbiór danych publikuje się w sieci. Taki krok wymaga zgodności z prawem wszystkich krajów, z których dane mogą być pobrane [1].

Przykładowo: trenujesz model na bazie artykułów prasowych w Unii Europejskiej, gdzie prawo zezwala na eksplorację danych. Następnie udostępniasz ten zbiór na platformie GitHub jako otwarty zbiór treningowy. Jeśli użytkownik z USA lub Japonii pobierze te dane, podlegasz pod tamtejsze systemy prawne, które mogą interpretować to jako naruszenie praw autorskich. Ryzykujesz odpowiedzialność prawną w wielu jurysdykcjach jednocześnie.

Brak globalnej domeny publicznej

Programiści często zakładają, że jeśli dane są dostępne publicznie, można je bez przeszkód włączyć do otwartych zbiorów treningowych. To błąd. Nie istnieje coś takiego jak globalna domena publiczna – to kategoria regulowana lokalnie [1]. Materiały wolne od praw autorskich w jednym kraju mogą być nadal chronione w innym, co naraża wydawcę zbioru na spory sądowe.

Tworzy to paradoks: chociaż kod i wagi modelu są udostępniane otwarcie, twórca nie może legalnie opublikować zbioru danych, na którym model się uczył. Mimo że standardy wymagają pełnej transparentności danych do uznania projektu za otwarty, prawo autorskie skutecznie to blokuje.

Akt o sztucznej inteligencji (Akt o AI): metoda prób i błędów

Unijne regulacje przewidują wyłączenia dla systemów wydawanych na otwartych licencjach [4]. Jednak interpretacja tych przepisów wciąż opiera się na metodzie prób i błędów [1]. Nikt nie jest w stanie precyzyjnie przewidzieć, jak sądy będą interpretować pojęcie otwartości w odniesieniu do zbiorów danych treningowych. Dla mniejszych firm i startupów publikowanie takich danych wiąże się z dużym ryzykiem prawnym.

Rozwiązanie: podejście oparte na metadanych

Praktyczną alternatywą jest publikowanie szczegółowych metadanych zamiast surowych, chronionych materiałów [1]. Udostępnia się statystyki, strukturę danych, informacje o ich pochodzeniu oraz skrypty przygotowujące, ale bez dystrybuowania samych plików źródłowych.

Przykładowo, zamiast udostępniać miliony pobranych z sieci obrazów, publikuje się:

Listę adresów URL prowadzących do oryginalnych grafik.
Skrypty automatyzujące pobieranie i obróbkę plików.
Sumy kontrolne do weryfikacji spójności.
Statystyki rozkładu klas i cech.

Dzięki temu końcowy użytkownik może samodzielnie odtworzyć zbiór treningowy w swojej jurysdykcji, przejmując na siebie odpowiedzialność prawną za pobieranie tych treści. Pozwala to na zachowanie wysokiego poziomu transparentności bez łamania prawa autorskiego.

Stanowisko US Copyright Office i doktryna dozwolonego użytku

Urząd ds. Praw Autorskich USA przeprowadził szerokie konsultacje społeczne dotyczące wpływu sztucznej inteligencji na prawo autorskie, otrzymując ponad 10 000 stanowisk od przedstawicieli branży technologicznej i prawniczej [2]. Dowodzi to skali problemów, z jakimi mierzą się twórcy systemów AI.

Wydane raporty przyniosły kluczowe rozstrzygnięcia. Pierwsza część (lipiec 2024) dotyczyła cyfrowych replik i ochrony wizerunku oraz głosu przed manipulacjami (deepfake'ami) [7]. Druga część (styczeń 2025) dotyczyła praw autorskich do treści generowanych przez sztuczną inteligencję i jednoznacznie wskazała, że dzieła stworzone w całości przez AI nie podlegają ochronie [2][7].

Zasada ta ma ogromny wpływ na projekty otwartego oprogramowania. Kodu wygenerowanego wyłącznie przez maszynę nie można objąć tradycyjnymi licencjami (MIT, GPL), ponieważ licencje te wymagają istnienia praw autorskich, które w tym przypadku nie powstają [2]. Projektowanie zapytań (inżynieria promptów) nie daje praw autorskich do rezultatu, ponieważ to system AI, a nie człowiek, decyduje o ostatecznym kształcie kodu [2].

Największym wyzwaniem pozostaje brak rozstrzygnięcia, czy wykorzystywanie chronionych utworów do trenowania modeli mieści się w doktrynie dozwolonego użytku (fair use) [2]. Prowadzi to do licznych procesów sądowych przeciwko twórcom modeli i asystentów programistycznych. Rozstrzygnięcia tych spraw będą kształtować rynek AI przez najbliższe lata.

Eksperci proponują utworzenie nowej kategorii praw dla projektów tworzonych we współpracy człowieka ze sztuczną inteligencją [2]. Jeśli programista aktywnie nadzoruje, edytuje i łączy fragmenty wygenerowane przez asystenta, całość mogłaby podlegać ochronie. Obecnie jednak brakuje precyzyjnych wytycznych, jak duży musi być wkład ludzki, by dzieło zyskało ochronę prawną.

Brak jasnych reguł to bezpośredni koszt dla dyrektorów technicznych (CTO) i liderów zespołów deweloperskich. Muszą oni balansować między ryzykiem pozwów za ujawnienie danych treningowych a utratą korzyści płynących ze zwolnień regulacyjnych za brak pełnej otwartości systemu [2].

Praktyczne wnioski i lista kontrolna dla projektów otwartej sztucznej inteligencji

Twórcy i opiekunowie projektów otwartej sztucznej inteligencji muszą pamiętać, że pełna otwartość wymaga udostępnienia kompletnego trójpodziału: danych, kodu oraz parametrów modelu [6]. W przeciwnym razie projekt zostanie zakwalifikowany jedynie jako model o otwartym dostępie, co pozbawia go korzyści regulacyjnych.

Lista kontrolna weryfikacji statusu prawnego:

Przeanalizuj status prawny danych treningowych. Pamiętaj, że reprodukcja danych na potrzeby uczenia maszynowego może być legalna lokalnie, ale udostępnianie tych samych danych w globalnej sieci jako otwartego zbioru wymaga zgodności z prawem we wszystkich krajach, z których dane te mogą być pobrane [1][2]. Bezpieczną alternatywą jest publikowanie samych metadanych i skryptów pobierających, zamiast chronionych plików źródłowych [1].

Zweryfikuj pochodzenie kodu źródłowego. Kod wygenerowany w całości przez sztuczną inteligencję bez udziału człowieka nie podlega ochronie autorskiej, więc nie można go skutecznie objąć licencjami otwartego oprogramowania [2]. Konieczne jest wykazanie ludzkiego wkładu w postaci modyfikacji, selekcji lub aranżacji wygenerowanych fragmentów [2].

Procedura zapewnienia ludzkiego autorstwa:

Dokumentuj proces korzystania z asystentów sztucznej inteligencji w opisach zatwierdzeń zmian (zatwierdzeniach).
Przeprowadzaj przegląd kodu przez doświadczonych programistów dla wszystkich fragmentów wygenerowanych przez modele, dokumentując wprowadzane poprawki.
Traktuj krótkie, powtarzalne fragmenty kodu wygenerowane przez sztuczną inteligencję jako elementy niemające charakteru twórczego, niewymagające szczególnej ochrony prawnej [3].

Strategia dobrowolnego ujawniania informacji:

Wprowadź zasadę transparentności i informuj w dokumentacji (pliku README) o zakresie wykorzystania sztucznej inteligencji przy tworzeniu oprogramowania. Określ, które moduły były wspierane przez modele AI, jaki był stopień ludzkiej modyfikacji oraz jakie źródła danych wykorzystano do szkolenia modeli.

Zarządzanie ryzykiem regulacyjnym:

Unikaj publikowania pełnych zbiorów danych bez uprzedniej analizy prawnej w kluczowych jurysdykcjach (UE, USA, Wielka Brytania).
Rozważ wdrożenie blokowania geograficznego w odniesieniu do zbiorów danych, których status prawny w niektórych krajach budzi wątpliwości [4].
Przygotuj dokumentację techniczną wymaganą przez Akt o sztucznej inteligencji (w tym historię pochodzenia danych oraz metodologię szkolenia) jeszcze przed oficjalną publikacją systemu [4].

Trzy złote zasady dla opiekunów projektów:

Po pierwsze: stawiaj transparentność ponad wygodę – nie ukrywaj faktu korzystania z modeli generatywnych w procesie produkcji oprogramowania. Po drugie: udział człowieka w pętli decyzyjnej jako standard – każdy element generowany automatycznie musi zostać zweryfikowany przez programistę. Po trzecie: ostrożne licencjonowanie – w przypadku jakichkolwiek wątpliwości co do statusu prawnego kodu, bezpieczniej jest opublikować go na zasadach otwartego dostępu z wyraźnym zastrzeżeniem prawnym, zamiast deklarować pełną zgodność z licencją otwartego oprogramowania.

Branża czeka na kolejne części raportu U.S. Copyright Office (część 1 w lipcu 2024 dotyczyła replik cyfrowych, część 2 w styczniu 2025 – zdolności do ochrony prawnoautorskiej [2][7]). Ponad 10 000 komentarzy w zapytaniu o opinię z 2023 roku pokazuje skalę niepewności. Opiekunowie projektów muszą działać w tej próżni prawnej, balansując między transparentnością a ryzykiem.

Prawa autorskie i otwarta sztuczna inteligencja: asymetria prawna blokująca transparentność

Prawa autorskie i otwarta sztuczna inteligencja: asymetria prawna blokująca transparentność

Krytyczna asymetria prawna: dlaczego prawdziwie otwarta sztuczna inteligencja jest niemożliwa

Definicja otwartej sztucznej inteligencji: trzy komponenty i cztery wolności

Zdolność do ochrony prawnoautorskiej kodu generowanego przez AI

Analiza przypadku: MongoDB kontra copyleft – czy sztuczna inteligencja może zmienić licencję?

Wyzwania jurysdykcyjne: publikacja zbiorów danych w globalnej sieci

Stanowisko US Copyright Office i doktryna dozwolonego użytku

Praktyczne wnioski i lista kontrolna dla projektów otwartej sztucznej inteligencji

Bibliografia

Komentarze