To jest 266. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o licencjach open source z punktu widzenia programisty komercyjnego. 

Wszystko, co potrzebujesz, notatka, linki, transkrypcja, czekają na Ciebie na porozmawiajmyoit.pl/266. Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz lub podzielenie się odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka.

Odpalamy!

Cześć! 

Mój dzisiejszy gość to programista .NET z ponad 10 latami doświadczenia, pasjonat wolnego i otwartego oprogramowania, po godzinach muzyk z zamiłowania. Moim i Waszym gościem jest Krzysztof Kempa. 

Cześć, Krzysztof, bardzo miło mi gościć Cię w podcaście. 

Cześć, witam Cię serdecznie, również mi miło. 

 

Z Krzysztofem będziemy rozmawiać o temacie, który mam wrażenie dotyka dużą większość projektów IT, czyli wykorzystania w nich oprogramowania open source, a co się z tym wiąże, również licencji, na jakich one są rozprowadzane. Można powiedzieć, że temat wydaje się dosyć oczywisty, ale pewnie większość programistów, którzy wykorzystują tego typu projekty open source, oprogramowanie open source, nie do końca wie, z czym wiążą się licencje, jakie konsekwencje dla projektu i samego wykorzystania właśnie oprogramowania open source niosą. Tak że dzisiaj z Krzysztofem przejdziemy sobie przez ten temat w celu, mam wrażenie, niesienia większej świadomości właśnie wśród programistów komercyjnych, którzy wykorzystują oprogramowanie open source. 

Zanim jednak do tego przejdziemy, to Krzysztof, chcę Cię zapytać, czy słuchasz podcastów? Może jakieś ciekawe audycje będziesz w stanie tutaj polecić? 

 

Jeżeli chodzi o taki świat trochę IT, trochę taki około powiedzmy ścisło naukowy, jest dwóch ludzi, których bardzo lubię słuchać. Pierwszy to jest Lex Friedman. Może się spotkałeś z tym człowiekiem? 

 

Tak, tak, bardzo ciekawa postać. 

 

I on właśnie prowadzi bardzo często podcasty na takie tematy okołonaukowe. Pamiętam, zwłaszcza jako, że jestem z pola IT, wywiad z Johnem Carmackiem, człowiekiem, który odpowiada za gry od id Software typu Doom, Quake, Wolfenstein 3D i dzięki temu człowiekowi cały jakby świat grafiki 3D dzisiaj istnieje i wygląda tak, jak wygląda. Dzięki wielu jego przełomowym, różnym rozwiązaniem. I pamiętam, to było 5 godzin podcastu, gdzie panowie siedzieli i rozmawiali na różne tematy z tym związane, bardzo polecam. 

Drugi człowiek z podobnego, chociaż bardziej zróżnicowanego, mam wrażenie, świata, to jest Joe Rogan, którego na pewno wszyscy kojarzą. Ten człowiek zaprasza bardzo różnych gości do siebie, ale też związanych właśnie trochę z tym światem. Pamiętam, że miał też z Elonem Muskiem jeden podcast. Tak że bardzo różnorodni goście, bardzo ciekawe tematy i bardzo miło się słucha. Człowiek naprawdę umie prowadzić podcasty, wie, jak to robić. Tak że tych dwóch panów najczęściej słucham i gorąco polecam. 

 

Dzięki za rekomendację. No tak, to skrajnie różne mam wrażenie osobowości, ale faktycznie posiadają tą umiejętność rozmowy i faktycznie są to pasjonujące podcasty do słuchania. 

Dobrze, Krzysztof, nie wiem, czy się ze mną zgodzisz, ale przeciętny programista zapytany o to, czym jest oprogramowanie open source, coś tam będzie w stanie na ten temat opowiedzieć, ale jakby tak się pewnie głębiej i dokładniej temu przypatrzeć, to mogą być jakieś różnice w tym, jak go definiują, więc może rozpocznijmy od tego i powiedzmy, co to jest właściwe open source. 

 

O tyle mamy szczęście, że Open Source Initiative, inicjatywa Open Source, definiuje jakby listę punktów, które dane oprogramowanie musi spełniać, żeby było uznane za open source. Bo wiele osób myśli, że jeżeli mamy dostęp do kodu źródłowego, to już automatycznie czyni to open source, ale jest trochę więcej kryteriów, które musimy spełnić. Więc po kolei. 

Pierwszy punkt, który oni wymieniają, to jest możliwość wolnej redystrybucji, czyli możemy dowolnie to oprogramowanie rozprowadzać, rozdawać, dystrybuować. Nie możemy w tym być w żaden sposób ograniczeni i co ciekawe, nie wszyscy to chyba wiedzą, umożliwia to również sprzedawanie takiego oprogramowania i licencje open source w żaden sposób nie zabraniają nam sprzedawać oprogramowania open source’owego, które również jest dostępne jako darmowe. Stąd na przykład wiele osób pewnie się spotkało ze sprzedawanymi dystrybucjami Linuxa na płytkach dołączonych do czasopism, tak że pierwszy warunek. 

Drugi, jak sama nazwa wskazuje, możliwość dostępu do kodu źródłowego. Więc musimy mieć dostęp do kodu źródłowego. Musi być on opublikowany w takiej formie, żeby był bezproblemowy do niego dostęp. Nie musi być to bezpośrednio dostępne, tak jak często to jest np. na GitHubie czy GitLabie w jakichś repozytoriach, ale jeżeli ktoś poprosi o dostęp do tego kodu, musi mieć taką możliwość. Więc druga rzecz, dostęp do kodu źródłowego. 

Trzecia rzecz, prace pochodne, czyli musimy mieć możliwość, wziąć sobie takie oprogramowanie, zmodyfikować je i rozprowadzać zmodyfikowaną wersję tego oprogramowania z wszelkimi naszymi zmianami, więc musimy mieć to umożliwione. 

Kolejny punkt, tzw. integrity, czyli jakby tożsamość oryginalnego kodu źródłowego. O co tutaj chodzi? Jeżeli jesteśmy autorem oprogramowania, który stworzył sobie taki kawałek kodu open source, musimy też mieć możliwość pokazania, udowodnienia, że to, co opublikowaliśmy, to jest to, co my żeśmy stworzyli bez żadnych modyfikacji, czyli musimy mieć taką możliwość odróżnienia, co jest oryginałem, a co modyfikacją. I to się wiąże z tym, że nasza licencja może też zezwalać tylko i wyłącznie na publikowanie patchy, czyli jakby modyfikacji do oryginalnego kodu źródłowego.

To bardzo często ma zastosowanie w aplikacjach związanych np. z bezpieczeństwem danych, szyfrowaniem, kiedy bardzo nam zależy, żebyśmy wiedzieli, że ta oryginalna wersja oprogramowania to jest dokładnie ta jedna wyprodukowana przez tą firmę i to się wiąże bardzo często z tym, że chcemy mieć pewność, że nie ma wprowadzonych żadnych dodatkowych luk zabezpieczenia czy jakichś furtek. A w przypadku, kiedy chodzi o bezpieczeństwo naszych informacji, naszych danych, no jest to kluczowa sprawa, więc musimy mieć możliwość pokazania, że to jest ta oryginalna wersja, to jest ta uznana, bezpieczna, zaudytowana właśnie, bo to często też się wiąże z audytami oprogramowania.

Tak jak swego czasu był bardzo popularny program TrueCrypt do szyfrowania danych, który jakieś 10 lat temu zniknął w tajemniczych okolicznościach, został sforkowany, teraz ten fork najpopularniejszy nazywa się Veracrypt. i wokół tego oprogramowania też było prowadzone mnóstwo audytów, które miały dowodzić, że tak, to jest bezpieczne, nikt nam się nie włamie, nikt nie złamię jakby bezpieczeństwa tych danych, które są zaszyfrowane. Więc to jest à propos tego Integrity. 

Kolejne dwie klauzule, dwa jakby podpunkty, to jest brak dyskryminacji przeciwko ludziom i grupom, więc licencja nie może w żaden sposób dyskryminować, kto może tego używać, czy to jeżeli chodzi o konkretne osoby, czy o grupy, a także nie może dyskryminować pod kątem tego, w jaki sposób mamy to używać, gdzie możemy to wykorzystać, więc nie możemy zabraniać użytkownikom w żaden sposób wykorzystywania tego oprogramowania w określony sposób. 

Kolejny punkt, dystrybuowanie licencji, czyli kwestia wszelkich praw dołączonych do oprogramowania. Musimy mieć możliwość zapoznania się z tymi postanowieniami licencji bez konieczności uruchamiania oprogramowania. Więc musimy mieć możliwość zapoznania się z tym, na jakie licencje to jest udostępniane, co możemy z tym zrobić, zanim w ogóle cokolwiek z tym zrobimy. 

