Open Source

Trochę dłuższa analiza (cz. 2)

Kolejna dawka opowieści o open source. Dziś – copyleft, a dokładnie GPL, standardowe i mniej standardowe scenariusze użycia.

Deeper dive: licencje copyleft – silne, słabe i ich praktyczne konsekwencje

Zachęcamy do lektury pierwszej części naszego cyklu – rozważań o copyleft/non-copyleft. Dziś chcemy się zająć najpopularniejszą z licencji copyleftowych, czyli GPL v.2 i v3. Razem mają – w zależności od badań – ok 20-25% rynku wszystkich licencji open source (Open Source Licenses in 2021: Trends and Predictions – WhiteSource), w tym szereg kluczowych produktów jak WordPress, MySQL czy Linux. Z jednej strony GPL ma więc istotne znaczenie rynkowe/gospodarcze, z drugiej stwarza nam najwięcej wyzwań. Ze względu na obszerność materiału, będą dwa rozdziały tej części – w kolejnym opowiemy o innych niż GPL licencjach copyleft. 

Dwie zagadki  

Zaczniemy od przykładu: pracujesz w spółce A, która dostała zlecenie na napisanie oprogramowania dla spółki B. Piszesz oprogramowanie, korzystając z kodu opartego o licencję GPL – modyfikujesz go, dopisujesz własne rozwiązania, ale bezspornie jest to opracowanie oprogramowania pierwotnego, opartego na GPL. Spółka B jest zadowolona, płaci Twojemu pracodawcy wynagrodzenie, otrzymuje kody. I tutaj pojawia się pytanie: czy spółka B z momentem otrzymania oprogramowania zobowiązana jest do publikacji całego kodu źródłowego? Czy programistka ze spółki C może żądać od spółki B udostępnienia tego kodu.

Nie i nie.

To jedna z pułapek ideologicznego myślenia o open source. Twórcy tych licencji dbają o to, aby twórca opracowania (czyli nasz programista ze spółki A, czy raczej sama spółka) nie “zamknęły” kodu takich opracowań. Ale nie oznacza to, że zmuszają, aby kod zawsze pokazać publicznie, nie oznacza, że świat “zewnętrzny” ma zawsze roszczenia. Open source działa w relacji licencjodawca – licencjobiorca. Jeżeli udzielana jest licencja, licencjobiorca (i tylko on) może żądać dostarczenia kodu źródłowego.

Jeżeli żadna ze stron takiej umowy nie jest zainteresowana udostępnieniem kodu źródłowego innym osobom, nie mają takiego obowiązku. Dopiero gdy spółka B rozpowszechni oprogramowanie, które nabyła, będzie musiała udostępnić kod źródłowy każdemu z użytkowników tego oprogramowania. 

Mechanizm ten ma szczególna wagę w grupach kapitałowych. Jeżeli jedna ze spółek ma charakter tzw. CUW / Centrum IT i opracowuje rozwiązania dla całej grupy (choćby i tysiąc spółek) to każda z tych spółek ma prawo do otrzymania kodu, ale nie mają obowiązku jego pokazywania na zewnątrz. 

Mimo objęcia kodu licencją GPL można więc cały czas kontrolować know-how i tajemnice przedsiębiorstwa, jeżeli są zawarte w kodzie.

Druga zagadka

Ten sam programista (spółka A) mówi “hola, hola, ale tam jest pełno mojego kodu – udostępnię na licencji GPL tylko to, co jest pierwotnie na GPL, a to co opracowałem, na własnościowej, komercyjnej licencji”. Czy taki “hybrydowy” mechanizm ma szansę zadziałać? 

Ma, ale rzadko. 

Wszystko zależy, co i jak połączył programista. Nie każde użycie kodu open source, nawet na GPL, zaraża. To wyzwanie zarówno od strony prawnej, jak i architektury systemu, ale bywa i tak, że możemy zaprojektować rozwiązanie w ten sposób, by ryzyka zarażenia uniknąć (IP by design). Jednak GPL ma tę cechę, że w zarażaniu jest bardzo skuteczny. Żeby wytłumaczyć, jak ten mechanizm zarażania działa, potrzeba trochę teorii.  

