Zarządzanie kodem źródłowym w projektach IT – umowy, metodyki i praktyka – część I

Systemy informatyczne mają coraz bardziej skomplikowany i zaawansowany charakter. Zwiększa się także świadomość ?głównego użytkownika? – mitycznego odbiorcy rozwiązań będących przedmiotem wdrożenia.

Świadomość ta powoduje, iż zarządzanie kodem źródłowym w projektach IT kojarzy się już nie tylko z pilotowaniem tego kodu przez sztab programistów po jednej czy drugiej stronie, lecz zaczyna odgrywać istotną rolę w nowoczesnym zarządzaniu projektami IT, czy szerzej firmą jako organizacją, którym to wątkiem zainteresowani są już nie tylko CTO, lecz praktycznie każdy świadomy ?C-manger?.

W niniejszym artykule zaproponuję spojrzenie na to zagadnienie z perspektywy zarówno biznesowej, tj. kontraktów zawieranych przez firmy poza procedurami przetargowymi, oraz zamówień publicznych, gdzie zarządzanie kodami źródłowymi powinno zostać na nowo zdefiniowane. Tak zdefiniowany obszar powinien uwzględniać w pierwszej kolejności aspekty prawne (przysługujące nam prawa i obciążające nas obowiązki) oraz konstrukcje umów wdrożeniowych. Na pewno nie można zapomnieć o tym, jak w cały ten proces wkomponowują się różnego rodzaju metodyki zarządzania projektami czy wytwarzania oprogramowania. Na koniec spróbujemy podsumować dobre praktyki funkcjonujące w tym obszarze.

1. Vendor Lock ? In

Niektórym Vendor Lock ? In kojarzy się z ruchami w zakresie wolnego i otwartego oprogramowania. Ma to jednak swoje głębsze korzenie. Vendor lock ? in, rozumiany jako uzależnienie odbiorcy od towarów lub usług jednego producenta, czego refleksem jest brak możliwości jego zmiany, co najmniej bez konieczności poniesienia znacznych kosztów1 nie jest niczym nowym. Jednym z pierwszych znanych przełomów w pokrewnym obszarze ? monopolu na wiedzę, była laicyzaja prawa rzymskiego w starożytności, od kiedy to prawem mogli zajmować się już nie tylko ?kapłani?, lecz także zwykli śmiertelnicy. Konkurencja więc motywuje, natomiast dobrze funkcjonujący monopol wydaje się być swoistą nirwaną każdego przedsiębiorcy. Pytanie, czy jest to dobre rozwiązanie dla nabywcy rozwiązań IT, którym często jest wewnętrzny dział IT o wielkości dużej firmy informatycznej (banki, ubezpieczyciele itp.).

2. SVN i GitHub

Narzędzia techniczne służące do zarządzania procesem wytwarzania kodu źródłowego są nie do przecenienia, zwrócimy na nie większą uwagę w drugiej części artykułu. W tym miejscu warto zapamiętać, że nie chodzi jedynie o akronim NLOC (ang. netto lines of code). Tylko dostęp do pełnego kodu, przez który rozumiemy kod należycie opisany i skomentowany sprawi, że zagwarantujemy sobie bezpieczeństwo w ewentualnych przyszłych wykorzystaniach. Z perspektywy wykonawcy również warto niekiedy mocniej się wysilić i przekazać zamawiającemu w tym zakresie więcej ? w szczególnych przypadkach może to uchronić wykonawcę przed nieuzasadnionymi roszczeniami nienależytego wykonania projektu.

3. Dostęp do kodu źródłowego na poziomie umowy

Clue programu i niemalże ?abecadło? prawnicze w tym zakresie. Samo przeniesienie autorskich praw majątkowych do oprogramowania czy systemu informatycznego, nawet z posłużeniem się długiej listy ? odnalezionej ?w Sieci? – pól eksploatacji, w zakresie których to przeniesienie ma nastąpić, nie gwarantuje tego, że wykonawca będzie zobowiązany do przekazania nam kodów źródłowych. Wielokrotnie wypowiedziały się w tej sprawie sądy.

Przykładowo ? nie dawniej jak we wrześniu 2014r. Sąd Apelacyjny w Warszawie w jednym ze swoich orzeczeń stwierdził, iż ?Z żadnego z powołanych w apelacji przepisów ustawy o prawie autorskim i prawach pokrewnych nie wynika przede wszystkim, aby wykonanie umowy dotyczącej przeniesienia praw autorskich do programu komputerowego przez jego twórcę obejmowało także obowiązek wydania kodów źródłowych nabywcy takich praw, jak również by ich zbycie z mocy prawa uprawniało nabywcę do wykonywania modyfikacji zakupionego programu, zwłaszcza we wszystkich możliwych zakresach i wszelkich jego częściach składowych?.

