Gdyby nie rozwiązania open source, to świat IT wyglądałby zupełnie inaczej. Otwarte oprogramowanie to istotny czynnik, który pcha rozwój cyfrowej rzeczywistości do przodu. A tam gdzie coś pełni ważną rolę, tam pojawiają się problemy prawne. Czy naprawdę można z tego korzystać? W jaki sposób? Co trzeba zrobić żeby było dobrze? Pytań o korzystanie z rozwiązań open source w kontekście spełnienia wymogów prawnych i tworzenia komercyjnego oprogramowania, trafia do mnie dość sporo.
Stwierdziłem więc, że opiszę jak korzystanie z otwartego oprogramowania wygląda z perspektywy prawnej. Piszę jak wygląda korzystanie z różnych elementów open source, takie jak gotowe aplikacje, kod źródłowy, frameworki czy biblioteki z perspektywy wykorzystania w tworzeniu rozwiązań IT w Polsce i Europie– tak aby polski programista mógł z tego po prostu skorzystać.
Co trzeba wiedzieć wykorzystując rozwiązania open source?
Co to w ogóle znaczy, że program jest open source?
Zacznijmy od podstawowej kwestii, czyli tego, że nie każdy kod źródłowy, który znajdujemy w publicznym miejscu (np. w jakimś repozytorium w Internecie) możemy uznać za rozwiązanie open source. Sam fakt udostepnienia kodu lub opublikowania go nie przesądza jeszcze o tym, że można z niego dowolnie korzystać. Z punktu widzenia przepisów dot. praw autorskich jest dokładnie odwrotnie – opublikowany i rozpowszechniony utwór jest nadal chroniony, a decydowanie o tym jak można go wykorzystać generalnie stanowi uprawnienie autora (albo innego podmiotu, który jest właścicielem majątkowych praw autorskich) - z małymi wyjątkami, wynikającymi z przepisów prawa.
Pamiętaj, że to, że coś technicznie się da zrobić (np. skopiować kod z jednego rozwiązania do drugiego) nie oznacza od razu, że jest to prawnie dozwolone. Dotyczy to również gotowych rozwiązań – to, że coś pobraliśmy za darmo z Internetu nie oznacza, że to jest open source.
Dlatego ważne jest aby wskazać, co to znaczy, że coś jest rozwiązaniem opartym o licencję open source. W praktyce większość osób, które mówi "oprogramowanie open source" ma na myśli potoczne rozumienie tego zwrotu, które obejmuje mniej więcej to, że:
kod źródłowy oprogramowania jest publicznie dostępny,
można wykorzystywać to oprogramowanie w swoich celach i się nim dzielić,
można to oprogramowanie modyfikować i dostosowywać do swoich potrzeb.
I te rzeczy muszą wynikać z licencji dotyczącej danego programu - innymi słowy musi być jakaś licencja, która wskazuje na możliwość tak szerokiego wykorzystania kodu.
W teorii sytuacja się nieco komplikuje, bo na świecie mamy do czynienia z różnymi "filozofiami" tworzenia otwartego oprogramowania i podziałem na free software (wolne oprogramowanie) i open source software (otwarte oprogramowanie, tzn. takie, którego kod źródłowy jest dostępny). W największym skrócie:
oprogramowanie open source to takie oprogramowanie, gdzie użytkownicy mogą badać udostępniony kod źródłowy, a przy okazji mogą go też zmieniać i rozpowszechniać oprogramowanie zgodnie z licencją open source,
wolne oprogramowanie ma taką dodatkową cechę, że "promuje" wolność tworzenia oprogramowania. Jest więc nie tylko sposobem tworzenia, ale całą filozofią jego dystrybucji i udostępniania ludziom. Zakłada, że każde oprogramowanie powinno być właśnie free source. Jest więc nieco bardziej radykalnym ruchem niż samo open source, bo jego celem jest również dalsze rozpowszechnianie wolnego oprogramowania. Open source koncentruje się natomiast na samym sposobie tworzenia programów, który zakłada udostępnianie kodu źródłowego.
W praktyce większość najpopularniejszych licencji spełnia założenia obu ruchów, a różnice są niewielkie. Zdarza się jednak, że niektóre licencje spełniają założenia open source, a nie są free source.
Zbiorczo te ruchy nazywa się często FOSS (free and open-source software) albo FLOSS (free/libre and open-source sotware). Nie będę tu rozstrzygał filozoficznych dysput dotyczących różnic pomiędzy free a open. Napiszę po prostu czego się wystrzegać w projektach komercyjnych i pracy dla klientów, którzy chcą uzyskać licencję albo nabyć autorskie prawa majątkowe do programu.
Z uwagi na to, że open source to pojęcie nieco szersze niż free source, będę tu odnosił się głównie do tego pierwszego zwrotu.
Jak zgodnie z prawem korzystać z open source?
Skoro już wiemy, co to jest open source i wiemy, że open source oznacza oprogramowanie posiadające jakąś licencję, możemy ustalić w jaki sposób możemy zgodnie z prawem korzystać z takiego oprogramowania. Dlatego też musimy się zastanowić nad tym:
w ramach jakiego projektu (rozwiązania) chcemy wykorzystać oprogramowanie open source,
co z tym rozwiązaniem będziemy robić - zwłaszcza jeśli chcemy je wykorzystywać komercyjnie.
Oczywiście nie napotkamy żadnego większego problemu, jeżeli po prostu korzystany z oprogramowania open source jako zwykły użytkownik - tzn. wykorzystujemy je zgodnie z intencją twórców. Mamy zresztą dużo popularnych programów, które są właśnie na licencjach open source i wielu ludzi z nich korzysta – Mozilla Firefox/Thunderbird, systemy operacyjne GNU/Linux itp. Po prostu korzystamy z nich jako uprawnieni użytkownicy (zgodnie z przeznaczeniem) i tyle – licencje na to pozwalają.
Nieco inna sytuacja ma miejsce gdy na bazie różnych rozwiązań open source my tworzymy nasz własny produkt. To bardzo powszechne, biorąc pod uwagę fakt, że duża część bibliotek, frameworków oraz innych elementów, na podstawie których tworzy się oprogramowanie, jest rozpowszechniana w oparciu o jakąś licencję FOSS.
Generalnie, jeżeli nasz projekt zakłada stworzenie czegoś na potrzeby własnego użytku domowego, na nasze potrzeby osobiste, to nie napotkamy zbyt wielu problemów. Podobnie będzie jeżeli zamierzamy korzystać z rozwiązań open source po to aby przyczynić się do rozwoju jakiegoś udostępnionego na takiej licencji programu i wesprzeć tworzenie wolnego/otwartego oprogramowania naszą wiedzą i umiejętnościami koderskimi. Z reguły najważniejsze w takiej sytuacji będzie po prostu to, że nasz kod zostanie opublikowany i stanie się częścią "większego dzieła" - o co i tak nam w gruncie rzeczy chodzi.
Sprawy nieco komplikują się, jeżeli chcemy tworzyć na bazie oprogramowania open source coś z czego będziemy korzystać komercyjnie. Dotyczy to np. sytuacji gdy my tworzymy coś co będzie wykorzystywane w ramach organizacji dla której pracujemy (np. Spółki, w której jesteśmy zatrudnieni) albo zostanie sprzedane (przeniesiemy autorskie prawa majątkowe) lub licencjonowane na rzecz naszego klienta.
Tu bowiem niektóre licencje FOSS mogą niestety okazać się pułapką, która uniemożliwi komercjalizację finalnego rozwiązania. Dlatego powinniśmy zweryfikować kwestie licencyjne przed rozpoczęciem projektu. Oczywiście, w praktyce nikt nie zaczyna szukania rozwiązań technologicznych, na których można oprzeć produkt dla klienta od lektury postanowień licencyjnych – niemniej jednak warto tę kwestię również mieć na uwadze. Od razu zastrzegam, że najpopularniejsze biblioteki z reguły mają "właściwe" licencje, które umożliwiają ich komercyjne zastosowanie, pod warunkiem spełnienia kilku, niezbyt skomplikowanych warunków.
Sprawdźmy czego dokładnie dotyczy nasza licencja FOSS?
Zdarza się tak, że decydując się na skorzystanie z określonej technologii, nie mamy do czynienia z jedną licencją, a z kilkoma. Siłą rzeczy, takie rozwiązanie może być bowiem złożone z różnych pomniejszych utworów programistycznych, które mają kilku autorów. Praktyka tworzenia oprogramowania open source bywa bowiem taka, że różne elementy są często zależne od siebie i aby skorzystać z jednego programu, musimy tak naprawdę wykorzystać kilka (albo nawet kilkadziesiąt) rozwiązań od kilku różnych twórców. A te mogą bazować na różnych licencjach.
Dla ułatwienia powiem, że licencje te są z reguły ze sobą kompatybilne, więc nie będziemy musieli się specjalnie nad tym głowić - ale musimy o tym wiedzieć np. informując o tym jakie rozwiązania wykorzystaliśmy w naszym finalnym produkcie (o czym poniżej).
Jakie licencje FOSS są najpopularniejsze?
Jak wspomniałem, licencji FOSS jest mnóstwo. Niemniej jednak, na szczęście, kilka z nich zdecydowanie dominuje. W dodatku są one ze sobą kompatybilne. To bardzo dobra wiadomość - jeżeli trafimy na jakieś rozwiązanie open source, to z dużym prawdopodobieństwem będzie ono oparte o licencję, którą już znamy.
MIT license/X11 – licencja bardzo popularna, a przy tym prosta, przyjemna i mocno kompatybilna z innymi. Generalne założenia są takie - rozwiązania oparte o tę licencję można wykorzystywać, modyfikować, pobierać, rozpowszechniać i wykorzystywać w celach komercyjnych (również w takich z zamkniętym kodem źródłowym). Warunkiem jest zamieszczenie tekstu licencji i informacji o prawach autorskich w ramach finalnego dzieła. Można wykorzystywać rozwiązania oparte o licencję MIT w takich programach, które same będą oparte o inną licencję.
Popularne rozwiązania oparte o tę licencję: Node.js, React, Vue.js, .NET
Apache License 2.0. - kolejna liberalna i popularna licencja. Rozwiązania, które są o nią oparte, można bez przeszkód kopiować, dystrybuować, wykorzystywać komercyjnie i modyfikować. Można je wykorzystywać również w rozwiązaniach z zamkniętym kodem źródłowym. Trzeba jednak zamieścić tekst licencji Apache oraz informację o prawach autorskich (o autorze), ewentualnych znakach towarowych i patentach. Dodatkowo, jeżeli w ramach opartego o licencję Apache rozwiązania, wprowadziliśmy jakieś zmiany, powinniśmy zamieścić odpowiedni changelog i je opisać, wraz ze wskazaniem autora modyfikacji . Co więcej, jeżeli wykorzystane przez nas rozwiązanie, oparte o licencję Apache, zawiera plik notice, to taki plik również powinien być zamieszczony. Ta licencja obejmuje również rozwiązania oparte o patenty - jeżeli więc jakaś część oprogramowania jest chroniona patentem (np. w USA, bo w UE patenty na oprogramowanie to nieczęsta sprawa) to licencja Apache też umożliwia wykorzystanie takiej części.
Popularne rozwiązania oparte o tę licencję: Kubernetes, Apache http server, Typescript
BSD-3 clause – licencja Berkeley Software Distribution, która ma 3 postanowienia (są też podobne wersje z 4, 2 albo nawet 0 postanowieniami). Liberalna, prosta i kompatybilna z innymi. Oprogramowanie, które jest o nią oparte może być wykorzystywane, modyfikowane i rozpowszechniane. Można je wykorzystywać w ramach projektów komercyjnych i nie wymaga udostępniania kodu źródłowego - tzn. można je wykorzystywać w ramach zamkniętego oprogramowania. Musimy jedynie zamieścić informacje o o prawach autorskich i treść licencji. Można wykorzystywać rozwiązania oparte o licencję BSD-3 w takich programach, które same będą oparte o inną licencję.
Popularne rozwiązania oparte o tę licencję (albo o inne, podobne licencje BSD): system operacyjny FreeBSD, Flask, Nginx, Chromium (nie wszystko)
Licencje Creative Commons
W powszechnym użyciu są też licencje creative commons. To specjalne licencje, które umożliwiają publiczne wykorzystanie utworów, które są nią objęte. Zaznaczam tu, że publiczne wykorzystanie nie oznacza wykorzystania dowolnego i niektóre licencje creative commons mogą odnosić się tylko do szczególnych rodzajów zastosowań (np. niekomercyjnego). Licencje creative commons są często stosowne do utworów takich jak zdjęcia, grafiki, ikony, teksty, filmy, dźwięki itp. - w niektórych przypadkach mogą dotyczyć również oprogramowania komputerowego (choć nie jest to zalecane).
Ich zaletą jest to, że są bardzo proste i przejrzyste - dzięki temu twórca może bezproblemowo wybrać licencję, która będzie zawierała odpowiadające mu zasady. Następnym krokiem jest po prostu rozpowszechnienie utworu, a wybrana licencja będzie do niego się stosować. Opisy licencji są bardzo skrótowe i składają się z pojedynczych liter - można je więc umieścić pod zdjęciem
CC0 – ta licencja umożliwia wykorzystywanie i rozpowszechnianie utworu bez jakichkolwiek ograniczeń - w tym również komercyjnie. Można taki utwór modyfikować. Nie wymaga podawania danych autora (albo innego podmiotu, któremu przysługują prawa autorskie),
CC-BY – tak samo jak powyżej, licencja umożliwia dowolne rozpowszechnianie i wykorzystywanie, również komercyjne. Konieczne jest jednak podanie danych autora. Modyfikowanie utworu jest dozwolone,
CC-BY-SA – licencja umożliwia wykorzystywanie i rozpowszechnianie, również komercyjnie. Konieczne jest podanie danych autora. Ewentualne modyfikacje są dozwolone o ile będą rozpowszechnione pod taką samą licencją (albo bardziej restrykcyjną),
CC-BY-SA-NC licencja umożliwia wykorzystanie i rozpowszechnianie, ale tylko niekomercyjnie. Koniczne jest podanie danych autora. Modyfikowanie jest dozwolone pod warunkiem rozpowszechnienia ich pod tą samą albo bardziej restrykcyjną licencją.
Mając to na uwadze, łatwo już ustalić co oznaczają poszczególne literki:
CC - ogólne określenie licencji creative commons - można wykorzystywać i rozpowszechniać dzieło,
BY – konieczne jest podanie danych autora,
SA – modyfikowanie jest dozwolone pod warunkiem rozpowszechnienia jej pod taką samą albo bardziej restrykcyjną licencją,
NC – wykorzystanie jest dozwolone, ale tylko niekomercyjne,
Jest też ND – zakaz modyfikowania utworów (no derivatives).
Jakich licencji unikać w komercyjnych projektach?
Istnieją też takie licencje, które wymagają aby każdy utwór zależny (pochodny, czyli stworzony na podstawie lub przy wykorzystaniu pierwotnego utworu) był również objęty taką samą licencją jak ten utwór pierwotny. Innymi słowy, licencja taka narzuca wykorzystanie dokładnie takich samych postanowień we wszystkich utworach, które zostaną stworzone na podstawie utworu, który jest utworem pierwotnym. Powoduje to, że każdy projekt, w którym zastosujemy rozwiązanie oparte o taką licencję, też musi być nią objęty. W praktyce uniemożliwia to wykorzystanie takich rozwiązań w komercyjnych, zamkniętych programach. Uniemożliwia bowiem to dalsze komercyjne wykorzystanie lub sprzedaż.
Przykładem takiej licencji jest GNU GPLv3 – sztandarowy produkt zwolenników wolnego oprogramowania i jego dynamicznej oraz bezkompromisowej promocji (np. Richarda Stallmana). Licencja ta pozwala na dowolne wykorzystanie, rozpowszechnianie i modyfikowanie programu pod dwoma warunkami:
Kod źródłowy musi zostać udostępniony (jeśli rozpowszechniamy nasze oprogramowanie) - zarówno jeżeli modyfikujemy oprogramowanie oparte o licencję GNU GPLv3 jak również gdy samodzielnie tworzymy jakieś oprogramowanie na bazie programu, który jest objęty licencją GNU GPLv3,
Wszystkie utwory zależne (pochodne) stworzone przy wykorzystaniu kodu źródłowego objętego licencją GNU GPLv3 muszą również być objęty licencją kompatybilną (w praktyce z reguły tą samą) z GNU GPLv3.
Jak zamieścić informację o tym jakie rozwiązania open source zastosowaliśmy?
Często praktycznym problemem, jaki napotykają twórcy oprogramowania, jest to w jaki sposób informować o wykorzystaniu rozwiązań FOSS. Trzeba pamiętać o tym, że najpopularniejsze licencje, takie jak wspomniana tu MIT albo Apache License 2.0 wymagają aby w ramach utworu zależnego zamieścić informację o tym, że do jego stworzenia wykorzystano rozwiązania oparte o którąś z tych licencji.
Musimy tu pamiętać o tym, że w ramach jednego oprogramowania może być wykorzystane kilkadziesiąt różnych rozwiązań opartych o open source (albo nawet więcej). Jak o tym wszystkim informować? Metod jest kilka:
Można utworzyć odrębny folder z licencjami i wrzucić tam wszystkie licencje – metoda stosunkowo prosta. Folder taki powinien być dostępny po rozpakowaniu/zainstalowaniu oprogramowania, ew. umieszczony wraz z innymi plikami instalacyjnymi na nośniku. Jest jedna rzecz o której tu jednak trzeba powiedzieć - samo wrzucenie licencji to za mało, jeśli nie wiadomo czego one dotyczą.
Można umieścić wszystkie licencje w dokumentacji oprogramowania - oczywiście musimy pamiętać aby w takim przypadku tę dokumentację dołączać zawsze do programu/kodu źródłowego. Tu też wymagane jest aby dało się dopasować poszczególne licencje do konkretnych rozwiązań i autorów.
Można stworzyć w ramach naszego programu odrębne miejsce z informacjami o licencjach (np. zakładkę "O programie -> licencje" i tam umieścić informację o wszystkich rozwiązaniach, autorach i licencjach). Niektóre licencje open source wymagają zamieszczenia licencji bezpośrednio w programie w każdym przypadku gdy w jego ramach znajdują się jakieś informacje prawne dotyczące programu.
W każdym z tych przypadków należy pamiętać o jednej ważnej rzeczy - licencje należy umieścić i opisać tak, aby było wiadomo, która licencja odnosi się do jakiego (wykorzystanego przez nas rozwiązania) - niektórzy tworzą osobne foldery w odniesieniu do każdego rozwiązania, inni dodatkowe pliki z wyjaśnieniami "co jest od czego". Pamiętajmy, że z reguły różne rozwiązania mają różnych autorów - i o nich też nie należy zapominać, więc samo wrzucenie jednej licencji z adnotacją, że licencja odnosi się do X rozwiązań, które zastosowaliśmy, nic nam nie da – bo nie będzie wiadomo o jakie rozwiązania chodzi i kto jest ich autorem. Dlatego trzeba wskazać wszystkie licencje, wszystkie rozwiązania/programy i wszystkich autorów.
Co jeszcze powinniśmy wiedzieć?
To, że coś jest na licencji open source i my możemy z tego korzystać nie oznacza, że coś jest nasze – to nadal czyjś utwór, prawa autorskie majątkowe są własnością kogoś innego, kto po prostu zezwala nam na określone (szerokie) wykorzystanie takiego utworu. Niby to oczywiste, ale tylko w teorii.
Często jest bowiem tak, że firmy IT, sprzedając lub licencjonując oprogramowanie, oświadczają w zawieranych z klientami umowach, że wszelkie autorskie prawa majątkowedo całego programu (utworu) przysługują właśnie im, tzn. oni są twórcami od A do Z. To niestety nie jest prawdziwe stwierdzenie, jeżeli elementem takiego programu są biblioteki/frameworki, oparte o licencję open source, zwłaszcza jeśli korzystanie z programu bez nich nie jest najzwyczajniej w świecie możliwe. Dodam, że z nieznanych mi przyczyn, wpisywanie takich oświadczeń do umów jest powszechne i widziałem tego bardzo dużo
Dlatego też, jeżeli sprzedajesz/licencjonujesz oprogramowanie, w którym są elementy open source, to nie oświadczaj, że całość należy do Ciebie. Możesz za to napisać, że w celu jego stworzenia wykorzystałeś elementy FOSS zgodnie z ich licencjami - które są zresztą dostępne w samym programie :)
Jeżeli chcesz poczytać więcej na temat praw autorskich do oprogramowania komputerowego, zapraszam Cię:
Interesuje Cię problematyka używania rozwiązań open source w komercyjnych projektach? Jeśli masz jakieś dodatkowe pytania, możesz śmiało się ze mną skontaktować, pisząc na kontakt@bytelaw.pl, albo korzystając z formularza kontaktowego tutaj.
Comments