Identyfikacja ryzyka w projektach open source

Analizujący problem open source zauważają niekiedy, iż nie można jednoznacznie wskazać, dlaczego programiści wybierają te, a nie inne wolne licencje. Niesie to ze sobą istotne praktyczne konsekwencje, bo nie każda z licencji zawiera klauzulę copyleft. Z kolei wykorzystywanie w ramach jednego rozwiązania modułów udostępnianych na różnych zasadach skutkować będzie niepożądanymi konsekwencjami, w tym groźbą procesu cywilnego. Tak więc identyfikacja ryzyka prawnego, związanego z partycypacją w projekcie open source, powinna poprzedzać jakiekolwiek przedsięwzięcia komercyjne.

Rozróżnić trzeba przy tym odmienne modele tworzenia programów - czasem są one rozwijane na poziomie ruchu społeczności programistów, czasem zaś przyjmują bardziej sformalizowane zasady (projekty realizowane przez przedsiębiorstwa). W pierwszym wypadku bardziej prawdopodobne jest ryzyko związane z umieszczeniem fragmentów kodu, naruszających cudze prawa. Może chodzić nawet o brak respektu dla klauzuli copyleft przy dystrybucji oprogramowania, gdy zaczerpnięto jego fragmenty z projektu udostępnianego w oparciu o GPL.

Dochodzą do tego pojawiające się na horyzoncie problemy powiązane z rozprzestrzenianiem się ochrony patentowej. Niebagatelnym problemem jest jednak wykorzystywanie kodu pozyskanego z "oprogramowania własnościowego" - udostępnianego na tradycyjnych zasadach rynkowych. Brak łatwej dostępności do kodu źródłowego aplikacji uniemożliwia przy tym nierzadko ujawnienie naruszenia praw autorskich. Zwłaszcza że w świetle przepisów rodzimego prawa autorskiego dekompilacja programu podyktowana wyłącznie celem zweryfikowania, czy doszło do nieuprawnionego skopiowania kodu, nie jest dozwolona.

Zakładając dynamiczny rozwój projektu IT i rozwijanie go przez kolejne podmioty w razie pojawienia się "wad prawnych" każde z kolejnych ogniw współtworzących go może liczyć się z podjęciem wobec niego kroków prawnych przez dysponującego majątkowymi prawami autorskimi. Dodatkowym mankamentem jest możliwość naruszenia dobrego imienia rozwijającego oprogramowanie. Skuteczną metodą uniknięcia choć części problemów może być audyt kodu źródłowego. Sięgając po pomoc wyspecjalizowanych podmiotów, uzyskujemy analizę, jaki kod został zawarty w projekcie, na jakim tle pojawiają się zagrożenia dla jego dystrybutora, co wymaga ewentualnej modyfikacji. Ułatwia to też określenie modułów programu, udostępnianych na różnych licencjach.