#3 — Piwo za software, czyli licencje na oprogramowanie

W tym odcinku poznasz podstawowe pojęcia ze świata praw autorskich i licencji związanych z oprogramowaniem. Uwaga! Nie jestem prawnikiem, więc przed zastosowaniem się do przedstawianych porad, skonsultuj się z leka...no, z prawnikiem, aby przeanalizować bieżący stan prawny :).

💡
Spodobał Ci się ten odcinek? Zasubskrybuj mój podcast na swojej ulubionej platformie i podziel się nim ze znajomymi!

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 3. „Piwo za software, czyli licencje na oprogramowanie”. W tym odcinku poznasz podstawowe pojęcia ze świata praw autorskich i licencji związanych z oprogramowaniem. Zaznaczam przy tym, że sam nie jestem prawnikiem. Moje objaśnienia należy traktować zdecydowanie praktycznie. Opieram się tutaj na własnych doświadczeniach, na różnych sytuacjach, w których wybieraliśmy, dobieraliśmy oprogramowanie, właśnie zwracając uwagę na licencje. Natomiast przy realizacji własnych działań czy to tworzenia oprogramowania w oparciu o zewnętrzne komponenty na różnych licencjach, czy też w przypadku doboru gotowego oprogramowania zawsze warto skonsultować się ze specjalistą, specjalistką w zakresie prawa cywilnego, najlepiej oczywiście prawa dotyczącego licencji, wszelkich praw autorskich. Tutaj warto pamiętać w szczególności, że nawet jeżeli moje rozważania w tym odcinku są w pełni prawdziwe, w pełni prawidłowe, to są one nagrywane na początku 2022 roku i w przyszłości pewne założenia dotyczące licencji, jak to się mówi, stan faktyczny, stan prawny mogą po prostu ulec zmianie. Także warto zawsze skonsultować się ze specjalistą. Skoro mamy już z głowy ten disclaimer, można powiedzieć, to zastrzeżenie, to możemy przejść już do meritum.

Kiedy ktokolwiek chce skorzystać z oprogramowania, to konieczna jest jakaś podstawa prawna, na bazie której możliwy jest dostęp, możliwe jest użycie takiego oprogramowania. Trochę inaczej to wygląda w takim, można powiedzieć, zwykłym przypadku, czyli w przypadku rzeczy materialnych wymieniamy pieniądze za dostęp do jakiejś rzeczy czy za możliwość posiadania na przykład samochodu czy też mieszkania. W przypadku oprogramowania jest trochę trudniej, bo oprogramowanie praktycznie znikomym kosztem można kopiować w nieskończoność. Częsty argument piratów internetowych właśnie jest taki, że przecież kopiowanie filmów, muzyki czy innych dóbr cyfrowych to nie to samo, co kradzież samochodu. Oryginalny właściciel nie traci swojej kopii. Przy czym mówię tutaj o właścicielu egzemplarza książki, a nie autorze całej publikacji, na przykład. Wiąże się z tym taka zabawna historia, kiedy chodziłem jeszcze do liceum i napisałem pierwszą książkę na temat programowania. I zgłosił się do mnie kolega po autograf, co oczywiście było bardzo miłe, natomiast niestety nie miał oryginalnego egzemplarza książki z księgarni, tylko – no cóż – miał po prostu wydruk kopii, nie wiem, czy skserował, czy pobrał gdzieś z Internetu. Była to dość niezręczna sytuacja. Zrobiłem wtedy taką minę, jaką uwieczniłem na zdjęciu wrzuconym na nasz podcastowy Instagram. Nie było to ciekawe doświadczenie.

