Update: Krzysztof Siewicz, Scope of copyleft clause under Polish law (PDF, English version)

Aktualizacja: poprawiona i uzupełniona wersja artykułu ukazała się w: J. Barta (red.), Zagadnienia Prawa Autorskiego, ZNUJ PWiOWI Zeszyt 93 s. 235, Zakamycze 2006

Wprowadzenie

W roku 1984, informatyk, ideolog i wizjoner Richard M. Stallman rozpoczął swoją moralną krucjatę o prawa użytkowników komputerów. Te prawa to cztery wolności, które składają się na zaproponowaną przez niego definicję „wolnego oprogramowania” i brzmią następująco:

Wolność nr 0: Prawo do korzystania z programu w jakimkolwiek celu.
Wolność nr 1: Prawo do badania sposobu działania programu i adaptowania go do własnych potrzeb. …
Wolność nr 2: Prawo do rozpowszechniania kopii, aby pomóc bliźnim
Wolność nr 3: Prawo do ulepszania programu i do publicznego rozpowszechniania własnych ulepszeń tak, aby skorzystało całe społeczeństwo … .Richard M. Stallman, Free Software Definition, 41 w: Richard M. Stallman, Free Software, Free Society: Selected Essays of Richard M. Stallman 41 (GNU Press, Boston, 2002). (tłumaczenie własne) (Wszystkie publikacje Stallmana dostępne są również pod http://www.fsf.org.

Z powyższej definicji wynika, że „wolność” w odniesieniu do oprogramowania oznacza przede wszystkim jego publiczną dostępność i zakaz pozostawiania kontroli nad nim w rękach jednostek. Celem Stallmana jest stworzenie kompletnego systemu składającego się z wolnych programów, który nazwał „Systemem GNU”. Początkowo Stallman pracował nad tworzeniem tego systemu samodzielnie lecz z biegiem czasu coraz więcej informatyków zaczęło rozpowszechniać swoje programy na zasadach zgodnych z definicją „wolnego oprogramowania”. Obecnie, zwłaszcza po stworzeniu w 1991 jądra Linux przez Linusa Torvaldsa, nad rozwojem systemu GNU pracują tysiące informatyków z całego świata.

Stallman zdaje sobie sprawę z faktu, że znaczna część praktyki systemu prawnej ochrony własności intelektualnej idzie w kierunku odwrotnym od wyznaczanego przez promowane przez niego wolności. Wielcy komercyjni gracze rynku informatycznego zaciekle bronią „swoich” praw autorskich, a ostatnio coraz odważniej sięgają po jeszcze bardziej silną ochronę patentową. Tam, gdzie Stallman chciałby widzieć coś na kształt łąki, z której swobodnie mogą korzystać wszyscy członkowie społeczności, dochodzi do coraz wyraźniejszego określania stref wpływów, porównywanego przez komentatorów do ruchu grodzeń znanego z historii Anglii. W związku z tym, Stallman zaprojektował model prawnej ochrony wolnego oprogramowania zwany „copyleft”, którego podstawowym celem jest zapewnienie, że oprogramowanie to pozostanie wolnym.

„Copyleft” – wszelkie prawa odwrócone

Konieczność tworzenia specjalnych konstrukcji prawnych dla ochrony wolnego oprogramowania można uzasadnić na podstawie następujących przesłanek. Przede wszystkim, cztery wolności Stallmana są jedynie postulatami, a obecny system prawny przyznaje monopol na wszelkie działania nimi objęte uprawnionym z praw autorskich do programów. Bez zgody uprawnionego, nie jest możliwe kopiowanie, modyfikowanie, ani rozpowszechnianie programu komputerowego.

Poza tym, proste zrzeczenie się roszczeń do programu przez uprawnionego, czyli umieszczenie go w tak zwanej „domenie publicznej” nie jest w stanie zapewnić takiemu programowi „wolności” na dłuższą metę. Każdy, po dokonaniu nawet niewielkiej modyfikacji programu public domain stałby się uprawnionym do tak powstałego nowego utworu i doszłoby do ponownego zawłaszczenia programu. Jest to pewien skrót myślowy, który wymaga wyjaśnienia. Oczywiście nie jest możliwe zawłaszczenie utworu, który w ten czy w inny sposób trafił do domeny publicznej. Mowa tu o kolejnej wersji takiego programu, stworzonej poprzez jego modyfikację lub wykorzystanie w nowym programie, wobec której prawa autorskie przysługiwałyby twórcy. Ponieważ na rynku oprogramowania istotny popyt występuje jedynie na najnowsze, ulepszone wersje oprogramowania, to pozostawanie wersji pierwotnej w public domain nie miałoby wielkiego znaczenia.Potwierdzeniem tej tezy jest ogromna popularność serwera Apache, opartego na uwolnionym do public domain programie httpd (http://www.apache.org). Pozycję rynkową zdobyłby nowy program i to jego twórcy przynosiłby korzyści wysiłek poświęcony na stworzenie programu uwolnionego do domeny publicznej.

W celu przezwyciężenia powyższych przeszkód w rozwoju wolnego oprogramowania Stallman zaproponował „copyleft”, które jest „prawem autorskim odwróconym na lewą stronę”, gdyż zamiast dostarczać sposobu na prywatyzację i zawłaszczenie utworu, zmusza do respektowania jego „wolności”.Richard M. Stallman, The GNU Project, 20 w: Richard M. Stallman, Free Software, Free Society: Selected Essays of Richard M. Stallman, 15 (GNU Press, Boston, 2002). Copyleft jest grą słów w języku angielskim – copyleft-copyright. Potocznie rzecz ujmując, „copyleft” polega na udzieleniu wszystkim praw wynikających z czterech wolności „wolnego oprogramowania” z jednoczesnym zakazem wprowadzania przez kogokolwiek ograniczeń tych wolności. Według Stallmana, „copyleft” sprawia, że wolności te stają się prawami niezbywalnymi.Id.

Z techniczno-prawnego punktu widzenia, „copyleft” jest postanowieniem umownym zawieranym w umowach licencyjnych na programy komputerowe. Najbardziej znaną i najpopularniejszą modelową umową licencyjną stosowaną w obrocie wolnym oprogramowaniem jest GNU General Public License, version 2.0 (dalej „GPL”), która przyznaje użytkownikom wszystkie cztery wolności wolnego oprogramowania. Klauzula „copyleft” zawarta w GPL wygląda następująco:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.GPL Sec. 2 b), http://www.fsf.org/licenses/gpl.html.

Zezwolenie na kopiowanie, modyfikację, tworzenie opracowań oraz rozpowszechnianie programu zawarte w GPL jest udzielone pod warunkiem przestrzegania powyższej klauzuli „copyleft”. Licencjobiorca nie może rozpowszechniać programów objętych zakresem tej klauzuli na zasadach innych niż GPL. Efekt ten jest potocznie określany jako „wirus copyleft”, gdyż prowadzi do „zarażania wolnością” wszystkich programów pozostających w określonym związku z programem podstawowym, dystrybuowanym jako wolne oprogramowanie. Na tym właśnie polega „odwrócenie prawa autorskiego na lewą stronę”. W zamierzeniu twórców „copyleft”, licencjobiorcy podejmujący działania objęte jego zakresem nie mają prawnej możliwości wykorzystania monopolu autorskiego w celu ograniczania czterech wolności Stallmana.

Przedmiotem niniejszego artykułu jest próba ustalenia zakresu klauzuli „copyleft” w prawie polskim. Rozważania zostaną ograniczone do „copyleft” zawartego w GPL, lecz należy pamiętać, że o ile GPL stała się modelową umową licencyjną, na zasadach której licencjonowane jest ponad 70% wolnego oprogramowania,Dane w oparciu o serwis SourceForge, http://www.sourceforge.net. to w obrocie funkcjonuje wiele innych standardowych wzorców umownych zawierających postanowienia typu „copyleft”.Free Software Foundation publikuje długą listę licencji, klasyfikując je według kryteriów „wolności”, korzystania z klauzuli „copyleft” oraz zgodności z GPL (http://www.fsf.org/licenses/license-list.html). Zgodność (kompatybilność) z GPL jest rozumiana jako prawna możliwość łączenia programu licencjonowanego na zgodnej licencji z programem licencjonowanym na zasadach GPL.

W wyznaczeniu dokładnego zakresu „copyleft” zawartego w GPL należy wziąć przede wszystkim postanowienia samej umowy. Duże znaczenie przy interpretacji będą miały praktyczne uwarunkowania wynikające z konkretnych technik wykorzystywanych przy pisaniu programów komputerowych. Dodatkowo należy wziąć pod uwagę fakt, że GPL została napisana przede wszystkim z myślą o prawie amerykańskim i bezpośrednio nawiązuje do tamtejszych instytucji. Oprócz tego, istotną pomocą interpretacyjną powinna być praktyka obrotu i zwyczaje stosowane przez społeczność hakerską.W niniejszym artykule słowo „haker” używane jest poprawnie na określenie wysoce wykwalifikowanego programisty. Czytelnik chcący zapoznać się z kulturą hakerską powinien sięgnąć przede wszystkim do dostępnych w Internecie publikacji Stallmana, Erica S. Raymonda i innych aktywistów ruchu wolnego oprogramowania (Free Software, Open Source Software). Z uwagi na zakres niniejszego artykułu, analiza zwyczajów i praktyki zostanie ograniczona do zasad zawartych w „GPL Frequently Asked Questions” publikowanych przez Free Software Foundation. (http://www.fsf.org/licenses/gpl-faq.html). Wszystkie te czynniki zostaną kolejno rozważone w następnych częściach niniejszego artykułu, przed podjęciem próby analizy „copyleft” na gruncie prawa polskiego.

Zakres „copyleft” według GNU General Public License

Z przytoczonej powyżej Sec. 2 b) GPL wynika, że „copyleft” obejmuje utwory w całości lub w części zawierające lub zależne od programu lub każdej jego części. Postanowienie to jest precyzowane w dalszej części Sec. 2 następująco:

[Sec. 2 b)] requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.GPL Sec. 2, http://www.fsf.org/licenses/gpl.html (podkreślenie własne).