I dwa ostatnie podpunkty dotyczą ewentualnych restrykcji, więc oprogramowanie open source nie może jakby ograniczać innych, innego software’u, innego oprogramowania, które jest dystrybuowane razem z tym. Czyli np. nie możemy ograniczać możliwości dystrybucji pod tym kątem, żeby wymagać dystrybucji na tym samym medium, czyli nie możemy na przykład np. wymagać, żeby nasz software open source’owy był rozprowadzany na tym samym CD, łącznie z jakimś innym pakietem oprogramowania. Musimy mieć możliwość wzięcia tego kawałka, oddzielenia i użycia tego odrębnie, indywidualnie.

I ostatni punkt, licencja musi być technologicznie neutralna, czyli np. nie możemy powiedzieć użytkownikom, że słuchajcie, możecie tego używać, ale tylko na Windowsie, a na Macu i Linuxie już nie. Takich ograniczeń też nie możemy wprowadzać. Użytkownicy muszą mieć możliwość, jeżeli nawet chcą to zmodyfikować, żeby mogli to potem uruchomić na dowolnej platformie, jaka im odpowiada. 

I to jest właśnie cała lista warunków, które oprogramowanie musi spełnić, żeby mogło być uznane za open source. 

Kolejny punkt, tzw. integrity, czyli jakby tożsamość oryginalnego kodu źródłowego. O co tutaj chodzi? Jeżeli jesteśmy autorem oprogramowania, który stworzył sobie taki kawałek kodu open source, musimy też mieć możliwość pokazania, udowodnienia, że to, co opublikowaliśmy, to jest to, co my żeśmy stworzyli bez żadnych modyfikacji, czyli musimy mieć taką możliwość odróżnienia, co jest oryginałem, a co modyfikacją. I to się wiąże z tym, że nasza licencja może też zezwalać tylko i wyłącznie na publikowanie patchy, czyli jakby modyfikacji do oryginalnego kodu źródłowego.

 

Czyli faktycznie znacznie więcej i znacznie szerzej niż tylko dostęp do kodu źródłowego. Podałeś tam całą listę różnych punktów, warunków, które muszą być spełnione, aby można było takie oprogramowanie nazwać jako open source. Natomiast często zamiennie z open source stosuje się również pojęcie wolnego oprogramowania, czyli free software. Chciałbym Cię zapytać, czy to są faktycznie tożsame pojęcia? Jaka tutaj historia za tym stoi, że faktycznie tymi dwoma pojęciami się posługujemy? 

 

Historia tutaj sięga już lat 70. I to wszystko zaczęło się od ruchu wolnego oprogramowania. Właśnie zanim powstał open source, był ruch wolnego oprogramowania, od którego to się wszystko wywodzi. I właśnie zanim powiemy troszeczkę o historii open source, to musimy poruszyć kwestię free software, czyli wolnego oprogramowania. I to wszystko zaczęło się od pana Richarda Stallmana, aktywisty, hakera, który odpowiada w ogóle za powstanie tego ruchu. I cała historia zaczęła się, co ciekawe, od drukarki. 

Krótka historia. Richard Stallman, w tamtych czasach, w latach 70., 80. haker, pracownik laboratorium sztucznej inteligencji MIT, miał problemy z jedną z drukarek, z której korzystali. Mieli drukarki Xeroxa i jedna z tych drukarek bardzo często się zacinała. Na szczęście w tamtych czasach coś takiego jak prawa autorskie, kod źródłowy, to były pojęcia dosyć takie jeszcze niespotykane, ponieważ wszystkie pieniądze, które były związane z zarabianiem na komputerach, zarabiały się praktycznie na sprzęcie. Software, oprogramowanie było takim dodatkiem do tego wszystkiego, żeby sprzęt działał, czyli jakby priorytetem był wtedy sprzęt. I nie było aż takich ograniczeń nakładanych na kod źródłowy. Dopiero to się zaczęło jakoś zmieniać mniej więcej z wkroczeniem Microsoftu i Bill Gatesa na scenę, kiedy ten człowiek zauważył, że na całym software też da się zarobić. 

I wracając do tej drukarki, panowie mieli dostęp do kodu źródłowego tej drukarki i zmodyfikowali ten kod źródłowy tak, żeby drukarka ich powiadamiała, kiedy zatnie się w niej papier, żeby ktoś mógł podejść, odblokować to i w ten sposób oszczędzić dużo czasu, który straciliby, na przykład czekając na wydruk 200 stron, kiedy się okazuje, że zacięło się to na trzeciej stronie i panowie musieliby w ten sposób zmarnować dużo czasu. 

I po pewnym czasie Xerox przysłał im nową drukarkę, która już nie miała dostępu do kodu źródłowego i nie było już możliwości zmodyfikowania tego w ten sposób, już nie mogli zmodyfikować tak funkcjonalności, żeby ta drukarka ich powiadamiała o tym. Richard Stallman wtedy wystąpił z prośbą do Xeroxa o udostępnienie kodu źródłowego, ale Xerox odmówił. I Richardowi to się bardzo nie spodobało. Był to człowiek, który z takiego bardzo etycznego punktu widzenia patrzył na to wszystko. Uważał, że dzielenie się kodem źródłowym, wiedzą, oprogramowaniem stanowi jakby podstawę nauki, podstawę jakby IT w tamtych czasach, postanowił stworzyć ruch oprogramowania, który w podstawowym założeniu miałby właśnie tą wolność, tę możliwość dzielenia się kodem źródłowym, uruchamiania go, dystrybuowania. 

I w 1983 roku jako konsekwencja m.in. tego oraz późniejszych różnych perturbacji powstał tzw. manifest GNU i zaczął powstawać system operacyjny GNU. To był skrót od GNU is not Unix i to miał być wolny i otwarty klon systemu operacyjnego Unix, który w tamtym czasie też miał dosyć ograniczoną licencję, jeżeli chodzi o dzielenie się tym kodem, możliwość uruchamiania. Więc Richard Stallman w tamtym czasie zaczął tworzyć system operacyjny GNU. 

I to były właśnie początki wolnego oprogramowania. Wtedy powstał manifest GNU, który definiował m.in. kilka takich założeń à propos możliwości uruchamiania tego oprogramowania, modyfikowania, analizowania kodu źródłowego. W późniejszym czasie powstała licencja GNU GPL, o której sobie trochę później powiemy. To była pierwsza z takich jawnie zdefiniowanych licencji, która stanowiła wolne oprogramowanie. I to się rozwijało jakoś przez lata 80. W międzyczasie Richard Stallman zrezygnował z pracy w MIT i poświęcił się w pełni rozwijaniu systemu operacyjnego GNU. 

I to mniej więcej zaczynało powoli sklejać się w całość na początku lat 90. Mieli już wtedy całą masę narzędzi, kompilator GCC, wszystkie core utility, czyli takie narzędzia jak LS, GREP, MV itd. Wszyscy ci, którzy obcują na co dzień z Linuxem albo systemami Linunxo podobnymi będą wiedzieli, o co chodzi. To są podstawowe narzędzia, które umożliwiają nam tworzenie, usuwanie plików, listowanie zawartości katalogów, czyli takie podstawowe narzędzia, które stanowią jakby trzon Unixa. 

Jedyne, czego im brakowało w tamtym czasie, to jąder systemu operacyjnego i ze względu na różne zawirowania licencyjne związane z systemem BSD, o którym też sobie trochę wspomnimy, który też jest wtedy jeszcze pełnokrwistym Unixem, dzisiaj jest troszeczkę bardziej uznawany za klon Unixa, chcieli pozyskać sam kerner, samo jądro systemu z tamtego miejsca, ale niestety różne problemy licencyjne nie pozwoliły na to i pojawił się pan Linus Torvalds, którego pewnie też ludzie kojarzą, który stworzył jądro systemu operacyjnego Linux. Jako początkowo projekt hobbystyczny, ale myślę, że i ku jego zaskoczeniu tak się rozrósł, że stanowi dzisiaj w zasadzie podstawę wszystkiego, co dzisiaj funkcjonuje w internecie. Więc jeżeli ktoś ma telefon z Androidem, czy odwiedza jakiekolwiek strony internetowe, wszędzie obcuje z tym jądrem Linuxa. 

I po połączeniu właśnie systemu GNU i jądra Linuxa powstał system GNU slash Linux, GNU plus Linux, różnie to jest nazywane, ale my to w skrócie nazywamy Linuxem. I to były jakby takie pierwsze poważne kroki ku rozpowszechnieniu się wolnego oprogramowania. W konsekwencji tego, że był dostępny wolny, darmowy system operacyjny, który był już wtedy, powoli stawał się dobrą alternatywą dla komercyjnego Unixa, firmy zaczęły zauważać, że można tego użyć również w celach komercyjnych. Między innymi właśnie serwery webowe zaczęły się pojawiać hostowane na Linuxie. 

