Jakość i moc umowy sprawdza się najczęściej dopiero z chwilą zaistnienia warunków spornych. Wtedy też na jaw wychodzi oddalenie od prawdy zawartych w niej zapisów, z czym borykać się musi, czasami przez długie lata, strona dochodząca swoich praw. W całej tej niedoskonałości nie istnieje metoda egzekucji swoich racji inna niż długotrwała droga prawna. Czasami można spotkać się niestety z brakiem odpowiedzialności i staranności prawniczej podczas sporządzania umów. Gdy autor niniejszego artykułu jako specjalista z zakresu technologii informatycznych brał udział po stronie klienta w przygotowywaniu umowy na zakup i wdrożenie dedykowanego oprogramowania, współdziałający prawnik zadbał o to, aby w umowie znalazły się klauzule, które w informatycznym kontekście pozbawione były logiki. Jego punkt widzenia był taki, że jeśli kiedyś wyniknie problem i jeśli umowa okaże się merytorycznie wadliwa, to w razie potrzeby właściwy sąd to rozstrzygnie. Tak więc wynika z tego, że brak staranności w przygotowaniu umowy z założenia skazuje jedną ze stron na potencjalne problemy. A powinno chodzić o to, aby nie stawiać kogokolwiek w takiej sytuacji. W każdym przypadku lepiej stosować odpowiednie działania prewencyjne, aby nie dopuszczać do konieczności dochodzenia swych racji przed sądami, co może trwać nawet latami. W przypadku oprogramowania taka zwłoka jest nie do przyjęcia.

Motywacje i przesłanki

W tym miejscu warto zastanowić się, czy istnieją jakieś szczególne, oprócz zwykłej uczciwości, pobudki, które miałyby kierować stroną autorską w dochowaniu starań, aby depozyt zawierał rzetelną merytorycznie i kompletną zawartość źródeł oprogramowania. W zasadzie nie ma takich przesłanek i motywacji. Z chwilą upadłości lub zakończenia działalności firmy autorskiej nie będzie komu ponieść odpowiedzialności za merytoryczną zawartość depozytu. Depozytariusz stwierdzi, że depozyt był przechowywany zgodnie z normami, a to, że jego zawartość jest niezgodna z oświadczeniem strony deponującej, jest sprawą dla sądu. Poza wszystkim mogą być problemy ze wskazaniem winnych wobec nieistnienia sprawczego podmiotu gospodarczego.

Z drugiej strony, jaki interes miałaby strona autorska, aby deponować wadliwe kody źródłowe? W zasadzie nic za tym nie przemawia, z wyjątkiem obaw o utracenie kontroli nad swoją własnością autorską, która niejednokrotnie stanowi o być albo nie być danego podmiotu. Jeśli jednak depozytariusz gwarantuje właściwą ochronę przedmiotu powierzenia, nie powinny pojawić się żadne wątpliwości o naruszenie tajemnicy. Wykluczyć raczej należy kwestie związane z umyślnym wprowadzaniem przez stronę autorską zamieszania przez udostępnianie kodu wadliwego, co można byłoby jedynie wytłumaczyć swego rodzaju złośliwością czy chęcią zemsty zza grobu biznesowej upadłości. Obawiać się natomiast należy niestaranności, co powoduje, że w depozyt nie są przekazywane wszystkie aktualne wersje przyrostowe produktu lub nie są one kompletne. Nierzadko zdarza się, że w umowie na dostawę oprogramowania strona kliencka zadowala się gwarancją zdeponowania pierwowzoru systemu, podczas gdy o wszelkich modyfikacjach oraz trybie i czasie ich przekazywania już się nie wspomina.

Weryfikować czy nie?

Wypadałoby się zastanowić, czy warto prowadzić batalię o weryfikowanie deponowanych kodów źródłowych oraz wypracowywać metody, jakimi można się w tym przypadku posłużyć. Zauważyć należy, że zgodność przechowywanych źródeł ze stanem aktualnym jest zarówno z prawnego, jak i technicznego punktu widzenia trudno weryfikowalna, gdyż nikt nie dysponuje źródłami wzorcowymi, do których można by odnieść zawartość depozytu.