„Utwór oparty na programie” („work based on the Program”) definiowany jest jako modyfikacje kopii Programu lub jego części („You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program”).Id.

Z powyższego wynika ogólne stwierdzenie, że podstawowym wyznacznikiem zakresu klauzuli „copyleft” jest uprawnienie twórcy do kontroli utworów zależnych („derivative works”), a także uprawnienie do utworów wykorzystywanych w utworach zbiorowych („collective works”). Jednak precyzyjne określenie zakresu powyższych instytucji w stosunku do programów komputerowych nie jest rzeczą łatwą. Programy komputerowe wchodzą w rozmaite relacje ze sprzętem, użytkownikiem oraz innymi programami. Podczas pisania nowych programów na porządku dziennym jest korzystanie z programów już istniejących (tzw. „code reuse”), a techniki temu służące stale się rozwijają. W związku z tym w klauzuli „copyleft” nie poprzestano na samym tylko odwołaniu do przepisów prawa autorskiego. Z drugiej strony, nie było możliwe ujęcie jej zakresu w sposób kazuistyczny, gdyż zmuszałoby to do „nowelizacji” GPL wraz z rozwojem nauki informatyki.

Podstawowe informacje o technikach „code reuse”

Good programmers know what to write. Great ones know what to rewrite (and reuse).Eric S. Raymond, The Cathedral and The Bazaar, http://www.catb.org/~esr/writings/cathedral-bazaar/.

Autor niniejszego artykułu nie zamierza dyskutować zagadnienia, czy programowanie jest sztuką czy rzemiosłem. Jest jednak faktem, że oprócz pisania własnego kodu, duża część wysiłku programistów idzie w kierunku decydowania, które z gotowych komponentów wykorzystać w nowym programie i jak to zrobić, aby zasoby komputera były wykorzystane jak najlepiej.

Najprostszą metodą jest modyfikacja (przeróbka) istniejącego programu realizującego zadanie podobne do zadania, które chce rozwiązać autor nowego programu. Technika ta nie wymaga dłuższego tłumaczenia. Można jedynie zwrócić uwagę, że do efektywnego modyfikowania programu konieczny jest dostęp do jego kodu źródłowego, czyli zapisu w zrozumiałym dla człowieka języku programowania. Praktyka rozpowszechniania programów wyłącznie w kodzie wynikowym, umożliwiającym jedynie ich wykonywanie w komputerze skutecznie utrudnia dokonywanie jakichkolwiek modyfikacji. Dlatego też, publiczna dostępność kodu źródłowego programu jest jednym z warunków koniecznych dla uznania go za “wolne oprogramowanie”.