I tak przez lata 90. coraz więcej firm zaczęło się interesować tym modelem rozwoju oprogramowania. Ale Free Software, wolne oprogramowanie miało to do siebie, że przede wszystkim skupiało się na takim etycznym aspekcie, a trochę mniej na pragmatycznym. I właśnie Linus Torvalds był jedną z takich osób, które wybrały licencję GNU GPL, czyli dokładnie taką samą, z której korzystał pierwotnie i do tej pory korzysta system GNU. Ze względu na takie bardziej pragmatyczne podejście, gdzie mnóstwo osób może współpracować nad tym samym kawałkiem kodu źródłowego, mnóstwo oczu jest jakby skierowanych na ten kod, może znaleźć wszelkie błędy, może zasugerować jakieś rozwiązania i to bardzo się spodobało Linusowi pod względem takiej kolaboracji i takiej współpracy i tworzeniu wspólnie tego kodu, żeby rozwijać jakiś wspólny cel. 

I pod koniec lat 90. właśnie zaczęto się skupiać bardziej na tym aspekcie i powoli gdzieś tam zaczęło się przebijać to określenie open source, które jakoś zdefiniowało się w roku 98. Po publikacji takiej książki, którą polecam, The Cathedral and the Bazaar, czyli Katedra i Bazaar, ta książka jest na temat dwóch różnych modeli rozwoju oprogramowania, czyli tzw. rozwój katedry, gdzie powstaje taki jeden wielki monolit, coraz kolejne jakby nowe wersje są wypuszczane i to wszystko jest skupione wokół jakiejś takiej zamkniętej grupy, natomiast bazar to jest taki model właśnie, jak to bardziej Linus widział w przypadku Linuxa, gdzie mnóstwo osób może wejść, zostawić jakąś drobną kontrybucję od siebie, wyjść i w ten sposób taki grupowy rozwój trochę taki chaotyczny, trochę taki przy udziale tłumu, może się to wszystko rozwijać. 

I wtedy zaczęło się jakby powoli tworzyć ten ruch open source, gdzie po publikacji tej książki stworzyła się jakby koalicja kilku firm, które zdefiniowały właśnie coś takie jak open source, wtedy właśnie powstał ten termin. Zdefiniowane zostały właśnie te punkty, o których sobie wcześniej mówiliśmy. I od tego momentu ten ruch do tej pory się rozwija i do tej pory jest jakby aktywny. 

I tak jak mówię, w porównaniu do free software, wolnego oprogramowania, on jest skupiony bardziej takim pragmatycznym, bardziej kolaboracyjnym aspekcie, czyli jak najłatwiej rozwijać takie oprogramowanie, jak umożliwić jak najefektywniejsze rozwijanie takiego oprogramowania, tak żeby komercyjne zastosowanie jakby też było dużo bardziej przyjazne w odróżnieniu tylko i wyłącznie od aspektów takich etycznych. 

 

Bardzo ciekawa historia. Myślę, że te idee Richarda Stallmana niejako znalazły swoje zastosowanie i ziściły się, ponieważ bardzo szeroko oprogramowanie open source jest obecnie wykorzystywane, od małych po duże projekty, nawet tzw. Big Tech w żaden sposób nie stroni od open source’u, wręcz sam tworzy, kontrybuuje do różnych rozwiązań open source’owych. 

Pojawia się pytanie, jakie są zalety tego bazaru w stosunku do katedry, czyli co stoi za tym, żeby faktycznie spróbować wykorzystać open source w stosunku do takiego zamkniętego komercyjnego oprogramowania.

 

Ja widzę kilka takich punktów. Przede wszystkim numer jeden, który mnie osobiście bardzo często dotykał, to możliwość samodzielnej naprawy wszelkich błędów i problemów w kodzie źródłowym. Jeżeli już jesteś programistą z doświadczeniem, jeżeli wiesz już, z czym to się je, jeżeli masz dostęp do kodu źródłowego w jakiejś bibliotece czy w jakimś kawałku oprogramowania zewnętrznym, z którego korzystasz, bardzo często zaczynasz zauważać, że no tutaj ten case jest okej, ale można by to troszeczkę dla naszego konkretnego zastosowania zrobić lepiej. 

I w momencie, kiedy korzystamy z komercyjnego oprogramowania, które nakłada pewne restrykcje licencyjne i nie pozwala nam swobodnie wprowadzać zmian, tylko musielibyśmy najpierw zgłosić taką zmianę jako ticket powiedzmy, czy jako jakąś propozycję, poczekać aż firma stwierdzi, czy chcą to zrobić, czy nie, poczekać aż to udostępnią, aż dostaniemy nową wersję i mieć nadzieję, że przy okazji licencja się nie zmieni, tak tutaj, kiedy korzystamy z open source’owych rozwiązań, nic nie stoi na przeszkodzie, żebyśmy samodzielnie zmienili coś w kodzie źródłowym, wprowadzili jakieś własne łatki i zmodyfikowali to pod siebie. Tak że bardzo ułatwia to rozwój oprogramowania i wszelkie jakby modyfikacje, które mogą nam wejść na korzyść. 

À propos licencji, właśnie to, co jeszcze wspomniałem, brak opłat licencyjnych. W momencie kiedy korzystamy z open source’owych rozwiązań, nie musimy się martwić o niekorzystne jakieś zmiany w komercyjnych licencjach, bo zdarzają się nieraz takie sytuacje, kiedy autorzy danego software’u z wersji na wersję potrafią wprowadzać jakieś zmiany, które powoli zwiększają opłaty, bądź ograniczają możliwość użycia w pewnych kwestiach. I bardzo ciekawym przykładem, który mnie osobiście zainteresował, było to, co się stało w zeszłym roku z silnikiem do gier Unity. 

Wszyscy ci, którzy nas słuchają i interesują się gamedev’em, myślę, że wiedzą, czym jest Unity. Unity w zeszłym roku postanowiło wprowadzić dodatkowe opłaty nałożone na autorów gier, za każdy zainstalowany przypadek Unity Runtime, czyli tych bibliotek całego frameworka, który umożliwia w ogóle nam odpalenie gier z Unity. 

I spotkało się to z ogromnym odzewem i z ogromnymi protestami ze strony ludzi, którzy korzystają z Unity, ponieważ było to w bardzo niejasny, bardzo zawiły sposób sformułowane. I w najgorszych wypadkach mogło dojść do tego, że autor musiałby więcej wydać na te wszystkie licencje, niż by zarobił na grze, co kompletnie im się nie opłacało. I ludzie w tamtym czasie zaczęli się interesować alternatywnym open source’owym silnikiem do gier, który nazywa się Godot. 

I Unity musiało się wycofać z tego i w tym roku, to jakoś nawet niedawno było, kompletnie wykreślili jakby to postanowienie i całkowicie zrezygnowali z tych opłat per instalacja frameworka, i teraz tylko i wyłącznie zostały licencje takie per seat, czyli za każde stanowisko się płaci jednorazową płatę i to jest wszystko. I w międzyczasie zrezygnował też ówczesny CEO Unity, który był odpowiedzialny za tę zmianę. Tak że w momencie, kiedy korzystamy z open source’owego oprogramowania, nie musimy się martwić o takie rzeczy. I to są moim zdaniem takie najważniejsze zalety, które ja bym osobiście wymienił. 

 

Tak, jako programiści mam wrażenie, że bardzo często nie doceniamy albo wręcz nie mamy odpowiedniej wiedzy na temat takiej, nazywam to różnorodności licencji właśnie open source, a to niesie ze sobą bardzo silne, mocne konsekwencje w zależności od tego, na co nam ta licencja pozwala i co nam robi z projektem, do którego takie oprogramowanie dołączamy, więc myślę, że to jest dobry moment, żeby sobie spróbować z lotu ptaka spojrzeć na te różne rodzaje licencji open source’owych.

 

Myślę, że najlepiej będzie podzielić je na trzy kategorie. Licencje liberalne, czyli takie, które w zasadzie pozwalają nam na wszystko, czego programista mógłby potrzebować bez praktycznie żadnych ograniczeń. 

Na drugim biegunie są licencje restrykcyjne albo też tzw. copyleft. Tutaj małe wyjaśnienie pojęcia. To jest taki mały wordplay, mała zabawa z słowem od copyright. gdzie copyleft oznacza użycie praw autorskich, żeby jak najbardziej wymusić taką otwartość i wolność danego oprogramowania. Bardzo często są to nazywane też licencjami wirusowymi, ponieważ przy zastosowaniu, przy włączeniu kodu na takiej licencji do naszej aplikacji wymuszają jednocześnie udostępnienie naszego kodu, jeżeli spełniamy pewne określone warunki, wymusza to również udostępnienie naszego kodu na postanowieniach tych samych licencji. 

