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.
Spis treści:
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.
– 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.