Programy komputerowe zapisane w kodzie źródłowym lub wynikowym stanowią zwykle część większej całości, określaną jako „oprogramowanie”, które tworzą wraz z (1) narzędziami deweloperskimi; (2) materiałami przygotowawczymi; (3) danymi wejściowymi; (4) wynikiem programu; (5) dodatkowymi materiałami (instrukcje, moduły pomocy) oraz (6) interfejsami (w tym graficznymi tzw. “look and feel” programu).Por. David Bainbridge, Software Copyright Law, 1-3 (Butterworths, London, Edinburgh, Dublin, 4th ed., 1999). Ponadto, elementy programu jako takiego można podzielić na tekstowe i pozostałe. Elementy tekstowe to właśnie zapis programu w kodzie źródłowym lub wynikowym. Pozostałe elementy to na przykład struktura programu (tak zwane SSO – structure, sequence and organization), wykresy (flow charts), struktura menu, czy interfejsy. W związku z tym, wykorzystanie cudzego programu może polegać nie tylko na zapożyczaniu tekstowych elementów, takich jak porcje kodu źródłowego. Ponieważ o wartości i przydatności programu decydują w ogromnym stopniu elementy nietekstowe, to właśnie one są zazwyczaj zapożyczane.

Podczas programowania niejednokrotnie zachodzi konieczność rozwiązywania zadań o charakterze mniej lub bardziej standardowym. Poza tym, prawie każde oprogramowanie, oprócz swego głównego zadania musi wykonywać funkcje dla niego niespecyficzne. W celu uniknięcia konieczności pisania tego samego od nowa przy tworzeniu kolejnego oprogramowania, udostępniane są tak zwane biblioteki (libraries). Biblioteka nie jest samodzielnym programem, zawiera jedynie zbiór przydatnych zmiennych, danych, funkcji, procedur lub większych modułów (podprogramów). Wykorzystanie bibliotek w programach określane jest jako „łączenie” (linking) i dzielone na statyczne i dynamiczne.

Łączenie statyczne polega na połączeniu biblioteki i programu w jednym pliku. Dokonuje się to w momencie translacji programu, czyli procesu, który zamienia zrozumiały dla człowieka program w kodzie źródłowym na wykonywalny plik napisany w kodzie wynikowym. Tak stworzony program rozprowadzany jest razem z połączoną z nim biblioteką. W dalszej części artykułu za łączenie statyczne będzie również uważane wszelkie inne połączenie dwóch programów w jednym pliku prowadzące do ich wspólnej dystrybucji, nawet jeżeli żaden z nich nie jest biblioteką.

Łączenie dynamiczne jest o wiele bardziej popularną techniką programowania, ale też prowadzi do znacznie bardziej skomplikowanej sytuacji, zwłaszcza pod względem prawnym. W pliku programu umieszczane są jedynie odwołania, które powodują wykorzystanie odpowiednich bibliotek przez komputer w momencie ładowania programu (loadtime linking) lub nawet dopiero podczas jego wykonywania (runtime linking). Łączenie dynamiczne pozwala na uniknięcie konieczności dystrybucji bibliotek wraz z programem; są one dostępne bezpośrednio w komputerze użytkownika i stanowią część systemu operacyjnego, na którym wykonywany jest program. Ponadto, dołączenie dynamiczne biblioteki nie musi oznaczać jej faktycznego wykorzystania przez program, gdyż ostateczna „decyzja” o tym podejmowana jest przez komputer użytkownika, a nie przez programistę. Może wobec tego dojść do sytuacji, w której dojdzie do dołączenia innej dynamicznej biblioteki niż ta, którą wybrał autor programu.

Pojęcie łączenia dynamicznego można rozszerzyć, dla potrzeb niniejszego artykułu, na pozostałe subtelne sposoby wykorzystania programów przez inne programy. Na przykład, serwer www, taki jak Apache Web Serwer może zostać wyposażony w dynamicznie ładowalny moduł zawierający język skryptowy, taki jak PHP. Ponadto, programy mogą komunikować się między sobą, wykorzystując publiczne zestawy interfejsów („application program interface” (API)). Ciekawym przykładem takiej interakcji pomiędzy systemami jest program Wine, który emuluje publiczny zestaw procedur systemu Windows i pozwala na uruchamianie programów pisanych dla tego systemu na komputerze działającym pod systemem Linux. Współpraca programów może odbywać się także na poziomie protokołów komunikacyjnych. Można tu wymienić na przykład program Samba, który umożliwia podłączenie komputera z systemem Linux/Unix do sieci obsługiwanej przez system Windows z wykorzystaniem protokołów SMB/NMB tego systemu.

Rozmiar niniejszego artykułu nie pozwala na bardziej dokładne opisanie technik wykorzystania cudzego kodu w programach. Czytelnik powinien mieć jednak świadomość, że powyższe informacje są dużym uogólnieniem. Dostępne są rozmaite języki programowania oraz systemy operacyjne, z których każdy umożliwia lub wymusza stosowanie określonych technik.

Zakres klauzuli „copyleft” w prawie amerykańskim

GPL operuje amerykańskim językiem prawniczym i wprost odwołuje się do instytucji skodyfikowanych w Copyright Act.Copyright Act of the United States of America, 17 U.S.C. Sec. 101-1332 (1976, z późn. zm.). Analizując klauzulę „copyleft” należy przede wszystkim pamiętać o następujących definicjach zawartych w Sec. 101 tej ustawy:

A „collective work” is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.
A „derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a „derivative work”.

Punktem wyjścia w rozważaniach o zakresie klauzuli „copyleft” powinno być ogólne ustalenie zakresu znaczenia „derivative work” oraz „collective work” w odniesieniu do programów komputerowych. Do powstania „derivative works” niewątpliwie prowadzi skopiowanie elementów programu chronionych przez prawo autorskie. Fakt skopiowania tekstowych elementów programu stosunkowo łatwo ustalić przez porównanie zapisów programów. W celu ustalenia czy doszło do wykorzystania nietekstowych elementów i czy wykorzystanie to podlega zakresowi prawa autorskiego, sądy amerykańskie wykształciły szereg testów, z których najbardziej znanym jest Abstraction-Filtration-Comparison Test (dalej „AFC”) ustanowiony w orzeczeniu Computer Associates, Inc. v. Altai, Inc.982 F 2d 693, 706 (2nd Cir 1992). Bazuje on na podstawowej zasadzie prawa autorskiego, nakazującej udzielanie ochrony sposobom wyrażenia idei, a nie samym ideom.

