Depozyt kodów źródłowych jest zwierzęciem mitycznym. W 90% umów, które znam, utożsamia się depozyt ze złożeniem nośnika u notariusza. Z reguły dzieje się to bez sprawdzenia, co na nośniku jest, nie mówiąc o próbnej kompilacji. Ani o kopii w innym miejscu. Ani o procedurach dostarczania nowych wersji. Ani o wymaganiach dokumentacji kodu. Idea depozytu jest świetna – rozwiązuje wiele spornych kwestii, ale tylko wtedy, kiedy jest profesjonalnie obsłużona przez wyspecjalizowane podmioty. Osobiście byłem dwa razy przy podjęciu kodu; raz był to czysty kod, bez linijki komentarza, drugi raz kod był zaszyfrowany. A wykonawca odmówił podania hasła. Lista roszczeń teoretycznie jest długa, tylko że w IT nie chodzi o roszczenia.

Odpowiedzialność i system kar umownych

Najbardziej prawniczy temat, z niewiadomych przyczyn powierzany prawnikom. Wbrew pozorom, nie jest to zdanie nielogiczne. O ile same zapisy muszą być przez prawników tworzone czy weryfikowane, o tyle pomysły na zasady odpowiedzialności to kwestie biznesowe. I zarazem jedna z najbardziej twórczych prac podczas negocjacji. Może być tak, że wystarczą nam same kary za zwłokę. Ale dobry kontrakt przewiduje prawdziwe zagrożenia i próbuje im przyporządkować zasady odpowiedzialności, np. wprowadzając progresję kar, kary za nieodpowiednią jakość kodu, za nieusunięcie zgłoszonych błędów (retestowanie niepoprawionych wersji), rozbudowane systemy SLA ze szczegółowym systemem sankcji. Idea jest prosta: po pierwsze, zabezpieczyć kluczowe interesy stron, po drugie zrobić to precyzyjnie i skutecznie.

Zobacz również:

• Trendy i wyzwania dla przedsiębiorców w 2024 roku – ekspercka analiza Comarch
• Rząd Ghany pracuje nad regulacjami dotyczącymi AI

Niezwykle trudno jest pisać o kluczowych interesach w sposób abstrakcyjny, bo one się różnią. Opóźnienia w projekcie to oczywistość, ale np. procedura testowania, kary za przekazanie do testowania niewłaściwej jakości kodu, za niepoprawienie błędu i zmuszania do retestowania tych samych wersji wymagają ścisłej współpracy z zespołem IT czy zespołem odpowiedzialnym za biznes. Brak współdziałania prowadzi do standardowych kontraktów, które nie radzą sobie z innymi problemami.

W sądach często pojawia się spór, jak rozumieć zapisy – za co jest kara (mityczna „dostępność”), jak należy ją liczyć (procent wynagrodzenia w kontraktach ze zmiennym wynagradzaniem) i czy jest skuteczna (kary za zwłokę przy odstąpieniu od umowy). To warsztat prawny, ale zaniedbania w precyzyjnym opisie są częste i zasłużenie kwalifikują się do „top five”.

Każdy z punktów wymaga oddzielnego omówienia, a to lista niepełna. Przez ostanie 20 lat kontrakty IT nauczyły mnie, że niepowodzenie projektu IT ma o wiele większe skutki niż wartość samej umowy. Nie negocjujemy kontraktu o wartości X, negocjujemy niezbędny fragment inwestycji o wartości wiele razy X. Nie jest możliwe napisanie idealnego, precyzyjnego i niepozbawionego pola do interpretacji kontraktu, ale zbyt często pod wpływem presji czasu lub innych czynników zgadzamy się na zapisy jawnie prowokujące do sporów. Których, zaręczam, warto w naszym systemie sądownictwa unikać. Zajmują za wiele czasu i kosztują zbyt dużo. O wiele więcej niż uczciwe przeprowadzone negocjacje.

Autor jest radcą prawnym, specjalistą prawa zobowiązań oraz prawa autorskiego w zakresie umów i projektów informatycznych i telekomunikacyjnych.