Licencje Open Source w wykorzystaniu komercyjnym nie zawsze bezpieczne

0
cyberbezpieczeństwo haker programista

Twórcy oprogramowania, w tym nawet duże software house’y chętnie i często korzystają z programów dostępnych na otwartych licencjach. Często jednak nie wiedzą, na co tak naprawdę dana otwarta licencja zezwala. Tymczasem niewłaściwe wykorzystanie kodu Open Source, z naruszeniem zasad jego licencjonowania, może być bardzo kosztowne. Nie chodzi tu wyłącznie o odpowiedzialność względem autorów otwartego kodu: na polskim rynku znacznie częściej jest to odpowiedzialność wobec zamawiającego, mogąca skutkować nawet odmową zapłaty wynagrodzenia.

Nie wszystkie otwarte licencje są bezpieczne

Mimo że popularne licencje takie jak MIT (licencja X11) czy Apache 2.0 są raczej liberalne i ich użycie w ramach wytwarzanego komercyjnego oprogramowania nie wiąże się z istotnymi uciążliwościami, użycie choćby fragmentu kodu opartego np. na licencji GNU AGPL powoduje konieczność ujawnienia całego kodu źródłowego wytworzonego oprogramowania. W praktyce więc licencja AGPL z tego powodu niemal nie nadaje się do zastosowań biznesowych.

Software house często nie wie, z czego korzysta deweloper

W wielu software house’ach czy agencjach interaktywnych poszczególni deweloperzy bądź zespoły projektowe mają wolną rękę w doborze rozwiązań technologicznych, w tym wykorzystaniu np. gotowych bibliotek. Programiści często ulegają pokusie, aby wykorzystać już funkcjonujące rozwiązania, które znajdą np. na GitHubie. O ile w niektórych przypadkach faktycznie nie ma potrzeby wyważania otwartych drzwi i wykorzystanie kodu Open Source ma racjonalne uzasadnienie, o tyle zawsze powinno być zgodne z wewnętrzną polityką firmy w tym zakresie, a ta zaś powinna być spójna z zawieranymi umowami. Project Manager czy Zarząd zawsze powinni mieć wiedzę o tym, że deweloper korzysta z kodu na licencji np. X11 i zadbać o odzwierciedlenie tego w ustaleniach z zamawiającymi.

Korzystanie w projektach komercyjnych z bibliotek dostarczanych w oparciu o tzw. licencje Open Source często pozostaje w sprzeczności z treścią umów, jakie dostawcy IT zawierają ze swoimi klientami. Umowy te niejednokrotnie wymagają choćby, aby twórca dysponował całością praw autorskich majątkowych do wytwarzanego oprogramowania, a tego warunku nie da się spełnić w przypadku korzystania z rozwiązań Open Source. Z drugiej strony korzystanie choćby z frameworków takich jak Struts czy Laravel jest bardzo powszechne. Wykorzystanie Open Source w IT to przecież nie tylko poszczególne biblioteki, ale także gotowe frameworki, które mocno przyspieszają pracę i zmniejszają finalne koszty produktu.

Czytaj również:  Energetyka napędzana przez innowacje

– Ważne jest, aby software house zadbał o właściwe uregulowanie otwartych licencji (w tym kwestii korzystania z frameworków) w swoich umowach zarówno z zamawiającymi, ale też z kontraktorami – mówi Tomasz Klecor, partner w kancelarii Legal Geek, specjalizującej się w obsłudze IT.

Co grozi za niedozwolone użycie oprogramowania Open Source?

Nieprawidłowe wykorzystanie oprogramowania Open Source może rodzić wiele konsekwencji. Będą to zarówno skutki wynikające bezpośrednio z przepisów prawa (w skrajnych przypadkach mogą to być teoretycznie nawet sankcje karne), jak i występująca częściej konieczność zapłaty odszkodowania. Mogą to być również konsekwencje umowne – wynikające z umowy z podmiotem, dla którego tworzymy oprogramowanie. W zależności od umowy może on domagać się np. zapłaty kary umownej czy zmniejszenia ceny.

– W praktyce bolesne i realne będą konsekwencje względem zamawiających oprogramowanie od software house’u, który nieprawidłowo użył kodu Open Source. Znamy bowiem sytuacje, w których przy okazji audytu oprogramowania (w związku z pozyskaniem inwestora) zamawiający odkrył, że w jego oprogramowaniu wykorzystano kod na licencji Open Source i doszło do jej naruszenia. Koszty usunięcia wady oprogramowania, które software house poniósł w następstwie roszczeń zamawiającego, niemal dorównały otrzymanemu wcześniej wynagrodzeniu. Co istotne, zarząd wykonawcy nie miał świadomości złego użycia kodu, a decyzja o wykorzystaniu konkretnego rozwiązania była samodzielną inicjatywą programisty – wyjaśnia prawnik z kancelarii Legal Geek.