Natomiast wracając do meritum – jeżeli chcemy skorzystać z jakiegokolwiek oprogramowania, to można powiedzieć, że mamy takie dwie zasadnicze opcje. Możemy oprogramowanie nabyć, uzyskać do niego prawa autorskie, prawa autorskie majątkowe, bądź też nabyć licencję. Oczywiście autorskie prawa majątkowe jest to potężna armata wręcz i bardzo często nie ma sensu jej stosować. Prawa autorskie majątkowe mają duże znaczenie dla start-upów czy też dla innych organizacji, które po prostu potrzebują oprogramowania na własność. Samo użycie oprogramowania nie wymaga z reguły posiadania praw autorskich. Co innego, jeżeli to oprogramowanie właśnie chcemy mieć na własność. Jeżeli podpisywaliście kiedykolwiek umowę o dzieło, tak naprawdę o jakiekolwiek dzieło bądź w ostatnich latach nawet umowy zlecenia z przekazaniem praw autorskich, to na pewno znajdziecie tam taki z reguły mocno niepasujący do reszty umowy paragraf, w którym wytwór waszej pracy jest przekazywany w dość taki obszerny sposób, czyli tak zwane pola eksploatacji są z reguły określane, związane między innymi z prawami do powielania, reprodukcji, dystrybucji treści czy po prostu wytworów waszej pracy. Natomiast, umówmy się, prawa majątkowe dotyczą własności. Jeżeli chcemy na przykład skorzystać z Windowsa, no to nie próbujemy nabyć do niego praw majątkowych, bo kosztowałoby to pewnie miliardy dolarów. W związku z tym zdecydowanie częstszym przypadkiem, zwłaszcza kiedy po prostu chcemy skorzystać z jakiejś aplikacji, jest zakupienie licencji na użycie takiego oprogramowania. Myślę, że każdy, kto korzystał z jakichkolwiek aplikacji, czy to stacjonarnych, czy mobilnych, przynajmniej raz w życiu akceptował taką umowę licencyjną. One pojawiają się chociażby też w programach biurowych, też w grach, jeżeli mamy zwłaszcza jakieś też usługi sieciowe. Często nazywa się to „End User’s Licence Agreement”, czyli EULA. Tak w skrócie. Nawet są memy, żarty w sieci, jak to wszyscy bardzo szybko potrafią w ciągu kilku sekund zapoznać się z taką EULĄ. No, oczywiście w praktyce mało kto je czyta, a teoretycznie powinno się to robić, tylko z reguły klikamy „dalej”, „akceptuję”, „zainstaluj jak najszybciej to oprogramowanie”. Wbrew pozorom, gdyby wczytać się w postanowienia takich umów licencyjnych, to mogłoby się okazać, że nawet niektóre przypadki stosowania czy to gier, czy programów, które wydaje się, że możemy robić, możemy realizować, po prostu nie są dopuszczalne. Na przykład kwestia pożyczania oprogramowania, udostępniania, no, jeżeli byśmy chcieli w jakiś odpłatny sposób, to już podejrzewam, w ogóle byłoby to zabronione. Dlatego mimo wszystko radzę czytać umowy licencyjne. Nawet w przypadku takich programów, usług gotowych, aby w razie czego po prostu być krytym.

Tak że podsumowując tę część dzisiejszego odcinka. Jeżeli chcemy po prostu korzystać z oprogramowania, to praktycznie zawsze będziemy mieli do czynienia z jakąś licencją. I tutaj sytuacja jest z reguły dość prosta, ponieważ w przypadku takich masowych, masowo dostępnych usług, programów czy różnego rodzaju innych aplikacji, samo oprogramowanie będzie chronić nas, no a raczej tak naprawdę twórców tychże usług przed zbyt intensywnym korzystaniem z nich, przed przekraczaniem pozwoleń, które daje nam licencja. Dobrym przykładem jest tutaj chociażby NETFLIX. W zależności od rodzaju licencji mamy możliwość korzystania z niego na kilku urządzeniach. No i jeżeli będziemy próbowali zainstalować, odtworzyć treść na jeszcze kolejnym urządzeniu, które przekracza limit, to powinniśmy zobaczyć wtedy ostrzeżenie, informację, że nie jest to możliwe, trzeba wylogować się na innym urządzeniu.

W przypadku oprogramowania biznesowego, oprogramowania klasy enterprise, modele licencyjne są z reguły bardziej skomplikowane, tak że tutaj zdecydowanie już warto zapoznać się z licencją, zwłaszcza że też konsekwencje złamania takiej licencji są z reguły znacznie poważniejsze. Warto zaangażować zarówno swoich prawników, jak i prawników drugiej strony, czyli firmy sprzedającej takie rozwiązania, aby mieć pewność, że zakupiona licencja pozwala na nasze przypadki użycia, na ich osiągnięcie, na ich realizację.