I gdzieś pośrodku są takie semi-restrictive, że tak powiem półrestrykcyjne licencje, które zachowują część tych restrykcyjnych postanowień, tych restrykcyjnych licencji, ale umożliwiają nam na wykorzystanie tego pod określonymi warunkami w oprogramowaniu komercyjnym. 

I najpierw myślę, że zaczniemy od tych najbardziej przyjemnych i najczęściej używanych przez nas licencji liberalnych. I takie trzy najważniejsze licencje albo nawet rodziny licencji w przypadku BSD, a to za chwilkę przejdziemy do tego, to są tak licencja MIT, licencja BSD i licencja Apache. 

I jedna z najpopularniejszych i najbardziej liberalna licencja To jest licencja MIT i to właśnie ta nazwa licencji pochodzi od uczelni MIT, Massachusetts Institute of Technology. Stamtąd wywodzi się ta licencja. I w zasadzie jedyne, z czego nas zobowiązuje, to umieszczenie takiego copyright notice, czyli informacji o tym, że wykorzystujemy tę bibliotekę, framework, czy ten kawałek kodu. Gdzieś, jeżeli publikujemy to oprogramowanie, to gdzieś musimy zawrzeć taką informację o tym, czy to na przykład na jakiejś liście, czy w jakimś pliku z licencjami i jakby dać kredyt autorowi, który odpowiada za to. I to jest w zasadzie wszystko. 

I jeszcze jedno postanowienie, jedna informacja, która jest zawsze zawarta w takich licencjach, to że oprogramowanie jest zapewnione, dystrybuowane as is, czyli tak jak jest i autorzy nie odpowiadają za wszelkie konsekwencje użycia tego oprogramowania. Więc możesz tego używać, ale jeżeli coś zrobić na swoją szkodę, to nie próbuj w żaden sposób nas pozywać. To jest w zasadzie całość, jeżeli chodzi o licencję MIT. Pozwala nam na zamykanie kodu źródłowego, pozwala nam na włączanie do zamkniętego kodu źródłowego, czyli możemy jednocześnie i włączyć naszego oprogramowania, które rozwijamy sobie gdzieś tam w firmie. Możemy stworzyć fork, czyli własną jakby wersję tego projektu, zamknąć kod źródłowy i z nikim się z tym nie dzielić. Czyli jakby najmniej problematyczna dla ludzi, którzy chcą, tak jak ja, jako programiści w firmie, wykorzystać taką bibliotekę czy framework. 

Kolejna licencja z tej kategorii to jest licencja BSD i ta licencja wywodzi się z Unixa BSD, o którym wcześniej wspomniałem, systemu operacyjnego BSD. Skrót oznacza Berkeley Software Distribution i to była jedna z wersji systemu operacyjnego Unix, który powstawał właśnie jeszcze w latach 70., 80. I ta licencja ma kilka różnych takich wersji, które różnią się liczbą takich klauzuli, czyli takich warunków, które one zawierają. I są cztery jakby kategorie, z czego dwa są bardzo popularne, często używane, a dwa bardziej myślę jako ciekawostka, rzadko się z tym spotykam. Są wersje licencji BSD 0-klauzulowe, 2-klauzulowe, 3-klauzulowe i 4-klauzulowe. 

I teraz, o co w tym wszystkim chodzi? 0-klauzulowa to jest w zasadzie ekwiwalent tzw. public domain, czyli własności publicznej, gdzie praktycznie nie ma żadnych ograniczeń na to nałożonych, czyli każdy może z tym wziąć, robić to, co chce, nawet nikomu o tym nie mówić. Dwie jednak popularniejsze wersje tej licencji to są licencje 2- i 3-klauzulowa. 

2-klauzulowa funkcjonalnie jest identyczna do licencji MIT, czyli tak jak w przypadku licencji MIT zawrzeć ten copyright notice, dać kredyt autorowi i to w zasadzie wszystko. 3-klauzulowa licencja dokłada jeszcze taki warunek, gdzie jeżeli reklamujemy nasz software, to nie możemy używać nazwisk, imion i generalnie tożsamości osób, które stoją za tym oprogramowaniem, do jakby reklamowania tego. 

Czyli jeżeli, załóżmy na to, że Elon Musk czy John Carmack, jakieś takie bardzo znane osoby, miałyby swój udział w jakimś projekcie na licencji tej BSD 3-klauzulowej, z którego to korzystamy, to jeżeli byśmy reklamowali, to nie możemy powiedzieć, że wow, słuchajcie, mamy kod, który był rozwijany przez Johna Carmacka, ponieważ licencja na to zabrania, a poza tym wolna ręka, możemy zamknąć ten kod źródłowy, tak samo jak w przypadku licencji MIT, możemy go włączyć do naszego zamkniętego projektu, żadnych takich większych ograniczeń. 

I czwarta wersja tej licencji, z którą ja się osobiście nie spotkałem, to jest licencja 4-klauzulowa, która do wszystkich wyżej wymienionych dokłada jeszcze taki warunek, że jeżeli nasza praca pochodna w reklamach wymienia funkcje, z których korzystamy, które są jakby za przyczyną tego softu, to musimy jakby dać znać, że korzystaliśmy z tej oto biblioteki i dzięki temu mamy dostarczone na przykład takie feature. To wszystko, jeżeli chodzi o licencję BSD. 

I trzecia taka bardzo popularna licencja, to jest licencja Apache. Od właśnie oprogramowania do hostowania serwerów Apache. Stamtąd się wchodzi ta licencja. Ma bardzo podobne postanowienia do licencji MIT, czyli tak, też musimy zawrzeć copyright notice, też poinformować o tym, że używamy w oprogramowaniu właśnie na tej licencji, dać kredyt autorom i oprócz tego dokłada jeszcze pewne warunki na temat patentów. 

I teraz, o co tutaj chodzi? Jeżeli jako kontrybutor włączamy nasz jakiś kod, czyli coś dodajemy od siebie do licencji Apache, dostajemy prawa do korzystania ze wszystkich patentów, które wiążą się z tym oprogramowaniem i tak samo jeżeli my włączamy jakiś kod na licencji Apache, do której mamy patent, to tak samo my dajemy inną możliwość korzystania z tego patentu i jednocześnie jest taki warunek, że jeżeli chciałbyś pozwać kogoś w sądzie za to, że korzysta z twoich patentów, których udzieliłeś jakby, będąc kontrybutorem, to automatycznie, jeżeli pozyskałeś przez kontrybucję prawa do takich patentów, w momencie gdybyś próbował pozwać kogokolwiek w sądzie, tracisz automatycznie możliwość wszelkie prawa do tych patentów. 

Tak że w skrócie można to podsumować jako takie dzielenie się patentami i nie ciągajmy się po sądach, nie pozywajmy się wzajemnie. Takie najważniejsze założenie licencji Apache. 

I to były trzy najpopularniejsze licencje takie liberalne i teraz przejdźmy na drugi biegun, czyli na licencje restrykcyjne i zacznijmy sobie od licencji GPL, o której wspomniałem. Autorem tej licencji był Richard Stallman, o którym już wcześniej mówiliśmy i licencja GNU GPL właśnie wywodzi się od systemu operacyjnego GNU. I ona była skonstruowana w ten sposób, żeby uniemożliwić ludziom, którzy by tworzyli jakby pochodne dzieła, zamknięcie kodu źródłowego i niedzielenie się tymi wszelkimi zmianami. Czyli ta licencja wymusza na nas, że jeżeli włączymy jakąś bibliotekę czy jakiś framework, na licencji GPL do naszego projektu, musimy jednocześnie udostępnić kod źródłowy tego projektu i wszelkie modyfikacje na postanowieniach tej samej licencji. 

I stąd się wzięła też nazwa takiej licencji wirusowej, ponieważ jakby zaraża swoją licencją, swoimi postanowieniami wszelki software, w którym to wykorzystujemy. I tu niestety jest bardzo duży problem z wykorzystaniem tego w zastosowaniach komercyjnych, ponieważ z natury, jeżeli mamy jakiś projekt komercyjny, to bardzo pilnie strzeżemy tego kodu źródłowego, więc wykorzystywanie jako prac pochodnych takiej licencji niestety odpada kompletnie. 