Interfejs między prawem autorskim a klauzulą copyleft 

Ochrona praw autorskich do utworów nie ogranicza się do ich dosłownej treści. Nie miałaby ona sensu, gdyby po dokonaniu prostych modyfikacji można było korzystać z utworu bez zgody autora. Dlatego też prawo autorskie pozwala autorowi kontrolować również wykorzystanie utworów zależnych (adaptacji, tłumaczeń, aranżacji i innych zmian, określanych łącznie mianem opracowań). Na poziomie międzynarodowym zostało to uregulowane w art. 8 i 12 Konwencji Berneńskiej, a w UE w odniesieniu do programów komputerowych w art. 4 (1) (b) dyrektywy 2009/24/WE. Na poziomie krajowym jest ono traktowane albo jako odrębne prawo (najczęściej określane jako „prawo do adaptacji”) [1], albo jako część szerszego prawa do zwielokrotniania [2]. W każdym przypadku, gdy mamy do czynienia z utworem zależnym (opracowaniem), korzystanie z niego wymaga zgody nie tylko autora utworu zależnego (opracowania), ale także autora utworu pierwotnego (oryginału). 

[1] Tak jest na przykład w Hiszpanii, Grecji, Estonii i Polsce.
[2] Dzieje się tak na przykład we Francji, Holandii, Belgii, Finlandii i Danii. Zob. M.M.M. van Eechoud i in., Harmonizing European copyright law: the challenges of better lawmaking, Kluwer Law International 2009, s. 83; S. Ricketson, J. Ginsburg, International Copyright and Neighbouring Rights. The Berne Convention and Beyond. Vol. 1, Oxford 2005, s. 645.

Prawo autorskie nie definiuje, czym jest opracowanie. Najogólniej rzecz ujmując, jego istotą jest „twórcza ingerencja” w dzieło twórcy pierwotnego. Każde opracowanie, w tym opracowanie programu komputerowego, jest więc wynikiem twórczości intelektualnej, w której występują obok siebie (a) elementy twórcze zaczerpnięte z utworu oryginalnego, oraz (b) elementy twórcze dodane przez twórcę utworu zależnego. W świecie nie-softwaru to np. tłumaczenie Harrego Pottera czy adaptacja filmowa książek Joanne Rowling. Niby coś innego, literka w literkę nie ma sensu porównywać, ale gdyby nie oryginał, opracowania by też nie było.  

Możliwość kontrolowania korzystania z utworów w postaci opracowania zapewnia klauzula copyleft. Z prawnego punktu widzenia, klauzula copyleft to zezwolenie na korzystanie z opracowania programu pierwotnego (oryginału), udzielone przez pierwotnego autora (autorów) pod warunkiem, że opracowanie zostanie również udostępnione na tych samych warunkach.

Klasyczny przykład takiej klauzuli znajdziemy w GNU GPL 2.0, która stanowi w paragrafie 2 (b), że „Musisz spowodować, że jakakolwiek praca, którą rozpowszechniasz lub publikujesz, która w całości lub w części zawiera lub jest pochodną Programu lub jego części, będzie licencjonowana jako całość bez opłat dla wszystkich stron trzecich zgodnie z warunkami niniejszej Licencji„. 

Na pierwszy rzut oka proste. Ale trudność tkwi w udzieleniu odpowiedzi na pytanie, kiedy w przypadku software dochodzi do powstania opracowania. Spróbujmy przejść przez kilka scenariuszy. 

Scenariusz 1: kilka prostych zmian 

Nie każda zmiana w cudzym programie to od razu dzieło zależne. Kilka prostych zmian (np. paru pojedynczych instrukcji, jakiejś nazwy zmiennej, niektórych wartości) nie musi być na tyle twórcze, żeby prowadzić do powstania opracowania. Ich wprowadzenie wymaga wprawdzie zgody autora programu (kontrola nad prawem do modyfikacji – art, 74 p.a.), ale samo w sobie nie czyni z osoby modyfikującej program twórcy zależnego. W takim przypadku, mimo że coś się zmieniło, to nadal ten sam program (nie ma przecież utworu zależnego), a ten, kto zmian dokonał nie może rościć sobie żadnych praw do niego, ani tym bardziej zmienić zasad licencjonowania.  