W pierwszej fazie AFC sąd wyróżnia w badanym programie tak zwane poziomy abstrakcji (levels of abstraction), których przykłady wymienia Ravicher: główny cel programu, jego architektura, abstrakcyjne typy danych, algorytmy, struktury danych, kod źródłowy i kod wynikowy.Dan Ravicher, Software Derivative Work: A Circuit Dependent Determination, 3 http://www.pbwt.com/Attorney/files/ravicher_1.pdf. W następnej fazie testu każda z części programu otrzymanych w fazie pierwszej poddawana jest „filtrowaniu” w poszukiwaniu materiału objętego ochroną prawnoautorską. Odrzucane są: (1) idee, (2) sposoby wyrażenia incydentalne w stosunku do wyrażanych idei powodujące połączenie idei i wyrażenia w jedno (merger doctrine), oraz (3) sposoby wyrażenia podyktowane czynnikami zewnętrznymi, jak na przykład wymogi kompatybilności (scenes a faire). Dodatkowo odrzucane są (4) elementy należące do public domain lub też (5) niespełniające wymogu oryginalności. W ostatniej fazie dokonywane jest porównanie elementów objętych ochroną prawnoautorską otrzymanych w dwóch poprzednich fazach, z drugim programem i ustalenie, czy elementy te zostały skopiowane. Oceniane jest nie tylko, czy chronione elementy zostały skopiowane, ale też ich relatywny wkład w porównaniu do całego programu.

AFC uznawany jest za jedną z najbardziej wyrafinowanych oraz rygorystycznych metod ustalania, które elementy programu komputerowego zasługują na ochronę. O ile rzadko zdarza się aby ochrona nie została udzielona zapisowi programu w którejkolwiek z postaci kodu, to zastosowanie AFC prowadzi do znacznego rozszerzenia możliwości kopiowania elementów nietekstowych. Wszystkie te elementy, które nie są chronione przez prawo autorskie mogą być wykorzystywane w nowych programach bez ograniczeń. W związku z tym, nie mogą one zostać objęte przez klauzulę „copyleft”. Należy zatem stwierdzić, że w porównaniu do kopiowania nietekstowych elementów programu, twórcza modyfikacja zapisu programu prowadzi do powstania opracowania ze znacznie większym prawdopodobieństwem.Niektóre modelowe licencje wolnego oprogramowania ograniczają zasięg ich klauzul „copyleft” wyłącznie do modyfikacji programu. Por. Mozilla Public License, v. 1.1, http://www.mozilla.org/MPL/MPL-1.1.html.

Amerykańskie prawo autorskie zalicza prawo do tworzenia „derivative works” do monopolu autorskiego.17 U.S.C. Sec. 106. Opracowanie jest przedmiotem prawa autorskiego niezależnie od oryginału, jednakże ochrona nie rozciąga się na utwory, w których chroniony materiał został użyty niezgodnie z prawem.17 U.S.C. Sec. 103(a). Jeżeli zatem opracowanie zostało stworzone bez zgody twórcy oryginału lub poza zakresem dozwolonego użytku (fair use exception), to nie podlega ochronie prawa autorskiego (infringing derivative). Amerykańska doktryna jest zgodna, że prawa autorskie do takiego opracowania nie przynależą ani twórcy oryginału, ani naruszycielowi, jednak nie dostarcza pozytywnej odpowiedzi na temat ich statusu prawnego. Lemley uważa, że takie opracowanie należy do public domain.Mark A. Lemley, The Economics of Improvement in Intellectual Property Law, 75 Texas Law Review 989, 1022 (1997). W takim przypadku, bezprawne opracowania nie tylko umykałyby klauzuli „copyleft”, lecz stanowiłyby sposób na „zawłaszczenie” wolnego programu z wykorzystaniem mechanizmu opisanego wcześniej. Należy jednak zwrócić uwagę, że prawdopodobieństwo powstania bezprawnego opracowania wolnego programu jest znikome, gdyż GPL zezwala na dokonywanie wszelkich modyfikacji.Istnieje bogate orzecznictwo i literatura amerykańska dotycząca zagadnienia ważności i możliwości egzekwowania licencji „shrink-wrap” oraz „click-wrap” (do których zalicza się GPL), z punktu widzenia prawa zobowiązań. W określonych przypadkach może dojść do sytuacji, gdy licencja nie będzie wiązać stron (Step-Saver Data Sys., Inc. v. Wyse Tech. 939 F.2d 91 (3d Cir. 1991), Specht v. Netscape Communications Corp. 306 F.3d 17 (2nd Cir. (N.Y.) 2002), Kevin W. Grierson, Enforceability of “Clickwrap” or “Shrinkwrap” Agreements Common in Computer Software, Hardware, and Internet Transactions, 106 American Law Reports 5th 309). W konsekwencji, wobec braku prawnie skutecznej zgody na dokonywanie opracowań, modyfikacje programu będą opracowaniami bezprawnymi.

Ustalenie dokładnego zakresu klauzuli „copyleft” komplikuje się jeszcze bardziej wobec istnienia technik wykorzystania cudzego kodu znacznie bardziej wyrafinowanych od zwykłego kopiowania i modyfikowania programu. Ogólną strategią stosowaną przez doktrynę amerykańską jest próba ustalenia, czy techniki te prowadzą do powstania „derivative works” lub chociaż „collective works”.

Opisane powyżej statyczne dołączanie bibliotek do programu bywa zwykle klasyfikowane jako tworzenie utworu zbiorowego (collective work). Na dystrybucję takich utworów, podobnie jak na dystrybucję opracowań, konieczna jest zgoda uprawnionych do utworów tworzących ich części składowe.Lee A. Hollaar, Legal Protection of Digital Information, VI.D.4, http://digital-law-online.info/lpdi1.0/treatise27.html Wydaje się zatem, że statyczne dołączenie wolnego programu powoduje uaktywnienie zobowiązań określonych w klauzuli „copyleft”. Z drugiej strony, GPL uznaje proste zebranie („mere aggregation”) programów za nie objęte jej zakresem. Free Software Foundation stoi na stanowisku, że proste zebranie programów to po prostu rozpowszechnianie ich na wspólnym medium, natomiast połączenie programów w jeden plik wykonywalny zdecydowanie jest objęte klauzulą „copyleft”.Free Software Foundation, Frequently Asked Questions about the GNU GPL, http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation Są to jednak przykłady skrajne, a pomiędzy nimi może istnieć wiele stanów pośrednich.

W przypadku bibliotek połączonych dynamicznie z programem nie dochodzi do wspólnej dystrybucji programu i bibliotek. Dysponowanie bibliotekami jest sprawą użytkownika i część autorów uważa, że to on musi wykazać się uprawnieniem do korzystania z nich.Hollaar, przyp. 21. W takim przypadku, autor programu połączonego dynamicznie z wolnym programem nie byłby zobowiązany z tytułu „copyleft”. Dyskusyjne jest też, czy obowiązkom wynikającym z tej klauzuli podlegaliby użytkownicy takich programów, gdyż jako nieuprawnieni z praw autorskich do nich, nie mieliby prawnej możliwości wypełniania jej postanowień (impossibilia nemo obligatur).