Są pewne warunki, o których myślę, byśmy powiedzieli później, pewne jakieś sytuacje, gdzie można w jakiś sposób włączyć to oprogramowanie, ale 99% przypadków wymusza na nas podzielenie się tym kodem źródłowym w przypadku, kiedy włączamy kod na licencji GPL. Mamy gdzieś pośrodku, jakby tak jak mówiłem, pomiędzy tymi licencjami restrykcyjnymi, a liberalnymi, licencje takie same i restrictive. 

I tutaj mamy dwie licencje. Ze względu właśnie na te problemy, czy jakby na założenia licencji GPL, powstała alternatywna wersja, która na pewnych warunkach pozwala nam włączenie tego do zamkniętego kodu źródłowego. Ta licencja nazywa się Lesser GPL, czyli Lesser General Public License. I ona się tym różni od licencji GPL, że taką bibliotekę czy taki framework pozwala na włączenie do zamkniętego kodu źródłowego i wykorzystywanie jej z takim projektem. Ale jeżeli my jakieś swoje zmiany wprowadzimy do takiej biblioteki, do takiego frameworka, czyli jeżeli jakoś zmodyfikujemy to wszystko i potem rozprowadzamy tę zmodyfikowaną wersję, to dalej te zmiany, które dotyczą tej właśnie biblioteki, tego frameworka, musimy udostępnić wszystkim, którzy dostają jakby dystrybucję tego software’u, musimy też tą zmodyfikowaną wersję im udostępnić.

Tak że możemy włączać do zamkniętych projektów, ale wszelkie zmiany do samej biblioteki, samego frameworka, tym musimy się dzielić.

I oprócz tego jeszcze z takich licencji semi-restrictive jest taka licencja Mozilla Public License, stworzona przez Mozilla Foundation odpowiedzialnych za m.in. Firefoxa, która też wymusza udostępnienie czy dzielenie się jakby tym oryginalnym kodem źródłowym przy możliwości włączenia do zamkniętych projektów, z tym że ta licencja patrzy nie jak na bibliotekę, czy na framework jako taki monolit, jako taką całość, ale traktuje to wszystko per plik kodu źródłowego.

Więc jeżeli mamy jakąś bibliotekę, która stanowiłaby taki trzon, foundation takiego naszego projektu, chcielibyśmy to mocno rozbudować, zmodyfikować, dodać do tego setki plików kodu źródłowego, to jedyne jakby fragmenty, jedyne czym musielibyśmy się dzielić, to są modyfikacje do oryginalnych plików, natomiast wszystko, co jest naszym własnym dziełem, tym już nie musimy się dzielić i to możemy wykorzystać w naszym projekcie, zamknąć ten kod źródłowy i to może zostać po naszej stronie. Tak że taki mały kompromis, gdzie dalej ten kod źródłowy, który był oryginalny, on zostaje jakby wolny i otwarty, ale wszelkie nasze jakby nadbudówki, takie modyfikacje, to może zostać u nas, bez dzielenia się tym. I tak jak mówiłem, bez problemu możliwości włączania tego do zamkniętych, do komercyjnych aplikacji.

I myślę, że mamy ogarnięty taki przegląd tych trzech kategorii licencji, o które najbardziej byśmy się mogli martwić. Jeszcze są różne drobniejsze licencje, których jest mnóstwo, ale one są tak rzadko spotykane, że musielibyśmy tu godzinami siedzieć i wyłącznie o tym rozmawiać, a myślę, że niestety tyle czasu nie mamy.

 

Jasne, dzięki za ten przegląd. Widać, że faktycznie w detalach, w szczegółach potrafią się one dość mocno różnić i różne mogą mieć konsekwencje. Czy znasz jakieś strony, serwisy, miejsca w sieci, gdzie dałoby się przynajmniej zapoznać z tymi licencjami, a idealnie w jakiś sposób je porównać, dobrać taką licencję do rozwiązania open source?

 

Myślę, że zacznijmy od jakby głównego źródła. Sama strona open source ma zakładkę licenses. Jeżeli wejdziemy sobie na opensource.org/licenses, tam mamy całą listę licencji, które są OSI approved, czyli jakby zaakceptowane przez Open Source Initiative jako licencje typu open source. Tam mamy wyszukiwarkę, możemy wyszukiwać te po słowach kluczowych czy po nazwie, zapoznać się z warunkami i dowiedzieć się, z czym to się je, dokładnie jak wyglądają warunki tej licencji.

Natomiast jeżeli chcielibyśmy coś prostszego, jakiś łatwiejszy sposób, gdzie poprowadzi nas to bardziej za rękę, jest taka stronka choosealicense.com. która pozwala nam na wybór open source’owej licencji i to zarówno przyda się osobom, które korzystają z frameworków czy bibliotek dostarczonych z zewnątrz, jak i osobom, które chciałyby na własną rękę rozwijać taki software open source’owy, gdzie mamy całą masę takich przykładów, jak pytanie: which of the following best describes your situation? Czyli który z wyżej wymienionych opisuje idealnie twoją sytuację? I mamy możliwość na podstawie tego wybrania do naszej sytuacji, do naszych jakby warunków, która licencja będzie nam najbardziej odpowiadała, najbardziej pasowała.

Tak że te dwie stronki polecam jako drogowskaz, który pokazałby potencjalnym użytkownikom, które licencje byłyby dla nich najbardziej interesujące i najlepsze w ich przypadku.

Sama strona open source ma zakładkę licenses. Jeżeli wejdziemy sobie na opensource.org/licenses, tam mamy całą listę licencji, które są OSI approved, czyli jakby zaakceptowane przez Open Source Initiative jako licencje typu open source. Tam mamy wyszukiwarkę, możemy wyszukiwać te po słowach kluczowych czy po nazwie, zapoznać się z warunkami i dowiedzieć się, z czym to się je, dokładnie jak wyglądają warunki tej licencji.

 

Super. W tej dzisiejszej rozmowie nie tylko przekrojowo chcemy pokazać różne typy licencji open source, ale również dać programistom, którzy na co dzień zajmują się tworzeniem oprogramowania komercyjnego, jakieś wytyczne, wskazówki co do tego, jak mogą wykorzystać tę wiedzę właśnie, włączając do swoich projektów oprogramowanie open source.

I w duchu tego chciałbym Cię zapytać, czy ta restrykcyjna, jak tutaj zdefiniowałeś licencja GPL, jest możliwa, czy da się w jakiś sposób ją wykorzystać, albo oprogramowanie na jej podstawie rozprowadzane w projektach komercyjnych, czyli czy nie chcemy zarazić tego naszego projektu komercyjnego właśnie tą licencją, czy są jakieś rozwiązania w tym kierunku?

 

Tak, są. I ja zawsze wymieniam dwa takie rozwiązania. Pierwsze to jest multi-licensing i bardzo dużo firm, które rozwija oprogramowanie, które jest udostępniane na licencji GPL, ma również alternatywną licencję komercyjną, którą możemy wykupić i korzystać z tego oprogramowania na zasadach licencji komercyjnej. Tak że dwie albo więcej licencji bardzo często mają takie projekty.

I moim ulubionym przykładem tutaj jest framework Biblioteka Qt do tworzenia interfejsów użytkownika na różne platformy w języku C++ i nie tylko. Oni udostępniają to jednocześnie na licencji GPL i z tego korzysta bardzo dużo open source’owych projektów, jak na przykład środowisko dla Linuxa KDE Plasma, środowisko graficzne najpopularniejsze, albo jedno z najpopularniejszych moim zdaniem, ale także firmy komercyjne, które chciałyby wykorzystać bibliotekę Qt w swoim oprogramowaniu mogą wykupić u nich licencję komercyjną, która pozwala na włączenie tego do zamkniętych aplikacji bez jakby łamania tych zasad licencji GPL, ponieważ w tym momencie używamy tego na zasadach innej licencji. Nie podlegamy już tutaj pod licencję GPL, tylko pod tą licencję, którą komercyjnie stworzyła firma, która zajmuje się rozwojem frameworka Qt.

A druga taka możliwość to jest na przykład to, co zrobił Google z Androidem, czyli stworzenie takiej platformy z takiego bazowego systemu operacyjnego na bazie software’u open source’owego, w tym wypadku jądra Linuxa i wykorzystanie jako takiej platformy.

I teraz, dlaczego możemy coś takiego zrobić? Ponieważ kernel Linuxa ma w swoich postanowieniach, jest tam taki plik licenses zawarty razem z kodem źródłowym, który wyraźnie jakby daje taki wyjątek, że w momencie kiedy wykorzystujemy kernel Linuxowy do używania takich systemowych wywołań, systemowych przerwań, to w tym momencie nie podpadamy jakby pod definicję działa pochodnego i w tym momencie nie ogranicza nas licencja GPL.