Oczywiście konia z rzędem temu, kto jest w stanie z całym przekonaniem powiedzieć, że coś nie jest utworem. Przesłanki ochrony prawnoautorskiej są interpretowane przez sądy bardzo liberalnie i nawet dość proste zmiany, zwłaszcza jak zbierze się ich większa ilość, łatwo zostaną zakwalifikowane jako opracowanie. I nie jest to wyłącznie polska specyfika. Nie szukając daleko – w opisywanej przez nas niedawno sprawie Oracle v Google sąd pierwszej instancji, mimo ogólnie bardzo przychylnego dla Google wyroku, uznał za twórcze (i dopatrzył się naruszenia) 9 linijek kodu przejętych przez Google przy tworzeniu Androida. Możemy te 9 sławnych linijek nawet zacytować w całości: 

1. private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {  

2.   if (fromIndex > toIndex)  

3.      throw new IllegalArgumentException(„fromIndex(” + fromIndex +  

4.        „) > toIndex(” + toIndex+”)”);  

5.   if (fromIndex < 0)  

6.      throw new ArrayIndexOutOfBoundsException(fromIndex);  

7.   if (toIndex > arrayLen)  

8.      throw new ArrayIndexOutOfBoundsException(toIndex);  

9. }  

Jak widać, nie trzeba wznosić się na wyżyny kunsztu programistycznego ani włożyć niezwykle dużo pracy, żeby powstało coś, co może podlegać ochronie prawnoautorskiej.  

Scenariusz 2: grzebiemy głębiej 

Drugi przypadek to głębsze zmiany w programie na GPL lub wykorzystanie jego kodu jako podstawy przy tworzeniu własnego programu. Czyli bierzemy czyjś kod, grzebiemy, przerabiamy, dopisujemy nowe funkcjonalności, poprawiamy błędy, a później przekazujemy dalej albo korzystamy dla własnych potrzeb. 

To sytuacja bliska “tradycyjnej” twórczości. Jeżeli nasz wkład jest oryginalny (a przy głębszych zmianach jest to bardzo prawdopodobne) powstanie opracowanie (utwór zależny). Co z tego wynika? Opracowanie jest nowym utworem. Jego związek z tym, co było materiałem wyjściowym wyraża się w konieczności uzyskania zezwolenia na – jak to określa polska ustawa o prawie autorskim – „korzystanie i rozporządzanie opracowaniem”. W odniesieniu do programów komputerowych przez „korzystanie” rozumieć należy czynności wymienione w art. 74 ust. 4 pr.aut. (czyli zwielokrotnianie, wprowadzanie dalszych zmian i rozpowszechnianie). „Rozporządzaniem” jest z kolei dysponowanie autorskim prawem zależnym w zakresie poszczególnych form korzystania z dzieła, obejmujące zarówno przeniesienie autorskich praw majątkowych, jak i dokonywanie innych czynności prawnych zmierzających do umożliwienia innym podmiotom korzystania z dzieła (przede wszystkim udzielenie licencji). 

Zezwolenia twórcy programu pierwotnego (pierwotnego programisty, który wypuścił kod na GPL) wymaga więc podjęcie eksploatacji opracowania przez jego twórcę (kolejnego programisty, który wprowadził zmiany) lub osobę trzecią oraz zawarcie umowy przenoszącej autorskie prawa majątkowe do opracowania lub upoważniającej do korzystania z opracowania (licencji).

Brak zezwolenia będzie skutkował w pierwszym przypadku naruszeniem autorskich praw majątkowych do utworu pierwotnego, w drugim zaś nieważnością zawartej umowy.  

Zezwolenie na korzystanie z autorskich praw zależnych może być udzielone bezpośrednio użytkownikowi (end-userowi) korzystającemu z opracowania (nabywcy praw zależnych lub licencjobiorcy utworu zależnego). Najczęściej jednak zezwolenie takie udzielane jest bezpośrednio twórcy zależnemu (programiście). Po jego uzyskaniu, twórca zależny może, w granicach uzyskanego zezwolenia, samodzielnie zawierać umowy przenoszące autorskie prawa majątkowe i umowy licencyjne, mające za przedmiot dokonane opracowanie. Innymi słowy – jak opracujemy utwór zależny (w naszym przypadku na bazie kodu objętego licencją GPL) musimy uzyskać zgodę na dysponowanie tym „naszym – nie do końca naszym” utworem.