Doktryna amerykańska nie jest zgodna, czy dynamiczne łączenie prowadzi do stworzenia opracowania programu. Rosen twierdzi, że dynamiczne łączenie to jedynie przejściowa relacja pomiędzy programami i nie prowadzi ono do zmodyfikowania programu łączonego.Lawrence Rosen, The Unreasonable Fear of Infection, 2, http://rosenlaw.com/html/GPL.PDF. Rozumowanie to opiera się jednak na definiowaniu opracowań jako efektów takiej, czy innej modyfikacji utworu oryginalnego. Free Software Foundation natomiast stoi na stanowisku, że zarówno statyczne, jak i dynamiczne łączenie programów prowadzi do powstania dzieł połączonych i w związku z tym podlega zakresowi klauzuli „copyleft”.Free Software Foundation, Frequently Asked Questions about the GNU GPL, http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL i następne. Stanowisko to, wyrażone w publikowanych przez tą organizację odpowiedziach na pytania zadawane w związku z interpretacją GPL powinno mieć duże znaczenie przy stosowaniu tej licencji, choć trzeba przyznać, że jest ono bardzo rygorystyczne.Przyjęcie podobnego stanowiska wobec dynamicznie łączonych bibliotek dostępnych wraz z systemem Windows doprowadziłoby do całkowitej monopolizacji rynku aplikacji przez firmę Microsoft, przez oddanie jej prawnej kontroli nad dystrybucją programów korzystających z takich bibliotek. Free Software Foundation sama przyznaje, że ostateczną odpowiedź na powyższe kontrowersje należy pozostawić sądom, które powinny brać pod uwagę zarówno mechanizm (sposób) komunikacji pomiędzy programami, jak i zawartość tej komunikacji (rodzaj wymienianych informacji).Free Software Foundation, Frequently Asked Questions about the GNU GPL, http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation

Jednym z najbardziej istotnych programów udostępnionych na licencji GPL jest jądro Linux. Ponieważ stanowi ono podstawę systemu operacyjnego GNU/Linux, to wszyscy piszący oprogramowanie dla tego systemu muszą zadać sobie pytanie, czy ich twórczość nie jest objęta zakresem klauzuli „copyleft”. Linus Torvalds, oprócz wielokrotnego wypowiadania swojego zdania w konkretnych przypadkach,Patrz np. http://www.kerneltraffic.org/kernel-traffic/kt20031226_246.html#1 lub też http://www.kerneltraffic.org/kernel-traffic/kt20021021_189.html#32. zdecydował się na opatrzenie Linuksa następującą adnotacją:

NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of “derived work”. …Linus Torvalds, Note to Linux Kernel, http://www.linux.de/linux/gnu.html.

Oczywiście poprawne jest stwierdzenie, że zwykłe programy pisane w celu uruchamiania na komputerze działającym pod systemem Linux, należące do tak zwanego „obszaru użytkownika” (user area) nie są objęte klauzulą „copyleft”. Wynika to chociażby z wyjęcia spod ochrony prawa autorskiego sposobów wyrażenia podyktowanych zewnętrzną koniecznością lub może być dodatkowo uzasadnianie działaniem w zakresie dozwolonego użytku systemu operacyjnego. Jednak przy ustalaniu gdzie kończy się system operacyjny, a zaczyna obszar użytkownika, nauka informatyki napotyka podobne trudności jak teoria prawa, usiłując rozgraniczyć utwory zależne od samoistnych.

Wyznaczniki zakresu klauzuli „copyleft” w prawie polskim

Wyłączenie ochrony dla idei i zasad

Rozważania dotyczące zakresu klauzuli „copyleft” w prawie polskim należy rozpocząć, podobnie jak w przedstawionej powyżej pobieżnej analizie prawa amerykańskiego, od stwierdzenia, że nie może on wykraczać poza granicę prawnej ochrony utworów. Granica ta wyznaczana jest w prawie polskim w art. 1 ust 21 prawa autorskiego, który głosi, że ochroną objęty może być wyłącznie sposób wyrażenia, a nie odkrycia, idee, procedury, metody i zasady działania oraz koncepcje matematyczne. Dodatkowo, w odniesieniu do programów komputerowych art. 74 ust. 2 stanowi, że

[o]chrona przyznana programowi komputerowemu obejmuje wszystkie formy jego wyrażenia. Idee i zasady będące podstawą jakiegokolwiek elementu programu komputerowego, w tym podstawą łączy, nie podlegają ochronie.

Zatem, polskie prawo autorskie nakazuje stosować tę samą podstawową regułę prawa autorskiego, która została wykorzystana przez sądy amerykańskie w orzeczeniach takich jak Altai.Patrz przypis 14. Nie oznacza to jeszcze, że sposób ustalania, które elementy programu podlegają ochronie prawnoautorskiej będzie na gruncie prawa polskiego przebiegał według testu AFC. Interpretacja polskich przepisów uwarunkowana będzie wynikami dyskusji doktryny polskiej nad zakresem pojęć „treść” i „forma” dzieła, czy też wynikiem przyjęcia określonego stanowiska w sprawie jego budowy (por. koncepcja jednolitej budowy dzieła BłeszyńskiegoJan Błeszyński, Tłumaczenie i jego twórca w polskim prawie autorskim, (Warszawa 1973). z teorią budowy trójwarstwowej KopffaA. Kopff, Wpływ postępu techniki na prawo autorskie, w: 48 Prace z wynalazczości i ochrony własności intelektualnej 104 (1988).).

Nowicka twierdzi, że szczególny przepis art. 74 ust. 2 zwalnia w przypadku programów komputerowych od konieczności rozgraniczania formy od treści dzieła.Aurelia Nowicka, Prawnoautorska i patentowa ochrona programów komputerowych, 116-117 (Dom Wydawniczy ABC 1995). Zgodnie z literalnym brzmieniem przepisu, uważa ona „idee” i „zasady” za wyłączone spod ochrony. Natomiast podlegające ochronie „wszystkie formy wyrażenia” rozumie jako równoznaczne z „postacią wyrażenia” i zbliżone do pojęcia „sposób wyrażenia” występującego w art. 1 ust. 1. Golat z kolei uważa, że wyłączenie „idei” i „zasad” nie uzasadnia jeszcze utożsamiania tych pojęć z warstwą treściową programu i nie oznacza wyłączenia wszelkiej treści programu spod ochrony.Katarzyna Golat i Rafał Golat, Prawo komputerowe (Zagadnienia podstawowe), 41 (Wydawnictwo Prawnicze, Warszawa 1998).