I dokładnie to zrobił Google, kiedy stworzył Android Open Source Project, który ma właśnie w swoim sercu jądro Linuxa. I to jest rozwijane jako open source, możemy sobie to pobrać, modyfikować, uruchamiać, tworzyć forki tego i własne wersje, ale na bazie tego nabudowali usługi Google Play i wszystkie aplikacje, które są takim w zasadzie sercem Androida, gdzie sam Android Open Source Project jest tylko taką podstawą, bazą, fundamentem. Natomiast Android w dzisiejszych czasach nie jest Androidem bez usług Google Play.

I o tym, myślę, wiele osób się przekonało w momencie, kiedy Huawei dostał pewne restrykcje, jeżeli chodzi o wykorzystywanie tworzonego w Ameryce oprogramowania, gdzie musieli stworzyć własną alternatywę dla usług Google Play i to była dosyć wyboista droga w momencie, kiedy to rozwijali. I właśnie myślę, mało ludzi ma taką świadomość, jak bardzo, mimo tego, że Android jest u podstaw open source’owy, to jak bardzo dużo zależy od tej zamkniętej części, która jest jakby na wierzchu, więc takie dwa przykłady, gdzie możemy wykorzystać właśnie taki software na różne sposoby.

 

To mogłoby się wydawać, że gdy bierzemy sobie taką przykładowo bibliotekę open source, stworzoną nierzadko przez społeczność, to właściwie kto będzie się martwił licencją, bo kto będzie ją egzekwował później, czy jej zapisy, prawda? Może mogłoby się tak wydawać. I tutaj możemy się niestety mocno przejechać i chciałbym Cię poprosić o może jakieś przykłady tego, z jakimi problemami, jakimi konsekwencjami możemy się tutaj zmagać, jeśli nie będziemy zasad licencji przestrzegać?

 

Jasne. I tutaj mi się nasuwają dwa takie przykłady. Pierwszy to jest to, co stało się we Francji, gdzie Orange, który wygrał przetarg na stworzenie takiego administracyjnego systemu dla Monservice Public, ktoś tak nazywa. Nie wiem dokładnie, jak to się mawia po francusku, ale myślę, że to wystarczy. To był internetowy portal, który umożliwiał ludziom załatwianie różnych spraw administracyjnych. I Orange przy projektowaniu tego portalu skorzystało z takiej biblioteki, która się nazywa Lasso. To był system single sign-on stworzony przez firmę Introvert.

I oni, podobnie jak to było z Qt, udostępniali to na dwóch różnych postanowieniach licencyjnych, na licencji GPL i na alternatywnej komercyjnej licencji. Orange miał pierwotnie wykupić prawa do tej komercyjnej licencji, ale w końcu tego nie zrobili. Stworzyli portal bazujący na tej bibliotece. Wprowadzili tam swoje zmiany, swoje modyfikacje do tej biblioteki, do tego software’u, które nazywa się Lasso, ale nie spełnili założeń licencji GPL, nie udostępnili zmienionego kodu źródłowego, nie udostępnili swoich zmian. I w tym momencie firma Introvert poszła z tym do sądu i wygrali od Orange 900 tys. euro za złamanie postanowień licencyjnych.

Więc mimo tego, że mogłoby się wydawać, że nikt tym się nie przejmie, no niestety już zdarzały się, jak widzimy takie sytuacje, gdzie jednak ludzie z tym poszli do sądu i wygrali.

I drugi taki przykład. Jeden z dosyć dużych koncernów samochodowych oparł swój firmware, swój software używany w swoich samochodach na jądrze Linuxa i początkowo nie podzielili się z tym. I zostali w końcu zmuszeni do wypuszczenia całego kodu źródłowego, ponieważ to wszystko właśnie stanowiło taki monolit i podpadało już właśnie pod definicję dzieła pochodnego. I ten software już przyjął taką podobną postać jak Android, można powiedzieć, więc żeby spełnić postanowienia licencji GPL, musieli wypuścić ten kod źródłowy. I ten kod źródłowy jest dostępny w internecie, jest dostępny na GitHubie. Można to sobie pobrać.

Więc takie dwa przykłady. Dlatego uczulam, musimy bardzo uważać na to, na jakiej licencji oprogramowanie włączamy do naszego komercyjnego projektu, żeby potem nie mieć żadnych kłopotów, jeżeli chodzi o jakieś prawne kwestie.

 

No tak, to może nas faktycznie bardzo zaboleć. No właśnie w tym dzisiejszym świecie, kiedy mamy do czynienia z mnóstwem usług w modelu SaaS, kiedy de facto nie mamy konieczności wręcz czy kupna oprogramowania, ponieważ korzystamy z tych dobrodziejstw przez internet, jak tutaj aplikuje się do tego cały ten temat licencji, czyli jedną z obowiązków, jak w aplikacjach sieciowych działają licencje GPL i inne?

 

No właśnie, to jest bardzo ciekawy przykład, ponieważ początkowo licencja GPL, jako że była tworzona w latach jeszcze osiemdziesiątych, nie przewidywała jakby takiego zastosowania i jeżeli mieliśmy jakiś software, jakąś bibliotekę, czy nawet cały serwer na licencji GPL, który potem mogliśmy wystawić jako usługę sieciową, w tym momencie licencja GPL nie wymuszała na nas dzielenia się kodem źródłowym, ponieważ wykorzystanie sieciowe nie było zdefiniowane jako tzw. dzieło pochodne.

Więc póki samego tego softu serwerowego, jakiego jakoś nie dystrybuowaliśmy, nie rozprowadzaliśmy, powiedzmy, czy to w sklepach, czy nie sprzedawaliśmy ludziom, tylko dostało sobie u nas na naszych wewnętrznych serwerach, nie musieliśmy się dzielić z tym kodem źródłowym i w ramach tego powstała kolejna odmiana licencji GPL, która nazywa się Affero GPL, która właśnie zawiera ten oto przypadek i w momencie, kiedy mamy jakiś software, właśnie jakiś serwer czy jakąś bibliotekę wykorzystywaną w usłudze sieciowej na licencji Affero GPL, to w tym momencie to wykorzystanie sieciowe już podlega jakby jako pod prace pochodne i w momencie, kiedy output z naszego softu jest wyrzucany, powiedzmy, w sieć, wymusza to na nas też dzielenie się tym kodem źródłowym.

Więc to jakby zamyka tą furtkę która była oryginalnie w tej licencji GPL, więc wszelkie jakby aplikacje, wszelkie jakieś frameworki itd., jeżeli chcemy tego używać po sieci, musimy zwrócić uwagę, czy to nie jest na licencji Affero GPL, ponieważ w tym momencie nawet udostępnienie samego takiego web serwisu mogłoby na nas wymusić otwarcie całej reszty kodu źródłowego aplikacji.

 

Dobrze, zatem z perspektywy programisty rozwiązań komercyjnych. Mamy tę grupę licencji, powiedzmy, nierestrykcyjnych, które są względnie bezpieczne. Mamy te właśnie na drugim biegunie, jak to określiłeś, czyli restrykcyjne, które musimy przynajmniej wiedzieć, jak działają, żeby nie wpaść na przysłowiową minę, to może spójrzmy na tę grupę, która jest pośrodku, czyli te semi-restrykcyjne jak LGPL. Czy jest to bezpieczne, aby w rozwiązaniach komercyjnych wykorzystywać właśnie oprogramowanie na takiej licencji?

 

Właśnie, to jest bardzo ciekawy temat, ponieważ licencja LGPL jest świadomie i celowo napisana w taki dosyć niejasny sposób, gdzie pewne sądy, pewne instytucje mogłyby na różny sposób interpretować pewne postanowienia, co stanowi dzieło pochodne, co nie stanowi dzieła pochodnego. Więc to bym po prostu zalecał ostrożność.

Ja się spotykałem do tej pory z wykorzystywaniem oprogramowania na licencji LGPL w projektach komercyjnych bez żadnych problemów. Natomiast trzeba pamiętać właśnie o jednej rzeczy. W przypadku licencji LGPL wszelkimi naszymi modyfikacjami, które wprowadzamy do oryginalnego projektu, musimy się podzielić. Więc gdyby ktoś wpadł na pomysł umieszczenia tam jakiegoś kluczowego, bardzo ważnego fragmentu kodu, który stanowi jakiś nasz trade secret, jakiś trademark, czyli jakąś własność intelektualną, którą za nic nie chcielibyśmy się dzielić z konkurencją, ponieważ ona jakby stanowi trzon naszych dochodów, to nie możemy umieszczać takiego kluczowego kodu jako część modyfikacji tej biblioteki czy tego softu na licencji LGPL. Ponieważ mimo tego, że możemy włączyć tę bibliotekę do zamkniętej aplikacji, to wszelkimi modyfikacjami, które my do niej wprowadzimy, musimy się dzielić i udostępnić kod źródłowy.