I tu wchodzi klauzula copyletft, która zezwala zarówno twórcy opracowania, jak i jego kontrahentowi (end userowi) na korzystanie i rozporządzanie opracowaniem tylko na warunkach danej licencji.

O ile z korzystaniem problemu nie ma, bo zakres zezwolenia jest bardzo szeroki (trudno jest wskazać czynności objęte zakresem autorskich praw majątkowych, na które np. GPL nie zezwala), to z rozporządzaniem jest. Bo zawarcie przez twórcę opracowania umowy z jakimkolwiek podmiotem trzecim jest możliwe tylko w granicach, na jakie zezwala dana klauzula copyleft (np. w GPL tylko na zasadach GPL). Czyli nie można przenieść praw do opracowania na kontrahenta, nie można udzielić bardziej liberalnej licencji (np. jakiejś licencji „permisywnej” jak MIT), nie można udzielić takiej bardziej restrykcyjnej. Jak to zrobimy, zawarta umowa będzie nieważna.  

Oczywiście to działa (tylko i aż) w relacjach kontraktowych. A przymusu kontraktowania nie mamy. Czyli jak nie będziemy chcieli nikomu dać naszego oprogramowania i zawierać z kimkolwiek umowy, możemy zachować kod dla siebie. Jak już jednak damy, to nie mamy prawnego sposobu powstrzymania naszego kontrahenta od przekazania go dalej (oczywiście tylko z punktu widzenia prawa autorskiego, wspomniane grupy kapitałowe radzą sobie z tym dość sprawnie w inny sposób).  

Scenariusz 3: integracja 

Dwa przedstawione wyżej scenariusze są dość oczywiste i łatwe do ogarnięcia od strony prawnej. Oczywiste jest, że jeżeli bierzemy kod na GPL-u, to to, co na jego podstawie napiszemy, też powinno być na GPL-u. Ale wyobraźmy sobie, że bierzemy binarkę jakiejś biblioteki programistycznej (niech będzie to nadal licencja GPL). Nie zmieniamy w niej ani linijki, ale piszemy program, który w swoim przebiegu wywołuje funkcje zawarte w tej bibliotece. Połączenie jest dynamiczne, a biblioteka i program wykorzystujący bibliotekę to dwa oddzielne pliki. Czy w takim przypadku GPL zarazi nasz kod? Otóż niewykluczone.  

Niewiele programów komputerowych działa w całkowitej izolacji od swojego środowiska – większość z nich musi być połączona z innymi programami, aby można było z nich sensownie korzystać. To, jakie rodzaje połączeń prowadzą do „aktywacji” klauzuli copyleft, a więc kiedy połączone oprogramowanie zostaje „zainfekowane” zasadami licencji GNU GPL, jest jedną z trudniejszych kwestii przy wykorzystywaniu copyleftowego oprogramowania w projektach komercyjnych i jest różnie oceniana zarówno wśród prawników, jak i programistów.  

Zgodnie z interpretacją konsekwentnie przyjmowaną przez Free Software Foundation, utwór zależny (opracowanie) powstaje, gdy procedury w zewnętrznych plikach są ściśle włączone w wykonywanie (przepływ) programu.

FSF kładzie nacisk na granicę procesu, gdy rozważa zakres copyleft, oraz na mechanizm i semantykę komunikacji między wieloma komponentami oprogramowania, aby określić, czy są one wystarczająco ściśle zintegrowane, by uznać je za pojedynczy program dla celów GPL. Przykładem łączenia komponentów w jeden program może być użycie dynamicznie łączonych bibliotek oprogramowania. W ten sam sposób FSF ocenia również użycie wtyczek, których sposób połączenia z danym programem zakłada wzajemne wywoływanie funkcji lub współdzielenie złożonych struktur danych, a także modułów Perla lub klas Javy połączonych w podobny sposób [3]. 