Druga sytuacja, z mojego punktu widzenia nieco ważniejsza właśnie również od strony prawnej, to taka, w której tworzysz rozwiązanie informatyczne od zera bądź też korzystasz z gotowych zewnętrznych komponentów, różnego rodzaju bibliotek frameworków. I tak jak wspominałem w odcinku pierwszym „Software szyty na miarę, czy gotowy”, dzięki takim zewnętrznym zależnościom nie musimy jakby martwić się o tworzenie aplikacji od zera, co jest z reguły dużo bardziej czasochłonne, a co za tym idzie, również i kosztochłonne. Możemy korzystać na przykład z fajnych opracowanych już przez innych elementów interfejsu użytkownika, mechanizmów do pobierania danych z Internetu. Są to takie, można powiedzieć, gotowce, klocki czy – ulubione przeze mnie słowo – prefabrykaty, z których można skorzystać. Natomiast pomijając techniczną możliwość zastosowania takich rozwiązań, trzeba się upewnić, że nie ma przeciwskazań prawnych. Tak naprawdę, niezależnie od tego, czy masz zespół wewnątrz firmy, czy też jakąś ekipę zewnętrzną, należy mieć pewność, że wszystkie te zewnętrzne komponenty, które są używane w twoim rozwiązaniu, są używane zgodnie z licencją. W przeciwnym razie może się to skończyć nieprzyjemnymi konsekwencjami, przede wszystkim związanymi z dodatkowymi kosztami naruszenia licencji, ale także nawet – w skrajnych przypadkach – koniecznością ujawnienia całego kodu twojego rozwiązania, co oczywiście jest niezwykle potencjalnie niebezpieczne.

W świecie licencjonowania mamy tak naprawdę do czynienia z dwoma głównymi rodzajami licencji. Licencjami komercyjnymi, płatnymi, czyli takimi, w których założenia licencji określa producent oprogramowania czy też usługi. No i tutaj to tak naprawdę po jego stronie leży kwestia przedstawienia ci wszystkich założeń, ustalenia z tobą, czy model licencyjny zaproponowany przez tego producenta jest dla ciebie w porządku. Tak więc jeżeli chcesz nabyć dostęp do jakiejś usługi, która jest po prostu płatna, do oprogramowania, które jest dostępne na licencji komercyjnej, no to po prostu trzeba odwołać się do reguł gry, do regulaminów, umów, które udostępnia ten producent. Od siebie dodam, że tak na wszelki wypadek warto mieć potwierdzenie tego rodzaju ustaleń na piśmie, zwłaszcza, jeżeli na przykład uda nam się wynegocjować rozszerzenie licencji czy bardziej korzystne zapisy, bo czasami producenci się na to zgadzają. Warto mieć to najlepiej w jakiejś formie pisemne, ale chociaż potwierdzenie przed odpowiednio umocowaną prawnie osobę w mailu. To zawsze w razie czego jest pewien plus. Natomiast oprogramowanie komercyjne to jest trochę inny świat, a to, na co na pewno trzeba uważać, co daje bardzo dużo możliwości, ale niesie też pewne ryzyko, to oprogramowanie otwarte, oprogramowanie wolne, czyli tak zwany open source software czy też free software. Różnica pomiędzy obydwoma pojęciami jest w zasadzie bardziej natury akademickiej, według twórcy, Richarda Stallmana, jednego – powiedzmy – z twórców otwartego oprogramowania, wolnego oprogramowania, wolne oprogramowanie jest bardziej koncepcją filozoficzną, podejściem do oprogramowania jako wartości dla ludzkości i wolność oprogramowania ma zapewnić korzyści dla nas, właśnie jako dla ludzkości. Natomiast otwarte oprogramowanie jest bardziej, tutaj od strony technicznej, inicjatywą, która ma pozwalać różnym ludziom z całego świata rozwijać wspólnie oprogramowanie, które jest publiczne dostępne, którego kod jest publicznie dostępny. Natomiast powiedzmy, że póki nie dyskutujemy bardzo o niuansach, to są to pojęcia w zasadzie tożsame. No i tutaj warto też zauważyć, że pojęcie znane na przykład z mediów cyfrowych, z innych mediów, pojęcie domeny publicznej jest rzadko używane w kontekście oprogramowania. Można się z tym spotkać, ale raczej, jeżeli myślimy o takim oprogramowaniu, które jest powszechnie dostępne, to mówimy raczej o oprogramowaniu wolnym czy też otwartym.

