W jednym z ostatnich projektów, w którym uczestniczyłem, FOSSA zgłosiła nam użycie bibliotek typu open source na licencji GPL. To wywołało podniesienie czerwonej flagi ze strony kontrahenta, który nie zamierzał udostępniać kodu swojego oprogramowania (a tego wymaga wspomniana licencja).
Na szczęście zgłoszenia okazały się false-positivami. Okazało się, że każda ze zgłoszonych bibliotek była dystrybuowana również na jakiejś innej, mniej restrykcyjnej licencji. Niemniej jednak zaistniała sytuacja zainteresowała mnie tematem otwartoźródłowych licencji oprogramowania głębiej niż do tej pory.
Poprosiłem Jakuba Szarmacha (tego samego, który pomaga mi z IP Boxem) o wypowiedź w tym temacie, zadając mu jednocześnie kilka pytań pod tą konkretną sytuację. Zobaczmy więc wypowiedź Kuby:
Pisząc kod często korzystamy z zewnętrznych inspiracji lub zapożyczeń rozwiązań już istniejących. Kod najczęściej składa się z części i) tworzonych pod konkretny projekt, ii) tych, które deweloper rozwinął już przy innych projektach, iii) udostępnionych na zasadzie open-source. Open-source przyspiesza proces tworzenia oprogramowania i pozwala na standaryzowanie rozwiązań. Niesie za sobą jednak również ryzyka prawne.
Otwarte źródła, takie jak biblioteki, narzędzia i frameworki, są szeroko dostępne i mogą być wykorzystywane w różnych projektach. Dzięki temu deweloperzy mogą skupić się na innowacjach, dostosowaniu i integracji tych fragmentów do swoich projektów, co przyczynia się do szybszego wdrażania nowych funkcji i poprawy wydajności systemów lub aplikacji.
Większość publicznych bibliotek korzysta z licencji open-source, opierających się na tzw. „wolnym oprogramowaniu”. Przy korzystaniu z tego rodzaju źródeł, kluczowe jest skupienie się na warunkach licencji. Pierwszym krokiem powinno być sprawdzenie, czy oprogramowanie faktycznie jest „wolne” i pozwala na swobodne korzystanie z kodu źródłowego oraz dokumentacji.
Ograniczenia licencji mogą obejmować:
- klauzule copyleft: licencje, takie jak GPL wymagają, aby wszelkie pochodne prace były również udostępniane na takich samych warunkach jak oryginalne oprogramowanie. Oznacza to, że jeśli korzystasz z oprogramowania na takiej licencji i wprowadzasz do niego zmiany, musisz udostępnić te zmiany jako otwarty kod źródłowy,
- używanie w określonych celach: np. wyłącznie do użytku osobistego; zakaz użytku komercyjnego,
- możliwość sublicencjowania: tj. udostępnianie pochodnego programu dalej,
- możliwość wprowadzania ulepszeń lub modyfikacji: tj. niektóre licencje mogą ograniczać prawo do wprowadzania ulepszeń np. do określonych fragmentów kodu,
- zachowanie praw autorskich: wiele licencji, w tym również wiele licencji open-source, wymaga, zachowania informacji o prawach autorskich w kodzie źródłowym i dokumentacji oprogramowania,
- inne: odpłatność, ograniczenia czasowe, terytorialne, dowolność w wypowiedzeniu licencji.
Wszystkie te ograniczenia mogą występować w takiej lub inne postaci, lub być kombinacją niektórych lub wszystkich z nich. Cała dżungla rozwiązań!
Poniżej omówienie kilku najbardziej popularnych i problematycznych licencji.
Czym jest licencja GPL?
Licencja GPL tj. GNU General Public License to jedna z najpopularniejszych licencji wolnego oprogramowania. Zapewnia użytkownikom możliwość swobodnego korzystania, studiowania, zmiany i rozpowszechniania oprogramowania. Istnieje kilka wersji licencji GPL, ale wszystkie mają podobne cele i zasady (GNU GPL v.2, v.3).
Jej podstawowym ograniczeniem jest wymóg tego, aby każdy utwór, który bazuje na utworze udostępnionym na zasadzie GNU GPL też był pełnym, wolnym oprogramowaniem. GNU GPL jest licencją copyleft – która zapewnia, że każde rozpowszechnianie zmodyfikowanego oprogramowania lub jego pochodnych musi być również objęte licencją GPL. Dzięki temu nowopowstałe zasoby pozostają dostępne dla społeczności, a ich kod źródłowy jest otwarty dla wszelkich modyfikacji i ulepszeń.
Nie oznacza to, że przy korzystaniu z GPL deweloper ma obowiązek dalszego rozpowszechniania programu. Jeżeli jednak, program pochodny jest dalej udostępniany, licencja GPL wymaga udostępnienia go na tych samych warunkach.
Zgodnie z zasadami GPL, każda kopia, modyfikacja lub rozszerzenie oprogramowania musi być udostępnione na zasadach GPL, co oznacza, że nie można udzielić bardziej liberalnej licencji, takiej jak MIT, ani bardziej restrykcyjnej do nowopowstałego programu.
To jedna z najbardziej „wolnościowych” licencji i tego samego wymaga od kodu lub dokumentacji, który powstają z jej wykorzystaniem. Licencja GPL ma na celu promowanie wolności użytkowników oprogramowania i zapewnienie, że prawa autorskie nie ograniczają tych wolności.
GPL zostało stworzone przez Free Software Foundation (FSF), na czele której stoi Richard Stallman. FSF sprzeciwia się restrykcyjnym regulacjom prawa autorskiego i „własnościowym” zasadom udostępniania oprogramowania, które mogą ograniczać swobodę użytkowników. Niekiedy nie bez powodu określana jest „informatycznym komunizmem”. FSF stosuje termin „copyleft” jako odwrotność „copyright”, co oznacza, że oprogramowanie objęte licencją GNU GPL i podobnymi będzie zawsze dostępne na tych samych warunkach, nawet w przyszłych wersjach.
Nie bez powodu R. Stallman miał znaczący wpływ na rozwój systemu operacyjnego Linux poprzez swoje idee i wkład w rozwój ruchu wolnego oprogramowania. R. Stallman wspierał projekt Linuxa, promując go jako przykład wolnego oprogramowania. Chociaż Linux korzysta z jądra GNU/Linux, które było częścią większego systemu operacyjnego GNU, to nazwa „Linux” stała się powszechnie używana dla całego systemu operacyjnego, co niekiedy przysłaniało wkład GNU.
Jaka jest różnica pomiędzy GPL, a LGPL?
Licencja LGPL (Lesser General Public License), znana również jako GNU Lesser General Public License, to także jedna z licencji opracowanych przez FSF w ramach projektu GNU. LGPL korzysta jednak z „osłabionej” zasady copyleft.
GPL wymaga, aby wszelkie prace pochodne lub modyfikacje były dystrybuowane na zasadach GPL, a więc również jako otwarty kod źródłowy. Natomiast LGPL jest bardziej elastyczna w tym aspekcie i pozwala na linkowanie z bibliotekami LGPL nawet w przypadku projektów oprogramowania opartych na innych licencjach, bez konieczności udostępniania kodu źródłowego całego projektu.
Wybór pomiędzy nimi robi dużą różnicę, ponieważ licencja LGPL pozwala na użycie biblioteki w programach prawnie zastrzeżonych, a GPL nie. LGPL, w porównaniu do GPL nie nakłada ograniczeń copyleft na cały program, ale na pojedyncze pliki źródłowe.
W skrócie, LGPL jest mniej restrykcyjna w stosunku do dystrybucji kodu źródłowego niż GPL, co sprawia, że jest bardziej odpowiednia dla projektów bibliotek oprogramowania, które mają być wykorzystywane w różnych projektach o różnych licencjach. GPL natomiast ma szerszy zasięg i jest bardziej odpowiednia dla projektów oprogramowania, które mają być dystrybuowane jako całe aplikacje z otwartym kodem źródłowym.
Biblioteki na licencji LGPL nie sprawią również problemu w projektach, w których źródła nie otwieramy (dopóki nie modyfikujemy kodu samej biblioteki).
Dlaczego niektóre biblioteki udostępniane są na podwójnych licencjach GPL i LGPL?
Udostępnienie biblioteki na podwójnej albo potrójnej licencji pozostawia więcej swobody użytkownikowi, który z nich korzysta. Deweloper ma wybór – jaką licencję dalej wybiera.
Po pierwsze, udostępnienie biblioteki na dwóch licencjach pozwala na zwiększenie dostępności dla różnych projektów oprogramowania, które mogą być oparte na różnych licencjach.
Po drugie takie rozwiązanie wyłamuje się z obowiązku udostępnienia utworu pochodnego na zasadach GPL. Nowopowstały utwór zostaje udostępniony w ramach licencji GPL – a jednocześnie otwiera furtkę do dalszego udostępniania utworu na zasadach LGPL. W ten sposób dochodzi do przerwania wirusa GPL. Nie jest to cel, który przyświecał twórcom GNU, ale na pewno pozostawia więcej swobody użytkownikom, którzy dostają prawo wyboru.
W jaki sposób „wybiera się”, z której licencji decydujemy się skorzystać? Czy trzeba to gdzieś spisać?
„Wybór” najlepiej oznaczyć w dokumentacji własnego projektu lub programu. Przy postanowieniach dotyczących praw autorskich można dodać spis bibliotek open source, gdzie będzie pełna lista bibliotek, które były wykorzystane przy projekcie. Obok nazwy biblioteki należy podać jej wersję oraz licencję, na jakiej jest udostępniona (a w przypadku podwójnych licencji, wskazać, na jakiej licencji wykorzystujemy daną bibliotekę w projekcie). Takie oznaczenie jest od razu sygnałem dla odbiorcy projektu lub klienta, że projekt opiera się na legalnych źródłach. Jeżeli jest to możliwe, warto dodać odnośnik do oryginalnej dokumentacji danej biblioteki.
W przypadku licencji GPL, oznaczenie wyboru jest dość jednoznaczne i polega na tym, że każdy dalszy projekt, który opiera się na tej licencji jest zarażony wirusem GPL. Oznacza to, że będzie musiał być udostępniony na tych samych zasadach. Wówczas bezpośrednio w pliku źródłowym, w dokumentacji lub pod odrębnym linkiem „License” należy oznaczyć wybór licencji (w stosunku do całego projektu) przez umieszczenie odpowiedniego zapisu np.: GNU GPL 3.0.
Co oznacza, że licencja jest zgodna z GPL? I jakie ma to znaczenie?
Licencja GPL narzuca pewne zasady dotyczące dystrybucji i użytkowania oprogramowania, a zatem inne licencje muszą być zgodne z tymi warunkami, aby można było łączyć oprogramowanie objęte różnymi licencjami.
Zgodność licencji umożliwia łączenie (linkowanie) lub dystrybucję oprogramowania GPL z oprogramowaniem objętym innymi licencjami. Na przykład, oprogramowanie na licencji Apache 2.0 jest zgodne z GPL, co oznacza, że można łączyć oprogramowanie na licencji Apache 2.0 z oprogramowaniem na licencji GPL i dystrybuować je razem.
Licencje zgodne z GPL muszą wymagać udostępnienia kodu źródłowego, umożliwiać modyfikowanie i dystrybucję zmodyfikowanej wersji oraz nie naruszać warunków GPL dotyczących rozpowszechniania oprogramowania.
Taka zgodność umożliwia tworzenie kompleksowych systemów lub aplikacji z różnych komponentów oprogramowania, zachowując jednocześnie spójność z zasadami GPL.
Na które licencje wolnego oprogramowania trzeba uważać?
To pytanie należy odwrócić na – które licencje są w miarę bezpieczne i można z nich swobodnie korzystać. Obecnie licencji wolnego oprogramowania jest tyle, że wypracowanie jednego katalogu licencji, z których nie należy korzystać jest w praktyce niemożliwe.
Najbezpieczniejsze licencje, to nie bez powodu te najbardziej popularnie: MIT, GPL, LGPL, BSD.
Najczęściej używany jest MIT. Nie ogranicza użytku komercyjnego, jedynym wymogiem jest umieszczenie zmianki o prawach autorskich i kopii licencji pierwotnej.
Nie jest licencją copyleft i nie wymaga dalszego udostępniania na tych samych zasadach.
Podobną do MIT „bezpieczną” licencją jest BSD, czy Apache.
Przy projektach komercyjnych należy uważać na licencje oznaczone jako copyleft, które wymuszają wykorzystanie nowopowstałego programu na takich samych warunkach.
Przykładowe licencje copyleft: creative commons, Mozilla Public License, FAL.
Licencje copyleft o „słabszym” skutku to przede wszystkim LGPL, czy MPL.
W kontekście aktualnych zmian w licencjach open-source warto zwrócić uwagę na zmiany Terraform ze standardowej licencji open-source (MPL 2.0) na licencję typu Business Source License (BSL) v1.1. Ta zmiana wprowadza pewne ograniczenia dotyczące sposobu korzystania z Terraform, zwłaszcza w kontekście konkurencyjnych produktów.
Według nowych warunków licencji, HashiCorp (twórca Terraform) zabrania wbudowywania Terraform w produkty, które konkurują z produktami HashiCorp. Oznacza to, że firmy, które chcą używać Terraform w swoich produktach konkurencyjnych dla rozwiązań HashiCorp, będą musiały szukać alternatywnych rozwiązań lub uzyskać specjalne zezwolenie od HashiCorp.
Zmiana ma istotne konsekwencje dla społeczności DevOps, która często polega na Terraform do zarządzania infrastrukturą jako kod. Ograniczenie możliwości wykorzystania Terraform w konkurencyjnych produktach może wymagać od firm przemyślenia i dostosowania strategii infrastrukturalnych.
Wybór odpowiedniej licencji open-source ma kluczowe znaczenie dla każdego projektu oprogramowania. Licencja określa zasady, na jakich kod źródłowy może być używany, modyfikowany i rozpowszechniany, co może mieć znaczący wpływ na sposób, w jaki projekt jest rozwijany i dystrybuowany. Zawsze należy dokładnie zrozumieć warunki licencji, uwzględnić cele, rozważyć zgodność z innymi licencjami oraz przewidzieć przyszłe potrzeby, aby uniknąć konfliktów prawnych i ograniczeń w rozwoju projektu.
Chcesz dowiedzieć się więcej?
Mam nadzieję, że powyższy materiał pomoże Ci zrozumieć na co zwracać uwagę wykorzystując zewnętrzne oprogramowanie na otwartoźródłowej licencji.
Gdybyś jednak cały czas miał(a) jakieś wątpliwości odnośnie treści niniejszego artykułu, to śmiało pytaj w komentarzach poniżej.
Jeżeli sam(a) trafił[a|e]ś na jakiś ciekawy przypadek brzegowy, którego nie jesteś pewn[a|y], to również zachęcam do pisania o tym w komentarzach. Umówiłem się z Jakubem, że odpisze na każde tego typu zapytania, jak tylko będzie potrafił najlepiej.
Polecam również bezpośredni kontakt z Jakubem, gdybyś potrzebował(a) bardziej dogłębnej porady prawnej (w szczególności takiej wokół branży IT).
Bądź na bieżąco!
Podobają Ci się treści publikowane na moim blogu? Nie chcesz niczego pominąć? Zachęcam Cię do subskrybowania kanału RSS, polubienia fanpage na Facebooku, zapisania się na listę mailingową:
lub śledzenia mnie na Twitterze. Generalnie polecam wykonanie wszystkich tych czynności, bo często zdarza się tak, że daną treść wrzucam tylko w jedno miejsce. Zawsze możesz zrobić to na próbę, a jeśli Ci się nie spodoba – zrezygnować 
Dołącz do grup na Facebooku
Chcesz więcej? W takim razie zapraszam Cię do dołączenia do powiązanych grup na Facebooku, gdzie znajdziesz dodatkowe informacje na poruszane tutaj tematy, możesz podzielić się własnymi doświadczeniami i przemyśleniami, a przede wszystkim poznasz ludzi interesujących się tą samą tematyką co Ty.
W grupie Programista Na Swoim znajdziesz wiele doświadczonych osób chętnych do porozmawiania na tematy krążące wokół samozatrudnienia i prowadzenia programistycznej działalności gospodarczej. Vademecum Juniora przeznaczone jest zaś do wymiany wiedzy i doświadczeń na temat życia, kariery i problemów (niekoniecznie młodego) programisty.
Wesprzyj mnie
Jeżeli znalezione tutaj treści sprawiły, że masz ochotę wesprzeć moją działalność online, to zobacz na ile różnych sposobów możesz to zrobić. Niezależnie od tego co wybierzesz, będę Ci za to ogromnie wdzięczny.
Na wsparciu możesz także samemu zyskać. Wystarczy, że rzucisz okiem na listę różnych narzędzi, które używam i polecam. Decydując się na skorzystanie z któregokolwiek linku referencyjnego otrzymasz bonus również dla siebie.
Picture Credits
Dodaj komentarz