W literaturze prawniczej pojawia się czasem argument, że dynamiczne linkowanie nie powinno być klasyfikowane jako utwór zależny [4]. Podejście Free Software Foundation ma jednak pewne wsparcie w orzecznictwie sądów amerykańskich, choć odnotowane spory nie dotyczyły bezpośrednio naruszenia GPL. W sprawie Bradstreet Software Servs., Inc. przeciwko Grace Consulting, Inc. spór dotyczył tego, czy program pozwanego, który wprawdzie nie zapożyczał bezpośrednio z programu powoda, ale wymagał uruchomienia programu powoda i odwoływał się do funkcji zawartych w bibliotekach programistycznych, które były częścią programu powoda, może być uznany za utwór zależny. Sąd Apelacyjny Stanów Zjednoczonych dla Trzeciego Okręgu, uchylając wyrok sądu procesowego, odpowiedział na to pytanie twierdząco [5]. Wyrok ten został odczytany jako wskazówka, że powstanie utworu zależnego może nastąpić już w wyniku stworzenia programu wywołującego funkcje zawarte w zewnętrznej bibliotece programistycznej łączonej dynamicznie [6]. Podobne rozstrzygnięcia sądów europejskich nie zostały odnotowane. Jednak ze względu na zbliżony stan prawny w tym zakresie można założyć, że rozstrzyganie takich spraw w UE byłoby analogiczne. Należy zatem przyjąć, że przynajmniej w niektórych przypadkach takie dynamiczne połączenie może skutkować powstaniem utworu zależnego. Jak z tego wybrnęła społeczność open-sourcowa – w kolejnym rozdziale, o „słabych” licencjach copyleft.

[3] Free Software Foundation, Frequently Asked Questions about the GNU GPL v2.0, https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html [10 marzec 2021 r.].
[4] L. Determann, Softwarekombinationen unter der GPL, „GRURInt” 2006, nr 8–9, s. 647.
[5] Dun & Bradstreet Software Servs., Inc. v. Grace Consulting, Inc. , 307 F.3d 197 (3d Cir. 2002).
[6] J. Band, M. Katoh, Interfaces on Trial 2.0, MIT Press 2011, s. 47.

Brak efektu wirusa 

Inne kombinacje programów niż opisane powyżej nie prowadzą do stworzenia dzieła zależnego, więc klauzula copyleft nie będzie miała zastosowania. Przykłady podane przez FSF [7] obejmują: 

  • tzw. „mere aggregation” (GPL 2.0) lub „aggregate” (GPL 3.0) programów, tj. umieszczanie ich na jednym nośniku lub na jednym urządzeniu, nawet jeśli są one rozpowszechniane razem lub funkcjonalnie powiązane; 
  • wymiany danych i komunikacji pomiędzy dwoma oddzielnymi programami, działającymi jako oddzielne procesy. Na przykład, w systemach Unix, mechanizmy komunikacji zwykle używane pomiędzy dwoma oddzielnymi programami to rury, gniazda i argumenty wiersza poleceń; 
  • zwykłego użycia programu objętego copyleft do przetwarzania pewnych danych (np. edytor programistyczny, w którym edytuje się kod źródłowy innego programu). To samo dotyczy interpretera języka programowania objętego copyleft, dla którego interpretowany program jest tylko przetwarzanymi danymi. 

W powyższych przypadkach, nawet jeśli kilka różnych programów współpracuje ze sobą w celu osiągnięcia określonego rezultatu, nie prowadzi to do połączenia ich w jeden program, a tym samym uznania go za utwór zależny. Przykładem mogą być dystrybucje Linuksa, w których komponenty systemu objęte licencją copyleft są połączone z komponentami objętymi innymi licencjami (w tym licencjami prawnie zastrzeżonymi). 

[7] Free Software Foundation, Frequently Asked Questions about the GNU GPL v2.0, op. cit.

c.d.n.

Na tym kończymy ten rozdział. W kolejnym – GPL a konteneryzacja, “słabe” licencje copyleft jak LGPL, „supersilna” klauzula copyleft w Affero GPL oraz podsumowanie i wprowadzenie do części trzeciej. 


Zobacz inne artykuły