Świat licencji otwartych jest niezwykle złożony. Na samej Wikipedii znajdziecie kilkadziesiąt przykładów różnych licencji. Co więcej, jedna licencja potrafi mieć też kilka wersji, niczym oprogramowanie. Muszę przyznać, że świat licencji, zwłaszcza tych otwartych, musi być dla prawników takim specyficznym wyzwaniem, ponieważ prawda jest taka, że wiele spośród tych licencji było pisanych bardziej czy przez informatyków, czy z inicjatywy informatyków, a prawnicy muszą sobie gdzieś z tym radzić. Natomiast nie zagłębimy się oczywiście tutaj w niuanse wszystkich tych licencji. Ja chciałbym przede wszystkim wspomnieć o dwóch zasadniczych rodzajach licencji otwartych, czyli tak zwanych licencjach permisywnych i licencjach copyleft, ponieważ ten podział licencji otwartych, te dwie takie najważniejsze grupy, mają kluczowe znaczenie w przypadku analizy tego, czy dana licencja mocno wpłynie na nasze oprogramowanie, czy też nie. Nie da się ukryć, że jedną z największych zalet oprogramowania otwartego jest to, że jest ono po prostu darmowe. Nie jest to co prawda tak naprawdę warunek konieczny, ale jak się za chwilę przekonamy, trudno od tego uciec. Tak że z oprogramowaniem na licencji właśnie takiej otwartej po prostu jest łatwiej robić biznes, bo ono teoretycznie, przynajmniej w tym podstawowym zakresie, nic nie kosztuje. Brak kosztów i fakt, że to oprogramowanie jest darmowe nie oznacza jednak, że możemy robić z nim cokolwiek. Na szczęście istnieje grupa licencji, właśnie licencji permisywnych, czyli jak sama nazwa wskazuje, takich dość liberalnych, według których możemy rozpowszechniać i modyfikować oprogramowanie w dowolnym zakresie. One tak naprawdę nakładają jeden bardzo łatwy do spełnienia warunek. Musimy dołączyć do naszego oprogramowania informację o tym, kto faktycznie dany komponent, daną bibliotekę czy po prostu dane oprogramowanie stworzył. Natomiast to oczywiście jest bardzo niewielkie, bardzo drobne wymaganie do spełnienia. W takiej licencji znajdziemy też z reguły informację o braku przeniesienia ewentualnych roszczeń na twórcę oprogramowania. No, trzeba przyznać, że ktoś, kto skorzystałby z oprogramowania darmowego i chciałby takie roszczenia wnosić, no, byłoby to bardzo – moim zdaniem – nieeleganckie zachowanie. Do licencji permisywnych zaliczamy na przykład licencje BSD, MIT i Apache. Jeżeli więc w oprogramowaniu czy w jakimś komponencie znajdziesz taką właśnie licencję, to w zasadzie nie ma się o co obawiać, jesteś w domu. Drugą grupą licencji są licencje copyleft, czyli licencje wywodzące się od licencji GPL. I tutaj sytuacja robi się już o wiele bardziej skomplikowana. W oryginalnym założeniu licencja GPL, której najpopularniejszą wersją jest wersja 3., działa po prostu jak wirus. Jeżeli w swoim oprogramowaniu, dajmy na to, komunikatorze internetowym, skorzystasz choćby z małego mechanizmu, na przykład do szyfrowania danych, który jest objęty licencją GPL, to niestety, całe twoje oprogramowanie, czyli w tym przypadku cały komunikator, powinien też być opublikowany na licencji GPL. To jest ten aspekt wirusowy. No dobrze, ale co to oznacza w praktyce. Otóż licencja GPL zakłada, że jeżeli udostępniamy komuś oprogramowanie, to wraz z tym oprogramowaniem musimy dostarczyć kod całej aplikacji. Taki użytkownik, który otrzyma kopię zarówno naszej aplikacji gotowej do uruchomienia, jak i kodu, może dalej udostępnić cały komplet, no i krótko mówiąc, rozprzestrzeniać w ten sposób aplikację w sposób wirusowy. W tym momencie łatwo też widać, dlaczego oprogramowanie otwarte nie jest sprzedawane jako takie. Zwróćmy uwagę, że formalnie nikt tego nie broni, ale jeżeli byśmy sprzedali taki program na licencji GPL, to w zasadzie pierwsza osoba, która by kupiła ten program od nas po jakiejś tam komercyjnej stawce, mogłaby dalej zupełnie za darmo, zupełnie bez przeszkód i bez konsekwencji prawnych udostępniać go każdemu, kto o to poprosi. No, nie byłby to dobry model biznesowy, bo mielibyśmy de facto jednego płatnego użytkownika. Czy to oznacza, że nie można użyć takiej licencji w oprogramowaniu komercyjnym? No nie do końca, bo jeżeli tworzymy oprogramowanie dla zamkniętej grupy użytkowników i żadnemu z tych użytkowników nie będzie zależeć na dalszej dystrybucji, to teoretycznie jest to sytuacja w miarę bezpieczna. Natomiast należy pamiętać, że wystarczy jedna osoba, która tego wirusa – można powiedzieć – wypuści. Tutaj warto przywołać taki przykład. Robiliśmy bowiem kiedyś oprogramowanie z wykorzystaniem biblioteki, w której jedną z opcji, bo to też warto podkreślić, że to samo oprogramowanie może być udostępniane na różnych licencjach w zależności od technicznych i formalnych uwarunkowań. Korzystaliśmy z biblioteki, które miała jedną z opcji udostępnienia na licencji właśnie GPL, tej wirusowej, no i oczywiście gdybyśmy poszli tą drogą i korzystali z licencji GPL, to musielibyśmy przekazać klientowi kod. Oczywiście ten klient i tak dostał dostęp do kodu, bo chciał uzyskać prawa majątkowe, więc to nie był problem, natomiast tutaj gdyby ten klient w pewnym momencie postanowił chociaż jednej osobie udostępnić aplikację na licencji GPL, to niestety to oprogramowanie mogłoby wypłynąć szerzej w świat. Na szczęście w tym projekcie nie musieliśmy korzystać z licencji GPL, tylko z takiej – no, można powiedzieć nieco bardziej elastycznej wersji, nazywanej Lesser GPL, czyli tak zwane LGPL. Ta licencja zakłada, że jeżeli mamy już taki składnik, na przykład w tym momencie w tym przykładzie używaliśmy tutaj pewnego komponentu do szyfrowania danych, to nie musimy na szczęście rozpowszechniać całej naszej aplikacji, całego naszego komunikatora wraz z pełnym kodem źródłowym. Jedyne, co musimy zrobić, to jeżeli my usprawnilibyśmy działanie komponentu szyfrującego, to wtedy musielibyśmy faktycznie dalej udostępniać go każdemu zainteresowanemu użytkownikowi. Ta licencja LGPL wymaga też, aby ten komponent, z którego chcemy skorzystać, był odrębną częścią aplikacji. Tak że to już są takie techniczne pewne uwarunkowania, które jednakowoż z reguły można spełnić. Dlatego jeżeli spotykamy się z licencjami GPL-owskimi, to zdecydowanie warto pochylić się nad tym, czy mamy do czynienia z GPL, czy z LGPL, bo jest to ogromna różnica.

