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.

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.

Krótki przewodnik po licencjach Open Source

Aby ułatwić deweloperom i software house’om poruszanie się wśród prawnych pułapek, zespół kancelarii Legal Geek przygotował kolejny już poradnik prawny dla sektora IT. Tym razem skupia się on właśnie na posługiwaniu się rozwiązaniami Open Source. W poradniku dostępnym na stronie LegalGeek.pl znajdują się krótkie opisy wybranych, najpopularniejszych otwartych licencji. Dodatkowo przy każdej z nich umieszczono barometr, który pozwala ocenić jej biznesową przydatność.

Autor:

Tomasz Klecor, partner w kancelarii Legal Geek, specjalizującej się w obsłudze IT.