Pułapki w Open Source mogą uderzać po kieszeni

Przeczytaj także: Dlaczego IT woli programowanie open source? Chodzi nie tylko o pieniądze

Nie wszystkie otwarte licencje są bezpieczne

Wprawdzie najbardziej popularne licencje jak chociażby MIT (licencja X11) czy Apache 2.0 charakteryzuje dość liberalne podejście i skorzystanie z nich przy tworzeniu komercyjnego programu nie powinno skutkować uciążliwościami, to jednak już użycie nawet fragmentu kodu bazującego np. na licencji GNU AGPL owocuje koniecznością ujawnienia całego kodu źródłowego wytworzonego oprogramowania. Z tego też względu AGPL właściwie nie nadaje się do zastosowania biznesowego.

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

Doświadczenie pokazuje, że w software house’ach czy agencjach interaktywnych deweloperom czy zespołom projektowym daje się sporą swobodę w zakresie wyboru technologii, w tym również w korzystaniu z gotowych bibliotek. W efekcie programiści nierzadko sięgają po już gotowe rozwiązania, które oferuje im np. GitHub. 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.