Zwróćmy jeszcze uwagę na jedną rzecz. Licencje GPL-owskie, te, które przed chwilą omówiłem, powstawały pod koniec lat 80., w latach 90. To był taki chyba najbardziej intensywny okres ich rozwoju. Natomiast one były dopasowane do realiów tamtych czasów. Aplikacje rozpowszechniało się w formie zestawu plików czy to na płycie, czy czasem przez rozpowszechniający się wtedy Internet, więc sytuacja była jasna. Chcieliśmy mieć Worda na komputerze, instalowaliśmy go z płyty i to był tak naprawdę zestaw plików na naszym lokalnym komputerze. Natomiast tutaj zauważmy, że obecnie często z aplikacji korzystamy na przykład za pomocą przeglądarki internetowej. To jest nieco inna sytuacja, ponieważ użytkownik takiej aplikacji nie otrzymuje kompletu plików. Otrzymuje tylko pewną część, uruchamianą w przeglądarce. Dobrym przykładem jest tutaj oprogramowanie Moodle, również takie, które my czasem wdrażamy u naszych klientów, które też jest na licencji GPL. Instalujemy więc takie oprogramowanie na serwerze naszych klientów i choć taki klient zgodnie z licencją GPL może sobie te pliki Moodla wziąć i wysłać komu chce, to oczywiście nie ma takiego obowiązku. Natomiast użytkownicy Moodla, czyli studenci, kursanci, korzystający z tej platformy e-learningowej nie muszą otrzymać kopii plików. Jest to niezwykle istotne, bo po prostu komunikacja odbywa się przez Internet. Tak naprawdę użytkownicy korzystają z efektów pracy aplikacji, a nie z samej aplikacji. To jest już taka kwestia mocno techniczna, natomiast de facto nie musimy udostępniać wszystkim użytkownikom całego Moodla.

