Wszystkie teksty umieszczane na Linkedin lub naszych stronach internetowych są naszą opinią. Prosimy nie traktować ich jako porady prawnej w konkretnej sprawie, ponieważ konkretna sprawa zawsze wymaga indywidualnej analizy.
Nasze myśli o Open Source. Z jednej strony wielkie idee, z drugiej skuteczny kod. Kod, którego użycie może przysporzyć bólu głowy, i programistom, i prawnikom. Na dodatek wiele mitów. Miłej lektury!
Lubimy open source z każdego punktu widzenia – idei, możliwości zabawy z kodem, wpływu na biznes czy wręcz na postawy społeczne. Imponuje nam autorsko-prawna konstrukcja i wiele wyzwań, teoretycznych i praktycznych, jakie open source stawia przed prawnikami. To powód pierwszy. Powód drugi jest czysto praktyczny – w ostatnich dwóch latach mieliśmy więcej projektów dotyczących zasad wykorzystania open source niż przez poprzednie dwadzieścia. W naszym odczuciu open source przebił się z „warstwy informatycznej” do „warstwy regulacyjnej” – nabywcy zwracają uwagę, czy dostawcy wypełnili wszystkie zobowiązania open sourcowe, badanie kodu pod kątem prawnych konsekwencji zastosowania oprogramowania OS zaczyna być standardem, podobnie jak badanie OS przy transakcjach M&A. Bywa, że prowadzi to do daleko idących konsekwencji, jak stwierdzenie braku praw autorskich do danego rozwiązania czy odmowa uiszczenia opłaty licencyjnej. Jednym słowem – warto się temu zjawisku przyjrzeć.
Planujemy trzy części (ale jesteśmy zwinni, więc może się zmienić). Dzisiaj wprowadzenie i trochę konstrukcji prawnych. Za jakiś czas (sprint drugi) analiza „wirusa GPL” i podobnych rozwiązań. W sprincie trzecim mapa „pola minowego” open source’u – gdzie można zrobić sobie lub klientowi krzywdę.
Źródeł ruchu Open Source można upatrywać w odczuwanej przez wielu programistów potrzebie badania, poprawiania i dostosowywania istniejących programów do ich własnych potrzeb. W przypadku oprogramowania „własnościowego” („closed source”) jest to zazwyczaj niemożliwe. Barierą technologiczną jest brak dostępu do kodu źródłowego, niezbędnego dla wprowadzania zmian i rozwoju oprogramowania. Barierą prawną jest natomiast bardzo szeroki zakres ochrony programów komputerowych, który sprawia że jakakolwiek forma korzystania z programu, w tym jego modyfikowanie, wymagają uzyskania zgody uprawnionego. Ruch Open Source, wyrósł ze sprzeciwu wobec takiego stanu rzeczy, stawia sobie za cel tworzenie i popularyzowanie programów „otwartych”, „wolnych”, a więc dostępnych wraz z kodem źródłowym i udostępnianych na bardzo liberalnych zasadach.
Początki Open Source sięgają lat 70-tych. Wtedy to AT&T dostarczał wszystkim zainteresowanym (przede wszystkim instytucjom edukacyjnym) system operacyjny UNIX za symboliczną opłatą i to wraz z kodem źródłowym. Szybko doprowadziło to do jego popularyzacji w środowiskach akademickich, który rozwijał się dalej nie tylko dzięki AT&T, ale i programistom z zewnątrz, zwłaszcza tym związanym z ośrodkami akademickimi. Szczególnie duży był wkład Uniwersytetu Kalifornijskiego w Berkeley. Poprawki i rozszerzenia, tworzone ze środków publicznych przez pracowników uniwersytetu, objęte były licencją o nazwie Berkeley Software Distribution. Licencja ta stała się wzorem dla udostępniania oprogramowania w środowiskach akademickich, w późniejszym okresie pojawiło się zresztą wiele bardzo zbliżonych licencji (np. MIT)[1].
Na przełomie lat 70-tych i 80-tych doszło do komercjalizacji systemu UNIX, zakończonej w 1983 r., w wyniku której sam system stał się odpłatny, a kod źródłowy na tyle drogi, że praktycznie niedostępny. Niemal równocześnie, w 1982 r., Richard M. Stallman rozpoczyna pracę nad bezpłatnym, dostępnym wraz z kodem źródłowym, systemem operacyjnym kompatybilnym z UNIX-em o nazwie GNU[2]. W celu koordynowania prac nad systemem zakłada w 1985 r. Free Software Foundation (FSF), której jednym z zadań jest też popularyzowanie „wolnego” oprogramowania[3]. Prace nad systemem GNU (który w międzyczasie zmienił nazwę na GNU-Hurd) nie zostały do dziś zakończone, jednak w ramach tego projektu stworzono wiele programów pomocniczych, stanowiących istotną część innych „wolnych” systemów operacyjnych kompatybilnych z UNIX-em. Przykład pierwotnej wersji systemu UNIX – kiedy to bezpłatnie dostępne oprogramowanie uległo komercjalizacji – spowodował, że opracowano specjalną licencję mającą nie tylko przyznawać użytkownikowi prawo bezpłatnego wykorzystania programu i wprowadzania do niego zmian, ale i chronić zachowanie takiego statusu w przyszłości. Licencją tą była GNU General Public License (Generalna Licencja Publiczna).
Lata 90. to okres ekspansji „swobodnego” oprogramowania. Rozwój Internetu, opracowanie narzędzi umożliwiających zdalną współpracę rozproszonej grupy programistów oraz wypracowanie zwyczajów dotyczących zarządzania procesem tworzenia oprogramowania i podejmowania strategicznych decyzji dotyczących jego dalszego rozwoju, zapewniło techniczne i organizacyjne ramy dla realizacji projektów o dużym stopniu złożoności[4]. W okresie tym powstają sztandarowe produkty Open Source takie jak system operacyjny Linux, serwer http Apache, czy system zarządzania relacyjnymi bazami danych MySQL. W 1998 r. powołana zostaje kolejna organizacja, stawiająca sobie za cel popularyzację otwartego oprogramowania – Open Source Initiative (OSI). Do jej zadań należy m. in. standaryzacja i ocena rosnącej liczby „otwartych” licencji. Open Source zainteresowali się również dostawy „własnościowych” rozwiązań informatycznych, tacy jak IBM, Apple, Novell, Sun czy Oracle, dla których „otwarte” oprogramowanie stanowi dogodną podstawę popularyzacji i rozwoju własnych produktów (o JAVIE pisaliśmy, to niezwykle ciekawy przykład równoległego open source i oprogramowania zamkniętego).
[1] M. O’Sullivan: The Pluralistic, Evolutionary, Quasi Legal Role of The GNU General Public Licence In Free/Libre/Open Source Software (FLOSS), EIPR 2004, nr 8, s. 340. [2] GNU to rekursywny akronim, oznaczający ,,GNU’s Not Unix”. [3] E.S. Raymond: A Brief History of Hackerdom. [4] E.S. Raymond: Cathedral and the Bazaar.
Ale Open Source to przede wszystkim (w wielu przypadkach) doskonały software. Niezależnie od ideologicznych pobudek, wiele „otwartych” programów, tworzonych przez grupy ochotników współpracujących ze sobą przez Internet, zdobyło pokaźne udziały w rynku. Proces powstawania oprogramowania Open Source, nazywany „rozproszonym postępem technicznym”, jest niewątpliwie jednym z socjologicznych i technicznych fenomenów sieci. Ale Open Source to również fenomen prawny, bowiem zapewnieniu „otwartości” oprogramowania służyć mają odpowiednio skonstruowane licencje.
Licencje oprogramowania Open Source to zbiorcza kategoria licencji, które charakteryzują się przede wszystkim (a) udostępnianiem oprogramowania wraz z jego kodem źródłowym oraz (b) szerokim zezwoleniem na korzystanie z tego oprogramowania, w tym dokonywanie modyfikacji i dalsze rozpowszechnianie. Przed omówieniem zasad, dwa słowa o ruchu open source i jego odłamach.
Jeden z podstawowych nurtów to fundacja Free Software Foundation – jej celem, jak i celem stojącego na jej czele guru R. Stallmana, jest tworzenie i rozpowszechnianie „wolnego” oprogramowania („free software”),[5] a także prawne zabezpieczenie jego dalszej „wolności”, przy czym angielskie słowo „free” oznacza tu właśnie „wolność” a nie „darmowość”[6]. Zgodnie z Free Software Definition licencje na „wolne” („wolnodostępne”) oprogramowanie powinny zapewniać każdemu wolność: a) wykorzystania oprogramowania w dowolnym celu (również „komercyjnym”), b) badania oprogramowania i dostosowywania go do własnych potrzeb c) rozpowszechniania oprogramowania w dowolny sposób, w tym również d) rozpowszechniania w zmodyfikowanej (dostosowanej, udoskonalonej) postaci[7]. Jednocześnie w ramach FSF silnie akcentuje się ideologiczny sprzeciw środowiska programistów przeciw nadmiernie restrykcyjnym regulacjom prawa autorskiego i dotychczasowym „własnościowym” regułom udostępniania oprogramowania, którym towarzyszy zamiar izolowania poszczególnych użytkowników, ich podporządkowania i uzależnienia od dostawcy[8]. Jak podkreśla preambuła najbardziej znanej licencji, stworzonej przez FSF: „większość licencji na oprogramowanie pomyślana jest po to, aby odebrać użytkownikowi możliwość swobodnego udostępniania innym i zmieniania danego oprogramowania. Natomiast w wypadku GNU General Public License (GNU GPL), celem jest zagwarantowanie użytkownikowi swobody udostępniania i zmieniania tego wolnego oprogramowania, a więc danie pewności, iż oprogramowanie jest wolnodostępne dla wszystkich użytkowników”. Celem GNU GPL jest więc przełamanie przywilejów wynikających z praw własności intelektualnej, jakie przyznawane są twórcy w zamian za jego pracę, i zapewnienie swobody przepływu informacji dla dobra publicznego.
W najbardziej radykalnych wypowiedziach R. M.. Stallmana i Free Software Foundation spotkać można opinię, że korzyści materialne nie powinny być jedynym czy głównym czynnikiem motywującym programistę do pracy twórczej. Wystarczającą motywacją powinna być sama radość tworzenia, możliwość samorealizacji czy zdobycia uznania[9]. Ponieważ chodzi tu w pewnym sensie o odwrotność „copyright”, używa się tu terminu „copyleft”, a „wolne” oprogramowanie udostępniane na licencjach GNU GPL i zbliżonych, tj. gwarantujących jego „wolność” również w przyszłych wersjach, nazywa się „copylefted software”[10].
Idealizm Free Software Foundation, ironicznie określany mianem „informatycznego komunizmu”, nie jest podzielany przez wszystkich aktywistów Open Source. Przeciwnicy podejścia FSF podkreślają, że ruch Open Source ma znaczenie przede wszystkim jako alternatywa i uzupełnienie komercyjnych produktów informatycznych. Może on sprzyjać wzrostowi konkurencji na rynku, przełamaniu dominacji dużych producentów i promowaniu niezależnych standardów technicznych, w oparciu o które zarówno indywidualni programiści jak i mali i średni producenci oprogramowania mogą oferować własne produkty i usługi. Innymi słowy celem ruchu powinna być nie tyle „wolność”, co „otwartość” oprogramowania[11]. Tak też cele Open Source postrzegane są przez Open Source Initiative (OSI) i drugą z czołowych postaci ruchu – E. S. Raymonda.
Zgodnie z opracowaną przez OSI Open Source Definition program należy do kategorii Open Source, jeżeli licencja zapewnia: a) swobodną redystrybucję programu (zwielokrotnianie w celu udostępnienia osobom trzecim i rozpowszechnianie oprogramowania); b) dostęp do kodu źródłowego; c) swobodę wprowadzania modyfikacji i dokonywania opracowań; d) swobodę rozpowszechniania modyfikacji i opracowań programu; e) brak dyskryminacji jakichkolwiek osób lub grup osób; f) brak ograniczeń co do sposobu wykorzystania oprogramowania; g) objęcie licencją Open Source całości rozpowszechnianego programu, a nie tylko wydzielonej części; h) zakaz uzależniania udzielenia zezwolenia na korzystanie z programu od uzyskania licencji dotyczącej innego produktu; i) zakaz wpływania na sposób udostępniania i korzystania z innego oprogramowania (np. poprzez postanowienia umowne, że wszystkie programy rozpowszechniane na jednym nośniku muszą należeć do kategorii Open Source)[12].
Bardziej pragmatyczne podejście Open Source Initiative jest źródłem rozbieżności pomiędzy FSF a OSI. Z praktycznego punktu widzenia różnice pomiędzy Free Software Definition a Open Source Definition są jednak nie aż tak wielkie. Istnieją licencje spełniające przesłanki Open Source Definition, które z punktu widzenia FSF są zbyt restrykcyjne, jak również takie, które wprawdzie spełniają przesłanki Free Software Definition, jednak nie mogą być uznane za Open Source[13]. Przypadki takie są wprawdzie stosunkowo rzadkie, jednak ideologiczne spory pomiędzy poszczególnymi odłamami ruchu powodują, że w ostatnich latach popularność zdobywa „politycznie poprawny” termin Free, Libre, Open Source Software (FLOSS), obejmujący wszystkie odmiany „niewłasnościowego” oprogramowania [14]. My stosujemy dalej pojęcie „Open Source”, mając na myśli jak najszerszą kategorię (czyli FLOSS).
[5] Ze względu na dwuznaczność przymiotnika „wolny” w języku polskim, termin „free software” często tłumaczony jest jako „oprogramowanie wolnodostępne”. [6] „When we speak of «free software», we’re talking about freedom, not price” – R. Stallman: Selling Free Software, publikacja dostępna pod adresem: http://www.fsf.org/philosophy/selling.html. [7] Zob. The Free Software Definition, dokument dostępny pod adresem: http://www.gnu.org/philosophy/free-sw.html [8] J. Barta, R. Markiewicz, Oprogramowanie Open Source w świetle prawa, Kraków 2005, s. 20. [9] R. Stallman: GNU Manifesto, publikacja dostępna pod adresem: http://www.gnu.org/gnu/manifesto.htmlcit_af ref_bf(Stallman, ref_num1851)ref_af, cit_bfR. Stallman: Reevaluating Copyright: The Public Must Prevail, Oregon Law Rev. 1996, Spring. [10] R. Stallman: What Is Copyleft?, publikacja dostępna pod adresem: http://www.fsf.org/copylft/copyleft.html. Zob. też A. Metzger, T. Jaeger, Open Source Software und deutsches Urheberrecht, „GRUR” 1999/10, J. Barta, R. Markiewicz: Oprogramowanie…, s. 47. [11] F. Koch: Urheber- und kartellrechtliche Aspekte der Nutzung von Open Source Software (I), CR 2000, nr 5, s. 280, R. Mann, Commercializing Open Source Software: Do Property Rights Still Matter? HARV. J. L. & TECH 2006/1, s. 21. [12] Open Source Definition, dokument dostępny pod adresem http://www.opensource.org/docs/osd. [13] R. Stallman: Categories of Free and Non-Free Software, publikacja dostępna pod adresem: http://www.fsf.org/philosophy/categories.html. [14] Zob. M. O’Sullivan, M.O. Sullivan, The Pluralistic, Evolutionary, Quasi Legal Role of The GNU General Public Licence In Free/Libre/Open Source Software (FLOSS), „EIPR” 2004/8, s. 340.
Celem licencji Open Source jest więc przełamanie przywilejów twórcy wynikających z praw własności intelektualnej oraz zapewnienie swobodnego przepływu informacji z korzyścią dla społeczeństwa. Innymi słowy, podstawowym celem licencjonowania Open Source jest odmówienie komukolwiek prawa do wyłącznego korzystania z utworu[15].
Oprogramowanie komputerowe jest przede wszystkim chronione prawem autorskim (niestety). Dodatkowo, w wielu jurysdykcjach, pewne innowacyjne elementy funkcjonalne oprogramowania mogą być chronione patentami jako tak zwane wynalazki realizowane za pomocą komputera. Przedmiotem patentu może być zarówno produkt (np. standardowy komputer z zainstalowanym innowacyjnym oprogramowaniem wykonującym pewne funkcje), jak i proces (np. pewien przebieg czynności wykonywanej za pomocą programu komputerowego). Ponadto, oprogramowanie może zawierać inne elementy chronione jako własność intelektualna. W szczególności, nazwa oprogramowania lub nazwa organizacji, która zarządza rozwojem oprogramowania może być zarejestrowana jako znak towarowy.
Wszystkie licencje Open Source uwzględniają wykorzystanie oprogramowania objętego licencją jako przedmiotu prawa autorskiego. Ponadto, niektóre licencje Open Source zawierają postanowienia zapewniające, że jeśli jakiekolwiek elementy oprogramowania byłyby chronione patentami, zezwolenie zawarte w licencji obejmuje również zezwolenie na korzystanie z wynalazku chronionego tym patentem. Jest to szczególnie prawdziwe w przypadku licencji takich jak Academic Free License 3.0, GPL 3.0, AGPL 3.0, Apache 2.0, Eclipse Public License 2.0, Mozilla Public License 2.0. Inaczej wygląda sytuacja w przypadku znaków towarowych. Wiele licencji zawiera wyraźne ograniczenia dotyczące korzystania z niektórych znaków towarowych. Na przykład, licencja Apache 2.0 nie zawiera prawa do używania znaku towarowego licencjodawcy, z wyjątkiem uzasadnionego i zwyczajowego użycia w opisie pochodzenia oprogramowania. Podobne postanowienia można znaleźć m.in. w licencjach BSD-3-clause, PHP-3.0 i GNU GPL 3.0. Ze względu na „otwartość” oprogramowania Open Source, jego elementy nie mogą być także chronione jako nieujawnione know-how lub tajemnica handlowa.
Objęcie oprogramowania licencją Open Source nie powinno być rozumiane jako zrzeczenie się praw własności intelektualnej lub przekazanie go do domeny publicznej
(bardzo ważne, ponieważ często, a błędnie, właśnie tak podchodzi się do OS). Oprogramowanie open source nadal jest chronione prawem autorskim, a korzystanie z niego wymaga przestrzegania warunków licencji. Nawet najprostsze licencje, takie jak MIT czy BSD-2-clause, nakładają na użytkownika pewne zobowiązania, takie jak obowiązek dostarczenia informacji o używanym oprogramowaniu. Inne często spotykane postanowienia to obowiązek informowania o dokonanych zmianach, udostępniania kodu źródłowego oprogramowania open source w związku z jego rozpowszechnianiem oraz udostępniania kodu źródłowego wszelkich modyfikacji dokonanych w rozpowszechnianej kopii oprogramowania. Licencje GPL to już zestaw bardzo daleko idących wymagań.
[15] A.M.St. Laurent, Understanding Open Source&Free Software Licensing, O’Reilly 2004, s. 5.
Charakter prawny licencji OS nie jest w pełni jasny. W większości jurysdykcji licencje te są interpretowane jako umowy (np. w Belgii, Chorwacji, Czechach, Francji, Hiszpanii, Holandii, Niemczech, Portugalii, Rumunii, Turcji, na Węgrzech). W niektórych krajach (np. w Grecji) rozważa się również ich kwalifikację jako jednostronnej zgody uprawnionego. Z drugiej strony, w kilku krajach, m.in. ze względu na brak orzecznictwa, sytuacja pozostaje niejasna[16]. Przykładowo w Polsce, w odniesieniu do licencji GNU GPL, rozważano zakwalifikowanie jej częściowo jako umowy (w zakresie zezwolenia na rozpowszechnianie objętego nią oprogramowania), częściowo jako jednostronnej zgody na korzystanie z utworu (w zakresie eksploatacji programu Open Source przez użytkownika)[17]. Co ważne, w wielu krajach Unii Europejskiej orzeczenia sądów potwierdziły skuteczność licencji Open Source, w tym charakterystycznych dla licencji GNU GPL klauzul „copyleft” (o których poniżej). Na przykład, we Francji, sąd zezwolił nabywcy programu na licencji GPL na wniesienie pozwu przeciwko dystrybutorowi programu na licencji GPL o ujawnienie kodu źródłowego[18]. Podobnie w Niemczech sąd wydał wstępny nakaz przeciwko pozwanemu, który włączył oprogramowanie GPL do swojego oprogramowania własnościowego[19].
Podsumowując – niezależnie od sporów w literaturze prawniczej dotyczących kwalifikacji licencji Open Source, warunki określone w tych licencjach należy traktować jako wiążące. Wykorzystanie oprogramowania Open Source może więc nastąpić wyłącznie na warunkach określonych w tych licencjach.
[16] A. Metzger, S. Hennings, General Report [w:] Free and Open Source Software (FOSS) and other Alternative License Models: A Comparative Analysis, A. Metzger (red.), seria „Ius Comparatum – Global Studies in Comparative Law”, Cham 2016, t.12, s. 14. [17] J. Barta, R. Markiewicz, Oprogramowanie Open Source w świetle prawa, Kraków 2005, s. 80; B. Giesen, Licence Contracts, Free Software and Creative Commons in Poland [w:] Free and Open Source Software (FOSS) and other Alternative License Models: A Comparative Analysis, A. Metzger (red.), seria „Ius Comparatum – Global Studies in Comparative Law”, Cham 2016, t.12, s. 341. [18] Sąd Apelacyjny w Paryżu, 16 września 2009 r., nr 04/24298. [19] LG München I z dnia 19 maja 2004 r., nr 21 O 6123/04.
Creative Commons to zbiór licencji opublikowanych po raz pierwszy w 2002 r. przez Creative Commons, amerykańską organizację non-profit założoną w 2001 r. Istnieje kilka rodzajów licencji Creative Commons. Różne wersje licencji narzucają różne prawa. Wszystkie licencje Creative Commons wymagają przypisania autorstwa do twórcy (opisanego elementem „BY”). Twórca może ponadto zastrzec, że licencjobiorcy mogą:
W związku z tym twórca, korzystając z licencji Creative Commons, zawsze zachowuje prawa autorskie, zezwalając jednocześnie innym na kopiowanie i rozpowszechnianie, a także może określić, czy korzystanie z utworu może odbywać się wyłącznie na warunkach niekomercyjnych, czy też ograniczyć tworzenie utworów zależnych. Licencje CC zawsze przyznają „prawa podstawowe”, takie jak prawo do rozpowszechniania utworu chronionego prawem autorskim na całym świecie w celach niekomercyjnych i bez modyfikacji.
Poza licencjami dotyczącymi praw autorskich, Creative Commons oferuje także CC0, czyli narzędzie pozwalające na umieszczanie materiałów w domenie publicznej. CC0 jest narzędziem prawnym, które pozwala twórcom zrzec się jak największej liczby praw. Narzędzie to powstało w związku z pojawiającymi się w wielu systemach prawnych wątpliwościami dotyczącymi zrzekania się praw autorskich przed upływem czasu ochrony [21].
Licencje Creative Commons oparte są na podobnej koncepcji co Open Source, ale nie są identyczne. Po pierwsze, są bardziej restrykcyjne w niektórych kombinacjach. Licencje zastrzegające użycie niekomercyjne (NC) i udostępnianie utworów zależnych (ND) nie są zgodne z definicjami Wolnego Oprogramowania i Open Source. Po drugie, są one generalnie przeznaczone do dzielenia się utworami innymi niż oprogramowanie i ich użycie w odniesieniu do oprogramowania nie jest zalecane. Ponieważ jednak programy komputerowe są utworami podlegającymi ochronie prawa autorskiego, objęcie ich licencją Creative Commons nie jest niemożliwe. Licencja CC BY-SA 4.0 jest kompatybilna z licencją GPL 3.0.
[20] Od wersji 4.0 licencji Creative Commons, prace pochodne są dozwolone, ale nie mogą być udostępniane. [21] T. Kreutzer, Validity of the Creative Commons Zero 1.0 Universal Public Domain Dedication and its usability for bibliographic metadata from the perspective of German Copyright Law, https://www.rd-alliance.org/sites/default/files/cc0-analysis-kreuzer.pdf [20 styczeń 2021 r.].
Jedną z zalet licencji Open Source (podobnie jak Creative Commons) jest de facto ich standaryzacja. W przypadku oprogramowania własnościowego istnieje duża różnorodność licencji, zarówno pod względem zakresu udzielanych praw, ograniczeń i warunków stosowanych przy korzystaniu z oprogramowania (tzw. metryk licencyjnych), jak i postanowień dodatkowych (np. zobowiązań dotyczących audytów licencyjnych czy odpowiedzialności). Oznacza to, że licencjobiorca przed podpisaniem umowy musi (a przynajmniej powinien) zapoznać się z bardzo obszernym i skomplikowanym dokumentem prawnym, często podlegającym nieznanemu mu prawu właściwemu (to często kilkaset stron tekstu, jeżeli uwzględnimy warunki kontraktowe publikowane w Internecie). Zwiększa to koszty transakcyjne związane z udostępnianiem oprogramowania oraz niepewność prawną. W praktyce to wielkie wyzwanie dla organizacji, połączone z ryzykiem audytu i odszkodowań – ale to temat na inny tekst.
Z kolei w przypadku oprogramowania open source najczęściej stosowane są licencje opracowane przez organizacje popularyzujące ten model dystrybucji oprogramowania (takie jak wspomniana FSF) oraz fundacje zarządzające rozwojem dużych projektów open source (Apache, Mozilla, Eclipse). Dodatkowo, organizacje takie jak FSF czy Open Source Initiative, regularnie dokonują przeglądu i oceny zgodności licencji z opracowanymi przez siebie definicjami Wolnego i Otwartego Oprogramowania[22]. W konsekwencji, licencje Open Source cieszą się dużym zaufaniem deweloperów i użytkowników. W przypadku popularnych licencji (takich jak GNU czy Mozilla Public License) korzystanie z oprogramowania powinno być łatwiejsze do oceny prawnej niż w przypadku licencji „zamkniętych”. Jak się okaże, nie zawsze.
Omawiane korzyści standaryzacji są częściowo ograniczane przez rosnącą liczbę licencji Open Source. The Open Source Initiative wymienia obecnie ponad 100 licencji spełniających definicję Open Source[23]. Liczbę kombinacji zwiększają „wyjątki” dodawane przez niektórych deweloperów do danej licencji (np. wyjątek GCC Runtime Library, wyjątek Qt GPL). Wskazuje się, że zjawisko to, ogólnie znane jako „proliferacja” Open Source, ma następujące negatywne konsekwencje:
Niekompatybilność. Przy większej liczbie licencji prawdopodobieństwo połączenia jednego produktu software’owego z innym, udostępnionym na niekompatybilnych warunkach licencyjnych, wzrasta wykładniczo (opowiemy o tym więcej w części III).
Niepewność. Im więcej licencji Open Source jest wykorzystywanych w praktyce, tym mniej prawdopodobne jest, że będą one poddane kontroli sądowej i ocenie ekspertów prawnych. Analizie podlegają tylko popularne, szeroko stosowane licencje.
Zamieszanie, zwiększone koszty transakcyjne. Im więcej licencji dotyczy danego projektu, tym trudniej jest ocenić, czy projekt spełnia warunki każdej z nich, lub przewidzieć, jaki będzie prawny rezultat połączenia różnych programów[24].
Jakby nie narzekać na „proliferację”, nadal ogromna większość oprogramowania Open Source jest wydawana na zaledwie kilku najpopularniejszych licencjach (MIT, GPL 2.0, Apache, GPL 3.0, BSD, LGPL 3.0, AGPL 3.0)[25]. I głównie o nich będzie mowa.
Podsumowując – wykorzystanie komponentów na tzw. „permisywnych” licencjach Open Source (MIT, BSD, Apache) wiąże się głównie tylko z podaniem w dokumentacji odpowiedniej informacji o zastosowanym oprogramowaniu i licencji, która je obejmuje. Więcej uwagi należy poświęcić wykorzystaniu oprogramowania Open Source na licencjach typu copyleft. W tym przypadku istotny staje się sposób połączenia takiego oprogramowania z innymi elementami produktu, opisany poniżej. Ryzykowne może okazać się stosowanie komponentów na „egzotycznych” (rzadko spotykanych) licencjach, zwłaszcza jeśli nie zostały one poddane ocenie przez organizacje takie jak Free Software Foundation czy Open Source Initiative.
[22] Free Software Foundation, Various Licenses and Comments about Them, https://www.gnu.org/licenses/license-list.en.html [28 luty 2021 r.]; Open Source Initiative, Licenses by Name, https://opensource.org/licenses/alphabetical [27 luty 2021 r.]. [23] Open Source Initiative, Licenses by Name, op. cit. [24] C. Piana, A discussion of the different software licensing regimes [w:] Legal aspects of free and open source software, Policy Department C: Citizens’ Rights and Constitutional Affairs 2013. [25] Według danych udostępnionych przez Github, tylko około 15% licencji kodu przechowywanego w repozytoriach Github nie było objętych jedną z wymienionych licencji. Patrz Open source license usage on GitHub.com.. Dane te znajdują potwierdzenie w innych źródłach, które również wskazują na rosnącą popularność „permisywnych” licencji Open Source. Zob. P. Johnson, Open Source Licenses in 2021: Trends and Predictions, https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-trends-and-predictions [15 marzec 2021 r.]; Synopsys, Top open source licenses and legal risk, https://www.synopsys.com/blogs/software-security/top-open-source-licenses/ [10 marzec 2021 r.].
Jednym z najpowszechniej przyjętych kryteriów klasyfikacji licencji Open Source jest rozróżnienie między licencjami typu „copyleft” i „non-copyleft”. Rozróżnienie to odnosi się do kwestii, czy wyniki dalszego rozwoju i modyfikacji programu muszą być udostępniane na tej samej lub „kompatybilnej” licencji, co oryginalny program.
Ogólnie rzecz biorąc, licencje typu copyleft wymagają, aby wyniki dalszego rozwoju i modyfikacji programu były udostępniane na tych samych warunkach, co program oryginalny.
Decydując się na wykorzystanie kodu objętego copyleft, korzystający (programista) „zaraża” swoje rozwiązanie (swój kod) tą licencją. Jego program, do którego użył komponentów copyleft, powinien być objęty warunkami pierwotnej licencji copyleft. Ten szczególny efekt (tzw. „wirus copyleft”) ma na celu zabezpieczenie „otwartości” danego programu i zapobieżenie jego „uprzywilejowaniu”[26], nawet jeśli jest on używany w dziełach pochodnych.
Powyższa konsekwencja ma duże znaczenie praktyczne. W wielu środowiskach open source traktowany jest jako darmowa „baza kodu” do swobodnego wykorzystania. Twórcy copyleft wprowadzili jednak przebiegły i bardzo skuteczny mechanizm – możesz z naszego rozwiązania skorzystać, ale wtedy Twoje rozwiązanie będzie dalej dystrybuowane na naszych licencyjnych warunkach. O konsekwencjach opowiemy w dalszych częściach, ale oznacza to m.in., że jak użyjemy copyleft nie będziemy mogli żądać opłat licencyjnych za nasze rozwiązanie czy też będziemy zobowiązani do ujawnienia kodu źródłowego całości rozwiązania (w tym naszej, autorskiej części).
Rozróżnia się dwa rodzaje klauzul typu copyleft:
W praktyce (czytaj: upraszczając) oznacza to, że korzystając z kodu z „silną” licencją prawie na pewno „zarazimy” nasz kod warunkami takiej licencji. W przypadku „słabej” licencji standardowe zastosowanie danego komponentu (np. odwołania do biblioteki na LGPL) nie stwarzają takiego ryzyka.
Żeby było jeszcze trudniej – w niektórych przypadkach spotyka się także tak zwane „częściowe” klauzule copyleft. Częściowe licencje typu copyleft mają podobny skutek jak słabe klauzule copyleft. Częściowy copyleft zwalnia niektóre części utworu z copyleft, zezwala na rozpowszechnianie niektórych części utworu lub jego modyfikacji na warunkach innych niż licencja copyleft lub w inny sposób nie nakłada warunków copyleft na cały utwór. Przykładem częściowego copyleftu jest wyjątek GPL dotyczący linkowania, który zwalnia z copyleftu pliki nagłówkowe bibliotek oprogramowania i pozwala na dynamiczne linkowanie oprogramowania komercyjnego (np. wyjątek GCC Runtime Library). Skutek podobny do LGPL, ale diabeł tkwi, oczywiście, w szczegółach.
Zazwyczaj klauzula copyleft jest połączona ze zobowiązaniem do udostępnienia kodu źródłowego oprogramowania objętego licencją copyleft. Dzieje się tak dlatego, że licencja ta ma zapewnić użytkownikom możliwość czytania kodu, poprawiania go i dzielenia się swoimi zmianami. Skuteczne korzystanie z tych praw wymaga dostępu do kodu źródłowego.
Licencje „non-copyleft” (znane również jako „permisywne”) nie mają podobnych ograniczeń.
Z reguły nie ma więc przeciwwskazań do łączenia rozwiązań „własnościowych” i „otwartych”, w tym udostępniania rozwoju „otwartego” programu na licencji „zamkniętej”. Najpopularniejsze przykłady to MIT, BSD (wszystkie wersje) oraz Apache. Licencje te nie nakładają obowiązku udostępniania kodu źródłowego. Oznacza to, że program objęty taką licencją może być udostępniony zarówno w postaci binarnej, jak i źródłowej, niezależnie od tego, czy został zmodyfikowany, czy nie.
[26] Termin 'propertization’ w kontekście Open Source jest używany do opisania zjawiska 'zamykania’ produktu wcześniej Open Source, zazwyczaj poprzez wypuszczanie pochodnych produktu Open Source na 'zamkniętych’ licencjach. Zobacz także V.N. Vasudeva, Open source software paradigm and intellectual property rights, „Journal of Intellectual Property Rights” 2012, t. 17, nr.
Krótkie zestawienie rodzajów licencji Open Source:
Typ licencji – Nazwa licencji – Podstawowe obowiązki licencjobiorcy
Silny copyleft – GNU GPL 2.0, GNU GPL 3.0, GNU AGPL 1.0, GNU AGPL 3.0 – licencja wymaga zachowania informacji o prawach autorskich i licencji oraz wymaga od dystrybutorów udostępnienia kodu źródłowego komponentu i wszelkich dzieł pochodnych na tych samych warunkach.
Słaba copyleft – LGPL 2.1, LGPL 3.0, MPL 1.1, MPL 2.0 – licencja wymaga zachowania informacji o prawach autorskich i licencji oraz wymaga od dystrybutorów udostępnienia kodu źródłowego komponentu i wszelkich jego modyfikacji na tych samych warunkach. Nie każda praca pochodna musi być wydana na warunkach licencji.
Non-copyleft – MIT, BSD, Apache 2.0 – licencja wymaga zachowania praw autorskich i informacji o licencji, ale pozwala na dystrybucję na innych warunkach bez ujawniania kodu źródłowego.
Licencje open source są powszechnie używane, ale należy pamiętać, że stoją za nimi różne konstrukcje prawne. To nie jest „domena publiczna”, kod bez właściciela, pełna swoboda korzystania. To mniej lub bardziej daleko idące zobowiązania prawne, zwłaszcza w przypadku modeli copyleft.
Realnie największy wpływ na rynek ma licencja GNU GPL – nieostrożne z nią postępowanie grozi szkodami i kłopotami. O tym, jak przebiegle jest napisana, na czym w istocie polega efekt wirusa, kiedy działa, kiedy nie, o linkowaniach dynamicznych i statycznych, o micie, że zawsze musimy udostępniać kod źródłowy, o tym, co możemy (jako nabywca), jak znajdziemy GPL w kodzie dostawcy i inne opowieści z życia open-sourcowego prawnika – w następnym odcinku.