Powyższe rozumowanie prowadzi do dość oczywistego i w zasadzie niekwestionowanego stwierdzenia, że ochronie podlega zapis programu w którejkolwiek z postaci kodu. Pozostaje zatem problem ustalenia zakresu ochrony dla elementów nietekstowych programu. Golat uznaje, że nie podlegają ochronie nie tylko generalne idee programu, ale także te bardziej szczegółowe.Id. 43. Ponadto, odróżnia on algorytmy matematyczne, czyli metody rozwiązania problemu przedstawione w postaci ciągu działań matematycznych, których opracowanie ma charakter odkrywczy, a nie twórczy,Id. 47. od algorytmów informatycznych, definiowanych jako „logicznie uporządkowany zestawy instrukcji, których realizacja zgodnie z odpowiednimi regułami pozwala na rozwiązanie szczegółowych problemów w ramach stanowiącego podstawę opracowania programu komputerowego docelowego zagadnienia.”Id. 45. Według tego podziału, algorytm matematyczny miałby stanowić niepodlegającą ochronie sferę treści algorytmu informatycznego podczas gdy chroniona forma tego wyrażenia byłaby graficznym lub opisowym przedstawieniem sposobu zastosowania algorytmu matematycznego. Ta forma, to nic innego jak „struktura programu, znajdująca wyraz w sposobie ukształtowania (architekturze) zestawu instrukcji”.Nowicka, przyp. 33, s. 124.

Podsumowując ten etap rozważań, można powtórzyć za Nowicką, że poszukiwanie granic ochrony prawa autorskiego programów komputerowych na gruncie prawa polskiego może prowadzić do podobnych rezultatów, jak stosowanie testu AFC przez sądy amerykańskie.Id. 125. W szczególności, proponowane przez Golata odróżnienie algorytmu matematycznego od informatycznego można porównać do zastosowanego w Altai wyróżnienia poziomów abstrakcji programu. Nie jest jednak oczywiste, czy na gruncie prawa polskiego „filtracja” elementów chronionych programu prowadzić będzie do takich samych wyników, jak faza druga testu AFC, w której sądy amerykańskie stosują nieznane sądom polskim doktryny „merger” oraz „scenes a faire”.

Należy także pamiętać, że Altai jest wiążącym prawem w 2nd Circuit, a w pozostałych okręgach USA może stanowić tak zwane „persuasive authority” w sprawach o podobnym stanie faktycznym. Tymczasem wypowiedzi polskiej doktryny mają charakter całkowicie niewiążący, a brak jest bardziej szczegółowych przepisów ustawowych w tym zakresie. Oznacza to, że w prawie polskim istnieje znacznie wyższe ryzyko prawne związane z dokładnym ustaleniem zakresu ochrony programów komputerowych i, co jest tego logiczną konsekwencją, zakresu klauzuli „copyleft”.

Dozwolony użytek

Klauzula „copyleft” nie tylko nie obejmuje elementów programu wyłączonych spod zakresu ochrony prawa autorskiego, ale też nie może być stosowana wobec tych chronionych elementów, których wykorzystanie jest możliwe zgodnie z przepisami o dozwolonym użytku chronionych utworów.

Zakres dozwolonego użytku w stosunku do programów komputerowych, który wchodziłby w grę przy próbie ominięcia klauzuli „copyleft” wydaje się znacznie ograniczony. Przepis szczególny art. 77 prawa autorskiego wyłącza stosowanie do programów komputerowych większości przepisów oddziału 3 rozdziału 3 ustawy. Niemniej jednak, poza zakresem wyłączenia pozostaje art. 29, który w części istotnej dla potrzeb niniejszego artykułu określa dozwolone granice cytowania. Golat uważa, że przepis ten może stanowić uzasadnienie dla przytaczania cudzych programów w programach nowo tworzonych.Golat, przyp. 34, s. 144. Niestety, doktryna polska nie dostarcza więcej wskazówek na temat granic dopuszczalności takiego przytaczania. W szczególności, według najlepszej wiedzy autora niniejszego artykułu, nie dokonano do tej pory analizy różnorodności możliwych stanów faktycznych pojawiających się w związku z korzystaniem z technik „code reuse” pobieżnie opisanych powyżej.

Art. 29 zezwala na przytaczanie urywków rozpowszechnionych utworów lub drobnych utworów w całości, w zakresie uzasadnionym, między innymi, prawami gatunku twórczości. Niewątpliwie, prawem gatunku twórczości, jaką jest programowanie, będzie wykorzystanie gotowych bibliotek lub modułów w nowym programie. Być może należałoby zastanowić się, czy ruch wolnego oprogramowania, ze swoimi normami moralnymi, zwyczajami oraz interpretacją GPL promowaną przez jej twórców, nie stanowi specyficznego gatunku twórczości. Prawem tego gatunku byłoby daleko idące zezwolenie na cytowanie, lecz z zastrzeżeniem przestrzegania klauzul „copyleft”. Nie jest jednak jasne, czy „copyleft” jako prawo gatunku twórczości może sięgać tak daleko, aby wymagać publikacji kodów źródłowych od wszystkich, którzy zawarli w swoich programach nawet niewielki cytat pochodzący z wolnego programu.

Opracowania

Instytucja „derivative works”, do którego odwołuje się klauzula „copyleft” GPL utożsamiana jest zwykle z opracowaniem cudzego utworu, regulowanym przez art. 2 polskiego prawa autorskiego.Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. (Dz. U. 1994 Nr 24 poz. 83, z późn. zm.) W doktrynie polskiej zaprezentowane zostało stanowisko, że uregulowanie kwestii zakresu autorskich praw majątkowych do programu komputerowego w art. 74 ust. 4 pkt 2 stanowi lex specialis w stosunku do przepisów o opracowaniu. Jakkolwiek jest to stanowisko przekonujące, to nie wydaje się, aby w takim razie czynności wyliczone w art. 74, czyli tłumaczenie, przystosowywanie, zmiana układu lub jakiekolwiek inne zmiany w programie komputerowym, nie mogły zostać objęte przez klauzulę „copyleft”. Odwołanie do instytucji opracowania zawarte w przywołanym w niniejszym artykule fragmencie GPL ma charakter wskazówki interpretacyjnej, a szczegółowe postanowienia tej umowy włączają do zakresu „copyleft” utwory w całości lub w części zawierające lub zależne od programu lub każdej jego części. Czynności wyliczone w art. 74 ust. 4 pkt 2 prowadzą do powstania takich utworów.