Natomiast oczywiście zauważono ten problem w świecie otwartego oprogramowania i aby go rozwiązać powstała licencja Affero GPL, czyli w skrócie AGPL, która krótko mówiąc, nakazuje udostępnianie oprogramowania objętego tą licencją również użytkownikom, którzy korzystają chociażby z przeglądarki internetowej. Tak że jeżeli mamy do czynienia z AGPL-em, to jest to ta sytuacja bardziej restrykcyjna. To samo dotyczy klasycznego GLP-a. Natomiast w przypadku stosowania licencji LGPL w oprogramowaniu, jesteśmy raczej w dobrej sytuacji. Warto tutaj jeszcze zwrócić uwagę na problem aplikacji mobilnych, takich instalowanych w telefonach. No bo niestety one łapią się niejako pod ten paradoksalnie starszy przypadek, czyli ten przypadek z lat 90. Użytkownik de facto otrzymuje pliki aplikacji, więc jeżeli korzystamy z jakichś plików na licencji GPL, no to niestety musimy udostępniać kod źródłowy użytkownikom. To też jest pewien problem.

Kilka wymienionych licencji oczywiście nie wyczerpuje w żadnym razie tematu, choć nie da się ukryć, że wspomniane licencje należą do najpopularniejszych licencji ze świata Open Source. Z pewnością jest duża szansa, że w waszej codziennej pracy spotkacie się z różnymi innymi przykładami licencji, chociażby ze wspomnianą w tytule licencją związaną z piwem, czyli tak zwane Beerware, która na marginesie jest dość permisywną, liberalną licencją, można robić w zasadzie to, co się chce. Jakby jedynym, można powiedzieć, warunkiem, jest to, że jeżeli oprogramowanie uznacie za przydatne, to w przypadku spotkania autora danego oprogramowania należy postawić mu piwo, co oczywiście jest pewnego rodzaju żartem. Natomiast dość dobrze pokazuje, jak różnorodne licencje można spotkać w świecie oprogramowania.

Przechodząc do podsumowania odcinka, nie da się ukryć, że temat ten można rozszerzyć na wiele sposobów. Możemy omówić kwestie licencji na prace kreatywne, licencji, które z reguły są związane z grupą Creative Commons, jeżeli w różnego rodzaju pracach korzystasz z różnego rodzaju grafik, zdjęć z Wikipedii, to licencja CC i różnego rodzaju pokrewne, bardzo często tam występują. Są firmy i start-upy, jak chociażby Vue Storefront, które na rozwoju oprogramowania Open Source, na tej całej koncepcji zbudowały całkiem ciekawy model biznesowy. Na pewno w przyszłości będę chciał rozwinąć ten temat i myślę, że idealnie nadawać będzie się do tego również jakaś druga osoba zaproszona, więc jestem bardzo ciekawy waszych opinii, w którą stronę dalej pójść z tym tematem.

Na dziś już kończymy. Kolejny odcinek jak zawsze za dwa tygodnie. Zapraszam do zapoznania się z naszymi kanałami social media, gdzie chociażby na wspomnianym już Instagramie znajdziecie fotkę z kręcenia tego odcinka. Pozdrawiam i do usłyszenia.