Więc to jest jedna rzecz, o której musimy bardzo pamiętać. Jeżeli stanowi to nasze takie narzędzie, tak jak dwa takie przykłady mi się przypominają, jest takie narzędzie do translacji, do udostępnienia wielu języków w naszej aplikacji GNU GetText, to jest też część projektu GNU, w momencie, kiedy tylko i wyłącznie używamy tego jako takiego narzędzia i nie stanowi jakby to trzonu serca naszego projektu, to okej, nie będzie to stanowiło żadnego problemu.

Natomiast tak jak mówię, jeżeli byśmy chcieli stworzyć na bazie tego jakiś większy projekt i tam rozwijać to wszystko, to już bym tego raczej unikał i tutaj z pomocą przychodzi jakby licencja MPL, Mozilla Public License, o której mówiłem, gdzie wszelkie modyfikacje, które wprowadzimy poza oryginalnymi plikami z kodu źródłowego, to już możemy zachować dla siebie.

Więc licencja MPL w odróżnieniu od licencji LGPL pozwala nam jakby na budowanie na bazie jakiegoś biblioteki czy frameworka oryginalnego całej masy naszego kodu źródłowego i pozostawienie tego dla siebie.

Natomiast co do używania jeszcze oprogramowania na licencji LGPL w naszych aplikacjach. Teraz jeżeli słuchają nas jacyś programiści, którzy pracują właśnie w firmach i chcieliby włączyć jakiś software na takie licencji, zalecałbym konsultację czy to z działem compliance, czy z jakimś leadershipem, czy to jest okej, czy mieliśmy takie przypadki, czy np. nasz klient nie będzie miał z tym żadnych problemów ze względu właśnie na taką troszeczkę niepewność w pewnych kwestiach tej licencji, zalecamy po prostu ostrożność i konsultację.

Natomiast trzeba pamiętać właśnie o jednej rzeczy. W przypadku licencji LGPL wszelkimi naszymi modyfikacjami, które wprowadzamy do oryginalnego projektu, musimy się podzielić. Więc gdyby ktoś wpadł na pomysł umieszczenia tam jakiegoś kluczowego, bardzo ważnego fragmentu kodu, który stanowi jakiś nasz trade secret, jakiś trademark, czyli jakąś własność intelektualną, którą za nic nie chcielibyśmy się dzielić z konkurencją, ponieważ ona jakby stanowi trzon naszych dochodów, to nie możemy umieszczać takiego kluczowego kodu jako część modyfikacji tej biblioteki czy tego softu na licencji LGPL.

 

Taka wiedza i świadomość tego, jaka licencja przychodzi do nas, do projektu z dołączonym oprogramowaniem open source jest istotna, ale musimy też być świadomi, że to oprogramowanie może zmienić swoją licencję w czasie i w teorii oczywiście jest to możliwe. Jestem ciekawy, czy w praktyce spotkałeś się z jakimiś przykładami tego typu działań?

 

Tak i myślę tutaj takim dosyć dobrym przykładem jest dosyć popularna baza danych MongoDB, która swego czasu była dostępna na licencji AGPL, czyli właśnie tej Affero GPL, o której wcześniej mówiłem. Natomiast jakiś czas temu MongoDB zmieniło tę licencję na własną customową licencję, którą oni nazwali jako Server Site Public License i dołożyli do niej taką klauzulę, że jeżeli używamy tego sieciowo i wprowadzamy jakieś zmiany, to musimy podzielić się kodem źródłowym do całego serwisu, do całego stacku, z którego korzystamy. Więc jakby jeszcze bardziej restrykcyjnie tutaj podchodzi do takiego dzielenia się tym kodem źródłowym.

I co ciekawe, tej alternatywnej licencji Open Source Initiative już nie uznaje jako open source, ze względu na to, że zbyt restrykcyjnie podchodzi do tego wszystkiego i w ich przeświadczeniu ma to zniechęcić ludzi do właśnie takiego korzystania sieciowego z tej licencji. I to jest jeden taki przykład z naszego komercyjnego świata.

Drugi taki przykład, który ja bardzo dobrze pamiętam, trochę mniej z komercyjnego, bardziej takiego indywidualnego, to jest bardzo popularne kiedyś narzędzie do obróbki grafiki Paint.NET, które było swego czasu i w sumie jest do tej pory taką dobrą alternatywą dla Gimpa i Photoshopa.

I jeżeli dobrze pamiętam, do wersji trzeciej ono było na licencji MIT, czyli tej najbardziej liberalnej, a późniejsze wersje zmieniły już licencję na komercyjną, gdzie ten kod źródłowy przestał być dostępny.

I właśnie tutaj jest jeden z takich, nazwijmy to, problemów licencji MIT, że to działa w obie strony, że jednocześnie my możemy wziąć sobie taki kod źródłowy, zamknąć to kompletnie i nie dzielić się z tym z nikim, ale równie dobrze może to zrobić ktoś inny, więc jeżeli polegaliśmy od lat na jakimś open source’owym narzędziu, które do tej pory zawsze było udostępnione na tej licencji, zawsze jakby autor dzielił się tym kodem źródłowym, to musimy pamiętać, że licencja pozwala mu na to, żeby w dowolnej chwili zamknął ten kod źródłowy i już z nikim się tym nie dzielił. Takie dwa przykłady, które ja bardzo dobrze pamiętam.

 

Zalecałeś tutaj jakieś konsultacje z działem compliance, z działem prawnym, jeśli nie jesteśmy pewni tego, jakie konsekwencje może nieść wybór oprogramowania z właśnie taką licencją, o której tutaj rozmawiamy. Natomiast zastanawiam się, czy w tej dobie, w której to AI często generuje dla nas kod, nie mamy pewnego ryzyka, czy pewnej furtki, żeby właśnie prześlizgnął się do naszego oprogramowania jakiś fragment, który był podstawą do uczenia AI, a który jest obwarowany jakimiś obostrzeniami właśnie licencyjnymi.

 

Na to bardzo trzeba uważać, ponieważ AI jest trenowane. Żebyśmy w ogóle mogli wygenerować taki kod, najpierw musimy na czymś tę sztuczną inteligencję wytrenować. I na czym najłatwiej wytrenować taką sztuczną inteligencję? Ano na publicznie dostępnym kodzie źródłowym, którego jest mnóstwo wszędzie. A jak już rozmawialiśmy, różne typy licencji tego kodzie źródłowego możemy spotkać. Jedne bardziej liberalne, inne trochę mniej. Więc zawsze jest niebezpieczeństwo, że gdzieś zupełnie przypadkiem możemy trafić na to, że takie AI nam wygeneruje fragment kodu źródłowego, który pochodzi z licencji, która kompletnie nie może się znaleźć w komercyjnej aplikacji.

I tutaj z pomocą przychodzi nam GitHub Copilot, bardzo ostatnio popularne narzędzie, które ma możliwość włączenia takiego feature’a, który pokazuje nam, które fragmenty kodu, które nam to narzędzie wygenerowało, pochodzi z publicznie dostępnych repozytoriów I jednocześnie umożliwia nam to sprawdzenie, na jakiej licencji był udostępniony ten oryginalny projekt.

Więc możemy włączyć taką możliwość generowania tego kod źródłowego z publicznych repozytoriów i w tym momencie będziemy wiedzieli, czy to, co nam zostało wygenerowane, jest na bezpieczne licencje rozprowadzane, czy też nie. Więc to jest taki przykład, jak radzić sobie z tym, co nam generuje AI z ostatniego podwórka.

Jestem ciekaw, jak to się będzie zmieniało, ponieważ to wszystko cały czas ewoluuje i w dzisiejszych czasach to tak idzie do przodu, że myślę, że to będzie się zmieniało nawet z tygodnia na tydzień, więc zalecam też zapoznawanie się z wszelkimi nowinami.

 

Tak, tak. Tym bardziej pewnie człowiek nie jest w stanie tego kontrolować i musi polegać niestety na narzędziach. Niestety, właśnie o narzędzia też chciałem Cię zapytać, czy mamy coś w tym naszym narzędziowniku, co by nam pozwoliło wykryć takie sytuacje, kiedy potencjalnie możemy łamać licencję?

 

Tak, Bardzo popularne narzędzie, z którym wielokrotnie się spotykałem, to jest Black Duck. I Black Duck ma takie dwie funkcje. Pierwsze to jest wyszukiwanie luk w oprogramowaniu, które mogłyby stanowić jakby problem bezpieczeństwa w naszej aplikacji. Ale druga taka funkcja, z którą ja się spotkałem, to jest wyszukiwanie w naszym kodzie źródłowym, podobnie jak to w przypadku tego, co nam generuje Copilot, fragmentów kodu, które pochodzą z publicznie dostępnych repozytoriów i jednocześnie sprawdzenie, na jakiej licencji oryginalnie był udostępniony ten kod źródłowy.

