Trudno wyobrazić sobie współczesny świat IT bez Open Source. Otwarte oprogramowanie jest w zasadzie wszędzie. Zeszłoroczne badanie firmy Synopsys pokrywające ponad 1,5 tys. kodów źródłowych pochodzących z 17 branż (takich jak m.in. fintech, IoT, telekomunikacja, lotnictwo) wskazało, że aż 98% spośród nich zawierało elementy Open Source. Niemal pewne jest więc, że jest on częścią również Twoich projektów. A czy aby na pewno legalnie?
Wpis ten jest zainspirowany szkoleniem Open Source licences in commercial use, w którym miałem przyjemność uczestniczyć. Serdecznie polecam Andrzeja Oryla – świetnego radcę prawnego, wykładowcę i eksperta w tej dziedzinie.
Czym jest Open Source?
Zanim przejdziemy do komercyjnego wykorzystania otwartego oprogramowania, sprawdźmy czym ono tak naprawdę jest.
Okazuje się, że nie istnieje jedna oficjalna i globalnie przyjęta definicja Open Source. Według OpenSource.org:
Open Source nie oznacza jedynie dostępu do kodu źródłowego. Zasady dystrybucji oprogramowania Open Source muszą być zgodne z określonymi kryteriami.
OpenSource.org
Wspomniane kryteria to m.in.: swoboda redystrybucji, dostępność kodu źródłowego, możliwość tworzenia produktów zależnych, integralność autorskiego kodu źródłowego, brak dyskryminacji przeciwko określonym osobom, grupom osób bądź obszarom biznesu i kilka innych (opisanych szerzej na OpenSource.org).
W uproszczeniu, terminem Open Source nazywamy oprogramowanie udostępnione na licencji gwarantującej dostęp do kodu źródłowego oprogramowania, modyfikowanie go oraz redystrybuowanie – zarówno w oryginalnej, jak i zmienionej wersji.
Case Study: bardzo dostępny, bardzo darmowy i bardzo… nielegalny
We wstępie zasugerowałem, że Open Source jest z pewnością obecny i w Twoim projekcie – nawet jeśli nie zdajesz sobie z tego sprawy (chociażby w niewinnej postaci – np. bibliotek, konkretnych języków programowania itp.).
Wydaje mi się, że w moim przypadku ta świadomość zawsze istniała, przynajmniej częściowo. Wiedziałem, np. że w jednym z projektów, które zrealizowaliśmy, jako bazę pod nowy produkt wykorzystywaliśmy opensource’owe frameworki. Doświadczeni deweloperzy i konsultanci otrzymali zadanie, przeprowadzili research dostępnych narzędzi, wybrali najlepsze (Open Source) i ruszyli z pracami programistycznymi.
Gdy prace w zasadzie dobiegły końca, jednemu z developerów przypadkiem wpadł w ręce tekst licencji, na bazie której dystrybuowany był wspomniany framework. Okazało się, że licencja ta nie pozwalała na jego komercyjne wykorzystanie. Po głębszej analizie tematu (oraz stosowanych przez nas narzędzi) odkryliśmy więcej problemów:
- brak możliwości wykorzystania danego frameworka w celach komercyjnych (a przecież nie realizujemy naszego projektu pro bono…),
- konieczność udostępnienia stworzonego przez nas produktu (częściowo opartego na Open Source) do dalszej modyfikacji/wykorzystania (wiralowość Open Source),
- przymus informowania użytkowników produktu o wykorzystaniu Open Source.
Oczywiście biorąc pod uwagę charakter naszego projektu oraz umowę z klientem, nie mogło być mowy o spełnieniu któregokolwiek z powyższych wymagań licencyjnych. Jedynym wyjściem z tej patowej sytuacji była odpowiednia modyfikacja rozwiązania, pozbywająca się narzędzi dystrybuowanych w oparciu o niekorzystne dla nas licencje. Generalnie, zaistniała sytuacja wyszła nam na dobre (również technicznie), ale o tym opowiem innym razem. Nie mniej jednak, straciliśmy na nią mnóstwo czasu oraz nerwów.
Licencje Open Source, a użytek komercyjny
Myślę, że lekcją płynącą z powyższej historii nie powinna być niechęć do Open Source, a raczej świadome używanie go, ze znajomością licencji w ramach której jest dystrybuowany. Zaznajomienie się z nimi nie jest trudne – na trzech najpopularniejszych typach licencji opiera się bowiem zdecydowana większość rozwiązań Open Source. Oto one:
| Licencja Open Source | Charakterystyka | Użytek komercyjny |
| MIT | Licencja pozwala jej posiadaczowi, w sposób swobodny i wolny od jakichkolwiek opłat, dysponować oprogramowaniem (włączając w to jego używanie, kopiowanie, modyfikowanie, łączenie, publikowanie, dystrybuowanie, sub-licencjonowanie, sprzedawanie) pod warunkiem zawarcia tej informacji (copyright notice) w każdej kopii oprogramowania. Oprogramowanie rozprowadzane w ten sposób nie jest objęte żadną gwarancją ze strony autora i nie jest on odpowiedzialny za konsekwencje wynikające z korzystania z niego. Udział w rynku w 2021 roku: 26% (według whitesourcesoftware.com) |  Oprogramowanie może być śmiało wykorzystywane komercyjnie. Jego licencja jest bardzo liberalna i zobowiązuje twórcę jedynie do dołączenia jej treści (informacji o zasadach korzystania z Open Source) do produktu finalnego. |
| Apache 2.0 | Podobnie jak w przypadku MIT, licencja uprawnia do reprodukowania, tworzenia utworów zależnych, publicznej prezentacji, sublicencjonowania, dystrybuowania w formie źródła bądź produktu – w sposób nieograniczony i wolny od opłat. Licencja zobowiązuje jej posiadacza do przekazania jej treści wszystkim osobom związanym w budowany produkt (współautorzy, użytkownicy itd.). Istnieje możliwość sformułowania własnych zapisów licencyjnych, dot. autorskich modyfikacji produktu (i rozprowadzania go pod innymi warunkami). Udział w rynku w 2021 roku: 28% (według whitesourcesoftware.com) | Oprogramowanie może być śmiało wykorzystywane komercyjnie. Jego licencja jest bardzo liberalna i zobowiązuje twórcę jedynie do dołączenia jej treści (informacji o zasadach korzystania z Open Source) do produktu finalnego. |
| GNU General Public License GPL v3 | Licencja daje możliwość nieodpłatnego oraz nieograniczonego używania oprogramowania w niezmienionej formie. W przypadku wykorzystania go do stworzenia innego produktu, produkt ten musi być dystrybuowany pod tą samą licencją, co oprogramowanie GLP v3 (o ile jest w nim w jakikolwiek sposób zawarty). Udział w rynku w 2021 roku: 10% (według whitesourcesoftware.com) |  Zastosowanie oprogramowania w celach komercyjnych jest bardzo mocno ograniczone. Trudno wyobrazić sobie bowiem, abyśmy mogli być zainteresowani dystrybuowaniem komercyjnego produktu na licencji Open Source. |
Umowa z klientem, a Open Source
Poza kwestią samego Open Source’a i postanowień jego licencji, problemów z wykorzystaniem otwartego oprogramowania w projektach komercyjnych mogą nam nastręczyć zapisy umowy z klientami. Okazuje się bowiem, że wielu klientów formalnie nie wyraża zgody na stosowanie Open Source przez dostawców oprogramowania.
Mogą kryć się za tym następujące przyczyny:
- chęć posiadania w 100% autorskiego kodu (co jest w zasadzie niemożliwe do osiągnięcia),
- względy bezpieczeństwa,
- ograniczenia nałożone przez zewnętrzną licencję (istnieją one niezależnie od tego jak liberalna ta licencja jest),
- konkurencja (m.in. niechęć do publikowania informacji o stosowanych w produkcie technologiach, w obawie przed konkurentami).
Przed przystąpieniem do pracy zweryfikujmy więc z zespołem treść umowy – nie biorąc niczego za pewnik. Nawet jeśli na zdrowy rozsądek coś „absolutnie nie ma sensu” (np. zakaz stosowania Open Source), kontrakt niekoniecznie jest tego odzwierciedleniem. Mnóstwo umów bazuje bowiem na szablonach, które nasze firmy (oraz klenci) przygotowały wieki temu. Bez regularnej aktualizacji są z pewnością pełne takich „kwiatków”.
Co z tym Open Source?
Świadomość umowy, na bazie której realizujemy nasz projekt oraz zapoznanie się z warunkami licencji oprogramowania Open Source, po które sięgamy – to według mnie dwa klucze do sukcesu, jeśli chodzi o wykorzystanie otwartego oprogramowania do celów komercyjnych.
Co do samych licencji Open Source: MIT oraz Apache nie powinny budzić naszych obaw, natomiast przy pozostałych (również GPL) lepiej zatrzymajmy się na chwilę i sprawdźmy ich zapisy z prawnikami (i tu znów polecam Andrzeja Oryla).