Byrska przyjmuje, że czynności te mogą być podejmowane przez inne osoby niż twórca oryginału, ale prawa majątkowe do utworów powstałych w ich wyniku przysługują wyłącznie uprawnionemu do programu wyjściowego.Małgorzata Byrska, Prawne aspekty modyfikowania programu komputerowego, 4 Kwartalnik Prawa Prywatnego, 693, 715 (1996). Tymczasem, przywołane powyżej przepisy amerykańskiego prawa autorskiego za uprawnionego uznają twórcę opracowania. Z kolei opracowania bezprawne, dokonane bez zgody twórcy oryginału, część doktryny amerykańskiej uważa za należące do public domain.Patrz tekst przy przyp. 19. Podobny pogląd w literaturze polskiej głosi Nowicka, która uważa opracowania programu dokonane bez zgody twórcy za wyłączone spod przedmiotu prawa autorskiego.Nowicka, przyp. 33, s. 134. Zdecydowanie najbardziej korzystnym stanowiskiem dla ruchu wolnego oprogramowania jest przyznanie praw do modyfikacji programu uprawnionemu do oryginału. W tym przypadku mógłby on bezpośrednio domagać się respektowania czterech wolności Stallmana, bez konieczności powoływania się na postanowienia licencji. Doktryna polska nie jest jednak zgodna w tym zakresie.Por. np. J. Barta, M. Czajkowska-Dąbrowska, Z. Ćwiąkalski, R. Markiewicz, E. Traple, Ustawa o prawie autorskim i prawach pokrewnych. Komentarz, teza 23 do art. 74 (Dom Wydawniczy ABC, 2001, wyd. II) „Zdecydowanie brak podstaw do interpretacji, że na tle [art. 74] prawo do opracowania programu komputerowego przysługuje osobie uprawnionej do programu pierwotnego”.

Osobnego rozważenia na gruncie prawa polskiego wymagają skutki stosowania pozostałych technik wykorzystania cudzego kodu, wykraczające poza zwykłe kopiowanie i modyfikacje. W zależności od zajmowanego stanowiska można zastanawiać się, czy prowadzą one do stworzenia opracowania programu, czy też, wobec uznania, że art. 2 prawa autorskiego nie ma do programów zastosowania, do powstania tłumaczenia, przystosowywania, zmiany układu lub jakiekolwiek innej zmiany w programie komputerowym. Zwraca uwagę, że przyjęcie tego drugiego stanowiska prowadziłoby logicznie do możliwości wykorzystania przywołanej wcześniej interpretacji Rosena, który uważa dynamiczne łączenie za nieobjęte klauzulą „copyleft”, gdyż nie powoduje ono zmian w łączonych programach.Patrz przypis 24.

Do ciekawych wniosków prowadzi próba oceny wykorzystania wolnych programów w nowych programach jako kontynuacji utworów. Traple rozróżnia kontynuacje dzieła rozpoczętego i nie ukończonego od kontynuacji w sensie dopisania dalszego ciągu do dzieła zamkniętego.Barta et. al, przyp. 45, teza 29 do art. 2. W tym momencie trzeba zwrócić uwagę na specyfikę przemysłu informatycznego, który w odróżnieniu od bardziej tradycyjnych dziedzin twórczości ludzkiej nie przyjmuje za cel wytworzenia dzieła skończonego. Wręcz, za zasadę można uznać dążenie do ciągłego udoskonalania programów w celu przystosowywania ich do zmieniającego się otoczenia, czyli na przykład postępu technicznego oraz wymagań użytkowników. Odbiorcy tej specyficznej kategorii utworów, jakimi są programy komputerowe, także nie oczekują, że zostanie im przedstawiony gotowy produkt finalny. Niemożliwe jest bowiem przewidzenie wszystkich stanów zachodzących w komputerze podczas wykonywania programów, w związku z czym każdy z nich zawiera takie czy inne błędy („bugs”). Na porządku dziennym jest tworzenie nowych wersji („upgrades”, „updates”) i uaktualnień programów („patches”, „service packs”) mających usuwać te błędy.Zwolennicy ruchu wolnego oprogramowania podkreślają, że opisana właśnie specyfika produkcji programów czyni z udostępniania kodów źródłowych oraz z zezwolenia na modyfikację programu wspaniały środek do zapewnienia szybszego i bardziej efektywnego usuwania błędów. Nie sposób się nie zgodzić z tym twierdzeniem, lecz jego uzasadnienie wykraczałoby poza zakres niniejszego artykułu.

W związku z powyższym wydaje się całkowicie uzasadnione, by znakomitą większość programów traktować jako dzieła rozpoczęte i nie ukończone. Jeżeli tak, to dopisanie przez licencjobiorcę wolnego oprogramowania fragmentu kodu mającego na celu poprawienie błędów odkrytych w takim programie prowadzić będzie do powstania opracowania programu.Barta et. al, przyp. 45, teza 29 do art. 2. Oczywiście, w zależności od stanu faktycznego możliwe jest także powstanie utworów współautorskich. Jest to jednak poza zakresem niniejszego artykułu, którego celem jest ustalenie zakresu obowiązku wynikającego z klauzuli „copyleft” w stosunku do licencjobiorcy. Zakładamy zatem, że stan faktyczny nie polega na działaniu w porozumieniu w celu wspólnego opracowania programu, choć takie sytuacje są niezwykle częste w ramach ruchu wolnego oprogramowania. Z kolei wykorzystanie wolnej biblioteki lub modułu w nowym programie należałoby rozważać jako kontynuację utworu zamkniętego, która będzie mogła zostać uznana za opracowanie jeżeli doszło do wykorzystania oryginalnych elementów tej biblioteki czy modułu.

Wątpliwości powoduje brak faktycznego zawarcia w nowym programie wykorzystanego wolnego programu w przypadku skorzystania przez licencjobiorcę GPL z technik łączenia dynamicznego. Pliki poprawiające błędy programu („patches”) także są zwykle dostępne bez programu naprawianego; zawierają jedynie poprawione instrukcje i informacje, w którym miejscu oryginalnego pliku ma zostać dokonana zamiana elementów kodu źródłowego. Oznacza to, że program oryginalny nie jest rozpoznawalny w programie, który jest jego poprawką lub jest z nim dynamicznie połączony. W takim wypadku, zdaniem Traple, nie dochodzi do powstania opracowania.Barta et. al, przyp. 45, teza 30 do art. 2 (krytykując orzeczenie SN IK z 26 listopada 1930 r., OSP 1931 nr 10 poz. 87, w którym Sąd Najwyższy znalazł naruszenie prawa autorskiego w sporządzeniu klucza do wcześniej opublikowanych ćwiczeń do łaciny dla uczniów szkół średnich, w skutek uznania klucza za tłumaczenie, czyli za opracowanie ćwiczeń).