Więc Blac Duck ma taką dosyć pokaźną bazę kodu źródłowego, który pochodzi z publicznych repozytoriów i porównuje sobie to, co u nas w naszej aplikacji znajdzie przy skanowaniu i sprawdza, że tutaj ten kod pochodzi z tego repozytorium, to było oryginalnie udostępnione na tej licencji. My możemy się z tym zapoznać, zobaczyć, czy przypadkiem nie mamy jakiegoś problematycznego kodu u siebie i odpowiednio zareagować, czy to pisząc na przykład alternatywę, czy jeżeli licencja jest przyjazna dla nas, możemy to po prostu zostawić. Więc polecam korzystanie z Black Duck’a. 

 

Świetnie. W tej dzisiejszej rozmowie skupiamy się głównie na zastosowaniach komercyjnych, czy na wykorzystaniu open source właśnie w rozwiązaniach komercyjnych, ale gdybyśmy wyszli poza ten krąg, to jakie według Ciebie są możliwości wykorzystania właśnie open source’a poza tymi komercyjnymi zastosowaniami?

 

Pierwsza taka rzecz to zwykli użytkownicy domowi, którzy korzystają na co dzień z komputera jako takiego narzędzia rozrywki. Czyli zwykły człowiek, który po prostu ma laptopa, ogląda na nim Netflixa, sprawdza Facebooka, coś tam czasami napisze jakiś dokument, wydrukuje, napisze do kogoś maila i tacy ludzie w 95% przypadków, myślę, mogliby spokojnie pozbyć się Windowsa, który jest najczęściej preinstalowany na ich komputerach i zainstalować sobie jakąś dystrybucję Linuxa, która w zupełności wystarczy do takich codziennych zastosowań.

I dobrym przykładem jest moja mama, której zainstalowałem właśnie zamiast Windowsa jedną z dystrybucji Linuxa. Głównie ze względu na to, że ona bardzo często robi przelewy bankowe i trochę się martwiłem o to, że mogłaby gdzieś przypadkiem na Facebooku kliknąć jakiś link, zainstalować sobie jakiś malware i potem mieć jakieś problemy z kontem. A w przypadku Linuxa, który jest raczej bezpieczny od takich problemów, raczej się nie muszę o to martwić. I to w zupełności wystarcza i nawet jest mniej problemów, ponieważ nie dostaję tych ekranów mówiących o tym: odśwież swój Windows, zainstalowaliśmy ci Edge czy jakichś innych takich przerywników, które bardzo się często zdarzały, i dużo mamy mniej problemów z tym.

Niektórym by się wydawało, że Linux potrafi takie problemy generować, gdzie zwykły użytkownik taki, który nie jest techniczny, miałby tego nie umieć używać, ale niestety nie mogę się z tym zgodzić. Jeżeli moja mama jest w stanie korzystać z komputera z Linuxem na co dzień do oglądania Netflixa, YouTube’a itd., to myślę, że większość użytkowników sobie z tym bez problemu poradzi.

A tak poza zastosowaniami domowymi, administracje publiczne i szkolnictwo, takie instytucje powoli zaczynają przechodzić w wielu przypadkach na wolne i otwarte oprogramowanie. I tak na przykład wiele urzędów, wiele administracji w krajach takich jak Niemcy, Dania czy Holandia przechodzą na open source i to głównie dotyczy pakietu biurowego, czyli Microsoft Office’a, który jest powoli zastępowany w pewnych kręgach Liber Office’em, czyli wolnym i darmowym odpowiednikiem, który jest na licencji open source udostępniany.

I powoli, powoli mam wrażenie, że to zaczyna wkraczać w coraz szersze kręgi. I tak samo spotykałem się z tym w przypadku szkolnictwa. Czy to chociażby nawet na Politechnice Łódzkiej, gdzie ja studiowałem. Bardzo dużo komputerów miał albo tylko i wyłącznie Linuxa, albo jednocześnie dostępnego Linuxa z Windowsem.

Ale też spotykałem się z przypadkami, gdzie w szkołach podstawowych były też sale informatyczne, które miały zainstalowanego Linuxa i myślę, że w przypadku dzieci, które dopiero się uczą z tego korzystać i kiedy zaoferuje im się środowisko, które jest jakoś zbliżone do Windowsa czy nawet troszeczkę inne, to myślę, że bez problemu to podchwycą i to nawet jest bardzo dobra opcja, żeby trochę jakby rozszerzyć inny świat i pokazać, że na różne sposoby komputery mogą działać i mamy różne możliwości korzystania z tego.

Więc poza komercyjnym światem to środowisko jest bardzo otwarte i moim zdaniem to jest bardzo interesujący temat i przy tym, co się dzieje na przykład z Windowsem 11 ostatnio, zauważyłem, że coraz więcej osób zaczęło się interesować przejściem na Linuxa, ponieważ zapewne kojarzysz tę funkcję Microsoft Recall, która robi nam screenshoty co kilka sekund i teoretycznie ma nam umożliwiać jakby przeglądanie tego, co my robiliśmy do tej pory, sprawdzanie tego, jak wygląda nasza historia działań na komputerze, ale to też stanowi potencjalną furtkę bezpieczeństwa, która mogłaby narazić nas na ujawnienie pewnych prywatnych danych.

I, jako że Microsoft ostatnio, może się to kiedyś zmienić, nigdy nie wiemy, ale ostatnio zaczął wymuszać jakby pozostawienie tego zawsze włączonego, Coraz więcej osób zauważyłem, że zaczyna się interesować Linuxem. I co ciekawe, jak sprawdzałem statystyki wykorzystywania, jeżeli chodzi o Linuxa, od roku, dwóch zaczęło to jakoś bardzo rosnąć i tak jak pamiętam jeszcze czasy mojego liceum 2008-2009 to było gdzieś poniżej 1%, tak teraz jak to sprawdzałem, ostatnio było gdzieś tam, kręciło się w okolicach 4-4,5%, więc jakby na przestrzeni tylu lat jakby pięciokrotny mniej więcej wzrost, to już jest coś znaczącego, więc zatacza to coraz szersze kręgi.

 

Tak, myślę, że bardzo dobrze, bo de facto oprócz tych różnych tutaj zalet, które wymieniłeś, no to jeszcze swego rodzaju konkurencja dla tych rozwiązań komercyjnych, myślę, że wprowadzana przez oprogramowanie open source też jest istotna, też napędza rozwój, też powoduje, że właśnie chociażby na przykładzie tego engine’u game’owego, jest konieczna jakaś tam reakcja ze strony tych często bardzo dużych podmiotów, ponieważ istnieją jakieś alternatywy open source’owe, gdyby ich nie było, to pewnie większy monopol niestety by na rynku istniał.

Krzysztof, bardzo Ci dziękuję za rozmowę. Cieszę się bardzo i jestem Ci wdzięczny, że pokazałeś ten przekrojowy temat licencji i tego, że programiści, którzy na co dzień właśnie tworzą oprogramowanie komercyjne, również muszą być świadomi, albo przede wszystkim muszą być świadomi tego, co licencje te, o których dzisiaj mówiliśmy, wnoszą do projektu. Myślę, że ta świadomość jest potrzebna i dzięki Ci wielkie, że podzieliłeś się też swoim doświadczeniem i takim praktycznym podejściem do tego tematu.

 

Dzięki serdeczne.

 

Powiedz, proszę, na koniec, gdzie Cię możemy znaleźć w internecie, gdzie możemy słuchaczy odesłać.

 

Dwa takie miejsca. Myślę, że pierwsze to jest mój LinkedIn: LinkedIn.com/in/krzysztofkempa, a drugie takie miejsce to jest mój kanał na YouTubie, który zacząłem jakiś czas temu rozwijać. Trochę to przerwałem ze względu na brak zainteresowania, ale może do tego wrócę. On się nazywa Nostalgia Tech Lounge i tam trochę opowiadam o minionej epoce, powiedzmy o takich nostalgicznych czasach, dla mnie przynajmniej, lata 90. i jak komputery wtedy wyglądały. Tak więc takie dwa miejsca polecam, gdzie można by zajrzeć i troszeczkę więcej ode mnie się dowiedzieć.

 

Sam z chęcią zerknę. Oczywiście linki będą w tle do odcinka. 

Krzysztof, jeszcze raz bardzo Ci dziękuję. Do usłyszenia i cześć. 

 

Dziękuję. Do usłyszenia.

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o licencjach open source z punktu widzenia programisty komercyjnego. 

Do usłyszenia w następnym odcinku!

Cześć!