Zimny prysznic, szczególnie gdy usłyszymy to po raz pierwszy na rozprawie, po kilku latach inwestowania w proces i pełnomocników. Co więcej, sąd jest w stanie przypomnieć jeszcze inne reguły wynikające z prawa autorskiego, jak chociażby ta, że to autor oprogramowania (tudzież producent) podlega szczególnej ochronie i nabycie autorskich praw majątkowych w najszerszym możliwym zakresie nie powoduje, iż możemy sobie uzurpować prawo do wszystkich aspektów tego oprogramowania, jak kod źródłowy i ?jakiekolwiek? modyfikacje.

Podobną bolączką, którą zaczynają być dotykani zamawiający publiczni, jest brak dostępu do API produkowanych dla nich aplikacji czy ich dalszego udostępnienia. W erze ?smart city? i big data w zakresie rozwiązań o charakterze miejskim (aplikacje), które mają służyć społeczności i pobudzać firmy do pisania swoich aplikacji na bazie danych udostępnianych przez Państwo (open data) może to być nie lada problem. Oczywiście później wszystko jest tylko kwestią ceny.

Po uzyskaniu dostępu do kodu, na pewno należy uważać z jego natychmiastowym utylizowaniem ? należy zrobić to roztropnie, tak aby nie stracić uprawnień wynikających z umów gwarancyjnych, utrzymaniowych czy serwisowych.

4. Jak komentować kod

Odwieczny problem, który staramy się rozwiązywać na poziomie umów wdrożeniowych ?w boju?. Są na to praktyczne rady ? zagadnienie wiąże się po części z punktem 2 powyżej, stąd też nie będę go w tym miejscu gruntownie rozwijał. Tytułem sygnału wskazać można, iż dobrym rozwiązaniem jest odesłanie do różnego rodzaju standardów. Których? To już zależy od specyfiki projektu i nabywcy oprogramowania oraz, a być może przede wszystkim, charakteru oprogramowania i jego przeznaczenia. Na pewno warto odnosić się do metodyk, które definiują jak kod powinien być sformatowany, ustrukturyzowany czy skomentowany. Warto pomyśleć w tym zakresie chociażby o OWASP Enterprise Security API.

5. Zamawiający publiczni

Zamawiający publiczni również powinni rozważyć, w jakim zakresie i kiedy powinni zagwarantować sobie dostęp do kodów źródłowych. Oczywiście nie powinno to powodować swoistej ?urawniłowki?, natomiast warto jest pochylić się nad tym zagadnieniem. Zostało ono nawet dostrzeżone z poziomu wielokrotnie krytykowanych Wytycznych Prezesa UZP dot. zamówień na systemy informatyczne2 Zestawienie ?kod źródłowy? zostało użyte w tym dokumencie ponad 20 razy, stąd należy chociażby docenić kierunek dostrzeżony przez Prezesa UZP w tym zakresie i dopasowywać wskazówki użyte w tychże rekomendacjach do konkretnych projektów informatycznych. Uzasadnienie, że znacznie to podroży koszty realizacji zamówienia nie zawsze znajduje odzwierciedlenie w rzeczywistości.

6. Projekty infrastrukturalne

O zarządzaniu kodem źródłowym nie można zapominać również w tego rodzaju projektach. Przykładem mogą być projekty inteligentnych systemów transportowych (ITS). Praktyka bazuje tutaj na umowach na roboty budowlane, które bazują na międzynarodowym standardzie FIDIC3, który publikuje wzory umów (?książki?), które sprawdzają się praktycznie we wszystkich typach projektów inwestycyjnych. W zakresie prawa autorskiego jest tam uregulowana jedynie kwestia korzystania z projektów i rysunków. Nie ma mowy, aby obejmowało to swym zakresem skomplikowane życiowo przypadki użycia oprogramowania w danym projekcie. Trzeba więc taki FIDIC uzupełnić o ? najlepiej ? osobną umowę licencyjną lub dotyczącą przeniesienia praw.

Już powyższa część opracowania pokazuje, jak wielowątkowa jest kwestia zarządzania kodem źródłowym w projektach IT. W kolejnych rozważaniach postaramy się zejść trochę niżej z tego czubka góry lodowej.

Rafał Malujda, radca prawny ? prowadzi Kancelarię Radcy Prawnego www.malujda.pl, współpracuje z zamawiającymi i wykonawcami w procedurach przetargowych i firmami IT w zakresie realizowanych przez nie projektów, przeprowadza due dilligence projektów IT

Rafał Malujda
radca prawny