W przypadku wdrożenia standardowych rozwiązań informatycznych, dostawca  zazwyczaj dostarcza klientowi oprogramowanie w postaci kodu wynikowego. Udzielana licencja zazwyczaj upoważnia jedynie klienta do „normalnego”, produkcyjnego wykorzystania standardowego oprogramowania. Jednocześnie, dostawca w ramach odrębnych umów zapewnia klientowi serwis oraz rozwój dostarczonego oprogramowania.

Oczywistym ryzkiem związanym z tego rodzaju modelem udostępnienia oprogramowania jest upadłość lub likwidacja działalności przez dostawcę (producenta)  oprogramowania. Z dnia na dzień klient może pozostać bowiem, zarówno bez wsparcia ze strony producenta oprogramowania, jak również bez technicznych (brak kodu źródłowego) oraz prawnych możliwości samodzielnej modyfikacji, czy rozbudowy oprogramowania. 

Interesującym środkiem na ograniczenie tego rodzaju ryzyka gospodarczego jest skorzystanie z konstrukcji depozytu kodu źródłowego. W generalnym ujęciu istotna depozytu kodu źródłowego sprowadza się do złożenia przez licencjodawcę, kodów źródłowych u zaufanej osoby trzeciej (depozytariusza), przy jednoczesnym upoważnieniu licencjobiorcy do wydobycia i dalszego wykorzystania kodów źródłowych w określonych w umowie przypadkach (np. upadłości, likwidacji producenta oprogramowania). W polskiej praktyce obrotu najczęściej rolę  depozytariusza pełnią banki oraz  kancelarie notarialne. Z praktyki autora wynika, iż pomału przedsiębiorcy zaczynają korzystać również z usług wyspecjalizowanych firm świadczących usługi depozytowe.   

W praktyce obrotu wykształciło się przynajmniej kilka konstrukcji umów depozytu kodów źródłowych. Podstawą ustanowienia depozytu może być umowa  trójstronna, regulującą wzajemne prawa i obowiązki licencjodawcy, licencjobiorcy oraz depozytariusza. Depozyt ustanowiony może zostać również przy wykorzystaniu dwóch, powiązanych ze sobą umów dwustronnych. Pierwsza umowa, obejmuje zobowiązanie licencjodawcy do ustanowienia depozytu oraz określa warunki depozytu (np. zasady składania i odbioru kodów źródłowych,  zasady zachowania poufności kodów źródłowych). W wykonaniu tej umowy, jedna ze stron (licencjobiorca albo licencjodawca) zawiera z depozytariuszem umowę będącą podstawą przechowania kodu źródłowego (np. umowę skrytki bankowej).  

Wybór stosownej konstrukcji depozytu ma pierwszorzędne znaczenie w przypadku, gdy celem depozyt jest zabezpieczenie klienta przed upadłością licencjodawcy. W takim wypadku należy bowiem brać pod uwagę szczególne regulacje prawne wynikające z prawa upadłościowego.

Przykładowo, z dniem ogłoszenia upadłości wygasają zawarte przez upadłego z bankiem umowy o udostępnienie skrytek sejfowych oraz umowy przechowania (art. 113 PrUpNr). A zatem, jeżeli to licencjodawca jest stroną umowy skrytki bankowej (do czego dążą często licencjodawcy, obawiając się o utratę kontroli nad depozytem), to ochrona licencjobiorcy na wypadek upadłości producenta okazuje się iluzoryczna.  W takim wypadku, z chwilą ogłoszenia upadłości licencjodawcy, umowa skrytki bankowej wygaśnie z mocy samego prawa, a syndyk uprawniony będzie do odbioru depozytu.

Zdaniem autora niniejszego artykułu, nawet w przypadku, gdyby licencjodawca zawarł umowę przechowania kodu źródłowego z innym podmiotem niż bank (np. z wyspecjalizowaną firmą) lub zawarta została umowa trójstronna, to w konkretnym stanie faktycznym może istnieć ryzyko, iż w przypadku upadłości licencjodawcy, syndyk na podstawie przepisów prawa upadłościowego będzie uprawniony do odstąpienia od umów depozytu (odbierz depozyt). Przedstawienie szczegółowej argumentacji prawniczej w tym zakresie przekracza niestety ramy niniejszego  artykułu.

Wydaje się zatem, iż najbezpieczniejszym rozwiązaniem dla licencjobiorcy zawarcie przez licencjobiorcę z licencjodawcą umowy określającej warunki depozytu, a następnie samodzielne zawarcie przez licencjobiorcę umowy będącej podstawą przechowania kodu źródłowego (np. umowy skrzynki bankowej).  

Zagwarantowanie sobie przez licencjobiorcę dostępu do kodu źródłowego oraz dokumentacji na wypadek upadłości, czy likwidacji producent oprogramowania, to jedynie „połowa” sukcesu. Licencjobiorca powinien również zagwarantować sobie prawo do wykorzystywania wydobytego z depozytu kodu źródłowego, w szczególności dalszego rozwoju i modyfikacji oprogramowania. Umowa depozytowa powinna przewidywać zatem udzielenie licencjobiorcy przynajmniej niewyłącznej licencji na korzystanie z wydobytego kodu źródłowego, w tym prawa do zwielokrotnienia, tłumaczenia (tu szczególnie kompilacji) oraz modyfikacji oprogramowania (art. 74 ust. 4 pkt 1 i 2 prawa autorskiego).

W praktyce koniecznym może okazać się powierzenie przez licencjobiorcę dalszego serwisu i rozwoju kodów źródłowych innej firmie informatycznej. Przewidując taką sytuację, licencjobiorca powinien dążyć do zapewnienia sobie prawa do udzielania sublicencji na wydobyte kody źródłowe firmą świadczącym na jego rzecz usługi w zakresie dalszego serwisu i rozwoju oprogramowania.    

Ze względu na przepisy prawa upadłościowego, niezwykle istotną kwestią jest prawidłowe określenie momentu udzielenia licencji na kody źródłowe. Niekiedy spotyka się umowy depozytowe, przewidujące, iż licencja na kody źródłowe zostaje udzielona lub rozszerzona,  dopiero po ziszczeniu się opisanych w umowie depozytowej warunków uzasadniających wydobycie kodów z depozytu (np. ogłoszenie upalności licencjodawcy). Należy jednak zauważyć, iż zgodnie z przepisami prawa upadłościowego nieważne są postanowienia umowy zastrzegające na wypadek ogłoszenia upadłości zmianę stosunku prawnego, którego stroną jest upadły (art. 83  PrUpNr).  Zdaniem autora niniejszego artykułu istnieje ryzyko prawne, iż powyżej opisana praktyka narusza postanowienia prawa upadłościowego. Wydaje się zatem, iż bezpieczniejszym dla licencjobiorcy rozwiązaniem będzie uzyskanie  licencji na kody źródłowe w zakresie  pozwalającym na ich modyfikację już w chwili zawarcia umowy depozytowej, przy jednoczesnym zobowiązaniu się licencjobiorcy do niekorzystania z tychże uprawnień do czasu wydobycia kodów źródłowych z depozytu (co jest możliwe tylko w przypadkach opisanych w umowie depozytowej).   

Roman Bieda

(artykuł ukazał się w Computerworld, Raport Specjalny z ERP Top10, z 16 marca 2010 r. )