Zbiory, utwory zbiorowe, utwory połączone

Alternatywą wobec uznania efektów stosowania technik „code reuse” za opracowania programu lub względnie za objęte hipotezą art. 74 ust. 4 pkt 2), jest interpretacja prowadząca do zaklasyfikowania ich jako zbioru (art. 3), utworu zbiorowego (art. 11) lub utworów połączonych w celu wspólnego rozpowszechniania (art. 10). Ponieważ ostatni wariant wyraźnie zakłada istnienie porozumienia pomiędzy autorami łączonych programów, jego rozważanie w niniejszym artykule zostanie pominięte, podobnie jak rozważanie dotyczące współautorstwa programów (patrz wyjaśnienia w przyp. 49).

Co do pozostałych wariantów należy uznać, że podlegają one klauzuli „copyleft” z uwagi na przewidziane zarówno w art. 3, jak i w art. 11 zachowanie praw do utworów wykorzystanych w zbiorach i utworach zbiorowych. Oczywiście i tu pojawiają się wątpliwości związane z dynamicznym łączeniem, które skutkuje brakiem faktycznego współwystępowania programów w jednym dziele. Natomiast w sytuacji statycznego połączenia programów, zarówno wynikające z art. 3 zachowanie prawa do wykorzystanych utworów, jak i uregulowane w art. 11 przyznanie praw do poszczególnych części mających samodzielne znaczenie ich twórcom, prowadzi do wniosku, że autorzy programu wchodzącego w skład zbioru lub utworu zbiorowego zachowują monopol autorski. Tym samym, mogą oni stawiać warunki, na jakich dystrybuowana będzie całość zawierająca ich program, a przestrzeganie klauzuli „copyleft” stanowi taki właśnie warunek.

Trzeba w tym momencie podkreślić, na co ustawicznie zwracają uwagę propagatorzy ruchu wolnego oprogramowania, że obowiązki z tytułu klauzuli „copyleft”, a w szczególności obowiązek publikacji kodów źródłowych, uaktywniają się dopiero w momencie podjęcia przez licencjobiorcę GPL rozpowszechniania programów opartych na wolnym programie. Zatem, korzystanie we własnym zakresie z programów w ten czy w inny sposób połączonych z wolnym oprogramowaniem oraz utrzymywanie w tajemnicy ich kodów źródłowych jest całkowicie zgodne z GPL.

Jak to już zostało zasygnalizowane (patrz tekst do przyp. 22) zakres klauzuli „copyleft” nie obejmuje prostego zebrania programów w celu wspólnej dystrybucji. W związku z tym, i na gruncie prawa polskiego pojawi się konieczność rozróżnienia co jest prostym zebraniem programów, a co prowadzi do stworzenia zbioru lub utworu zbiorowego. Wydaje się, że istotną wskazówką jest tu wymóg twórczego charakteru ustanawianego dla doboru, układu lub zestawienia utworów w zbiorze, przyjęty w art. 3. W odniesieniu do zbioru programów komputerowych, „twórczy charakter” mógłby przejawiać się w nowej funkcjonalności zbioru, która nie istnieje w przypadku programów istniejących oddzielnie, gdy każdy z nich realizuje swoje zadanie bez interakcji z innymi.

Wnioski

Przedstawiona powyżej analiza nie dostarcza odpowiedzi na pytanie o zakres klauzuli „copyleft” w prawie polskim i wydaje się, że wyraźne jego ustalenie po prostu nie jest możliwe. Powody takiego stanu rzeczy są złożone. Po pierwsze, wynikają one z ogólnego charakteru sformułowań GPL, której twórcy chcieli stworzyć coś w rodzaju modelowego prawa wolnego oprogramowania, a nie umowę licencyjną odnoszącą się do konkretnego stanu faktycznego. Po drugie, wynikają one właśnie ze złożoności stanów faktycznych występujących w przemyśle informatycznym, co potęguje jeszcze ciągły jego rozwój.

Na te czynniki nakłada się trzeci, jakim są meandry przepisów, orzecznictwa i doktryny prawa autorskiego. Analiza klauzuli „copyleft” w tym kontekście przywołuje jedynie odwieczne problemy nauki tej dziedziny prawa z ustaleniem co jest niechronioną ideą, a co chronionym sposobem jej wyrażenia, jakie są granice dozwolonego użytku, czy też w którym momencie autor przestaje być tylko inspirowany cudzym utworem i zaczyna dokonywać jego opracowania. Oczywiście, w konkretnym stanie faktycznym wszystkie koncepcje teoretyczne analizowane w niniejszym artykule będą musiały zostać w jakiś sposób zastosowane. Co istotne, po lekturze orzeczeń takich jak Altai okazuje się, że zakres ochrony prawa autorskiego ustalany jest, generalnie rzecz biorąc, z zachowaniem spójności, a efekty stosowania tego prawa mają społeczno-ekonomiczny sens.

Podsumowując, warto podkreślić, że trudności w ustaleniu zakresu klauzuli „copyleft” istnieją tylko na styku pomiędzy prawem autorskim a domeną publiczną. W sytuacjach bardziej typowych, gdy dochodzi do skopiowania elementów bez wątpienia chronionych lub, gdy dokonano ewidentnej modyfikacji wolnego programu, wniosek o objęciu takich działań obowiązkami wynikającymi z GPL powinien nasuwać się bez większych przeszkód. Z nieco większą ostrożnością można sformułować pogląd, że klauzuli „copyleft” podlegają także programy łączone statycznie z wolnym oprogramowaniem. Natomiast próby rozszerzenia jej zakresu na łączenie dynamiczne należałoby ocenić jako bardzo ryzykowne. W związku z tym, zakres „copyleft” w prawie polskim i w prawie amerykańskim kształtuje się podobnie.

Warto oprócz tego pamiętać, że klauzula „copyleft” nie została napisana w celu zastawienia pułapki na nieuważnego licencjobiorcę, ale ma na wskroś prospołeczny charakter. Ma ona bowiem chronić interesy osób zaangażowanych w tworzenie wolnego oprogramowania oraz uniemożliwiać monopolizowanie efektów tej pracy przez nieuczciwych gapowiczów, których działania mogłyby doprowadzić do ograniczenia społecznego prawa dostępu do tego oprogramowania. Zatem, obowiązki wynikające z klauzuli „copyleft” kończą się tam, gdzie zaczynają się prawa innych – co ujęte zostało w następującym postanowieniu licencji: „it is not the intent of this section to claim rights or contest your rights to work written entirely by you.”Patrz przyp. 9.

Przypisy