Wstęp

W artykule na temat ochrony know-how napisałem:

Projektant (analiza biznesowa i projektowanie), na podstawie wymagań (biznesowych) Inwestora tworzy autorskie dzieło jakim jest Projekt rozwiązania. Na tej podstawie powstają Projekt implementacji i Kod aplikacji. Wszystkie te dokumenty chroni prawo autorskie, jednak Projekt implementacji i Kod aplikacji to dzieła zależne, pierwotnym utworem jest tu Projekt rozwiązania. Dlatego autor Projektu rozwiązania ma ustawowy nadzór autorski nad jego realizacją. (źr. Ochrona know-how Prawo autorskie)

Dzisiaj opiszę problem prawnych zależności pojęciowych w projekcie informatycznym i odpowiedzialności (zobowiązań) stron umów, oraz to, jakie ma to konsekwencje w zawieranych umowach. Artykuł ten to także przykład zastosowania elementów analizy systemowej w takich rozważaniach (do stworzenia modelu pojęciowego wykorzystano symbole diagramu faktów notacji SBVR¹ oraz diagramu komunikacji UML², zostały one tu użyte w sposób bardzo intuicyjny, więc czytelnicy nie powinni mieć problemu z ich prawidłową interpretacją).

Artykuł adresuje do tych moich czytelników, którzy biorą udział w ustalaniu treści umów na dostarczenie oprogramowania.

Wybrane umowy cywilnoprawne i ich specyfika

Scharakteryzuję tu umowy i słownictwo opisane w kilku ustawach ustawach:

1. Kodeks Cywilny Tytuł XV. Umowa o dzieło³
2. Kodeks Cywilny Tytuł XXI. Zlecenie⁴
3. Ustawa o prawie autorskim i prawach pokrewnych⁵
4. Ustawa o zwalczaniu nieuczciwej konkurencji⁶

Są to trzy odrębne akty prawne i niestety nieco różne słownictwo zostało użyte w każdym z nich. Każda z nich rodzi inne zobowiązania⁷. Korzystając z zasady (logika rachunku zdań) zamiennego stosowania pojęć i ich definicji w zdaniu⁸, można uporządkować pojęcia użyte w tych umowach i doprowadzić do ich spójności w następujący sposób (model pojęciowy, notacja SBVR – diagram faktów, linia z pustym grotem wskazuje na pojęcie będące generalizacją, czytamy to np. zamawiający jest typem podmiotu prawa):

Z perspektywy umów o dzieło podmiotami (podmiot prawa) zawierającymi umowę są przyjmujący zamówienie i zamawiający. Przedmiotem umów o dzieło jest powstanie dzieła, produktu pracy przyjmującego zamówienie (s.j.p. produkt: coś co powstało).³ Zobowiązaniem zamawiającego jest dostarczenie przyjmującemu zamówienie, niezbędnych materiałów i zapewnienie ich odpowiedniej jakości. Materiały te to często treści, które mogą stanowić tajemnicę przedsiębiorstwa zamawiającego, ich ochrona (właściwe oznaczenie⁹) spoczywa na zamawiającym, który tu dostarcza ten materiał⁹.  Zobowiązaniem przyjmującego zamówienie jest dostarczenie określonego dzieła powstałego z użyciem otrzymanych materiałów (przypominam, że informacje to także materiał). Specyficznym typem dzieła jest utwór, w tym przypadku przyjmujący zamówienie jest także twórcą⁵.

Treść umowy musi zawierać opis tego co zamówił zamawiający, przyjmujący zamówienie musi wiedzieć i rozumieć co ma wykonać. Jeżeli wartość umowy przekroczy pewien próg ryzyka dla choćby jednej jednej ze stron, dostarczane przez zamawiającego materiały powinny być przekazywane w formie pisemnej (materiał dowodowy w razie sporu).

Wynagrodzenie w umowach o dzieło jest ustalane w momencie zawierania umowy, jednak są prawne możliwości jego zmiany w trakcie jej realizacji (Art. 630 KC), dlatego warto w tych umowach wpisywać także np. stawkę godzinową lub dzienną wynagrodzenia przyjmującego zamówienie na wypadek konieczności korekty wyceny.

Z perspektywy umów zlecenia, podmiotami (stronami) umowy są: dający zlecenie i przyjmujący zlecenie. Przedmiotem umowy zlecenia jest działanie przyjmującego zlecenie (zobowiązanie przyjmującego zlecenie do należytego wykonywania czynności prawnych) w imieniu dającego zlecenie.⁴ Tu realizacja umowy jest relatywnie prosta, bo przyjmujący zlecenie działa w imieniu dającego zlecenie (Art. 734 KC). W efekcie przyjmujący zlecenie ponosi odpowiedzialność wyłącznie za jakość swojej pracy a nie za powstający produkt, nadzór nad pracami sprawuje z zasady dający zlecenie.

W obu rodzajach umów pojawia się pojęcie przekazanego materiału, materiałem tym są tu często informacje. Art. 11. pkt. 4 Ustawy⁶ mówi:

Przez tajemnicę przedsiębiorstwa rozumie się nieujawnione do wiadomości publicznej informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, co do których przedsiębiorca podjął niezbędne działania w celu zachowania ich poufności.

Oznacza to, że podmiot dostarczający materiały odpowiada za ich prawidłowe oznaczenie, przyjmujące zamówienie lub zleceniobiorca, ma obowiązek ochrony otrzymanych materiałów zgodnie z wytycznymi  przekazującego te materiały. Często spotykam się z tezami prawników:

?Kara umowna zgodnie z prawem jest oderwana od szkody i jej rozmiaru. To znaczy nie trzeba wykazać szkody, aby móc otrzymać karę umowną. Nie możemy egzekwować szkody uznaniowo, a zamiast tę szkodę miarkować egzekwujemy całą karę umowną. Powyższe oparte jest na art. 484 Kodeksu cywilnego, zgodnie z którym: 1. W razie niewykonania lub nienależytego wykonania zobowiązania kara umowna należy się wierzycielowi w zastrzeżonej na ten wypadek wysokości bez względu na wysokość poniesionej szkody.?

Jednak Art.484. to dział zobowiązań, dotyczy dłużnika i jego zobowiązań z tytułu świadczeń umownych zaś zachowania poufności nie jest świadczeniem, to niezachowanie poufności jest naruszeniem ogólnie obowiązującego prawa. Kwestie ochrony informacji stanowiących tajemnicę przedsiębiorstwa reguluje USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji, w szczególności Art. 11. a możliwe sankcje za łamanie tego zakazu Art.18.i Art. 23 tej ustawy. Ewentualna szkoda spowodowana takim ujawnieniem wymaga jej wykazania przed sądem na zasadach ogólnych. Podpisywanie umów o zachowaniu poufności z klauzulami mówiącymi o jednostronnym orzekaniu o niedochowaniu obowiązku ochrony otrzymanych informacji i stosowaniu dorozumianych kar umownych przenosi całe ryzyko na zleceniobiorcę i nie ma uzasadnienia (jednak podpisanie takiej umowy to zgoda na tę praktykę).

Umowy cywilnoprawne mogą mieć charakter mieszany, jednak należy w takich przypadkach bardzo precyzyjnie definiować przedmioty tych umów, tak by nie było wątpliwości z czego konkretnie jest rozliczana  (kto i jakie ma zobowiązania) każda strona umowy.

Umowy na wykonanie i dostarczenie oprogramowana

Opiszę tu sytuację stanowiącą idealizację projektu informatycznego, którego zakresem jest dostarczenie oprogramowania. Idealizacja to metoda badawcza pozwalająca na stworzenie modelu sytuacji docelowej uznaną za idealną (optymistyczną), pozwalającego na ocenę stopnia wykonalności projektu lub osiągnięcia tego celu. Pozwala generalizować i abstrahować od zbędnych detali. Swego czasu opisywałem błędy popełniane często przez prawników w umowach, konkluzja była taka:

Jak więc nazwać przedmiot umowy? Autorzy [kanc. Maruta Wachta sp. j.] szukają nazwy dla pojęcia ?Oprogramowanie dostosowane do wymagań Umowy, w tym wymagań funkcjonalnych i pozafunkcjonalnych?. Rzecz w tym, że przedmiotem umowy może być (i z reguły jest) coś znacznie bardziej złożonego niż oprogramowanie, bo oprogramowanie ? jak już wyżej napisano ? nigdy samo z siebie nie jest ?czymś działającym?. Nie da się stwierdzić poprawności  działania oprogramowania bez jego uruchomienia na komputerze (w jakimś środowisku), dlatego samo oprogramowanie NIGDY nie powinno być przedmiotem umowy! W branży inżynierskiej, w IT także, mówi się o rozwiązaniach (tu informatycznych), które są systemami (ale system to pojęcie szersze, bo możemy mówić o systemie ochrony zdrowia, którego małą częścią będzie oprogramowanie). (żr.: Wzorcowe klauzule w umowach IT | | Jarosław Żeliński IT-Consulting)

Wdrażanie systemów IT, praktycznie zawsze jest (powinno być) umową o dzieło, zleceniem w tej umowie mogą być wybrane prace, tylko te co do których zleceniodawca ma przekonanie, że ma kompetencje do ich nadzoru.

Poniższy diagram obrazuje referencyjną realizację projektu dostarczenia oprogramowania  w postaci dwóch odrębnych etapów: Etap I to Umowa na projektowanie, Etap II to umowa na realizację projektu (tu projekt jako specyfikacja techniczna). Charakter tych umów (dzieło lub zlecenie) zależy od szczegółów ich treści. Tu przedstawiono sytuacje idealną: oba etapy to umowy o dzieło, w etapie drugim projektantowi (robi to Inwestor) zlecamy (zlecenie) nadzór autorski nad pracami Realizatora:

W pierwszym etapie Projektant dostarczy dzieło będące opisem tego, jakie oprogramowanie ma w drugim etapie dostarczyć podmiot realizujący dostawę oprogramowania. Materiałem jaki ma otrzymać przyjmujący zamówienie od zamawiającego, są wszelkie informacje do tego wymagane. Zobowiązaniem Projektanta jest opracowanie Projektu. projekt jest wymaganiem dla Realizatora, stanowi opis przedmiotu zamówienia (dla drugiego etapu).

-> Nie jest to wbrew pozorom, tak zwany wodospad, gdyż projekt nie musi (i nie powinien być) detaliczny a realizacja jednoetapowa. Obecny etap rozwoju inżynierii  oprogramowania operuje pojęciem architektury, projekt systemu to jego architektura, detaliczną konstrukcję projektuje Realizator, robi to dla każdego komponentu osobno (czytaj: metoda iteracyjno-przyrostowa tworzenia oprogramowania).

W drugim etapie, jakim jest pozyskanie przez inwestora potrzebnego mu oprogramowania, przedmiotem umowy (zobowiązaniem) jest także dzieło. Tu jednak jest to albo cudze dzieło (tu utwór) czyli dostarczana jest licencja na cudze oprogramowanie i usługa (zlecenie) jego wdrożenia, albo dzieło (oprogramowanie) jest produktem przyjmującego zamówienie (ten zobowiązuje się do jego wytworzenia i wdrożenia). W tym etapie materiałem dostarczonym przyjmującemu zamówienie jest produkt pierwszego etapu, czyli dzieło projektanta (Projekt) stanowiące opis przedmiotu zamówienia. Biorąc pod uwagą fakt, że jest to utwór (zakładam, że prawa majątkowe do Projektu zostały przekazane inwestorowi, co powinno mieć miejsce) jego autor, w ramach umowy zlecenia, sprawuje (w takich projektach z reguły płatny) nadzór autorski.

W przypadku gdy oprogramowanie powstaje w ramach umowy o dzieło, stanowi ono utwór. Jeżeli materiał dostarczony przez zamawiającego także stanowi utwór (produkt I Etapu) będący projektem, dostarczone oprogramowanie jest dziełem zależnym, co pokazano poniżej:

Zarówno Specyfikacja (jeżeli jest projektem) jak i Kod programu są utworami, Ważna uwaga: materiały opisowe zamawiającego przekazywane Projektantowi są ideą, dlatego Projektant tworzy utwór pierwotny  (Specyfikacja powinna być Projektem: metody opisu wymagań zorientowane na modele) a nie utwór zależny. Gdyby było inaczej, praca Projektanta była tu zbędna.

Podsumowanie

Podstawowym zaleceniem dla inwestorów jest oddzielanie etapów projektowania i realizacji oraz zlecenie realizacji tych etapów odrębnym podmiotom. Rok temu, pisząc o tym jak opracować przedmiot zamówienia zamawiając oprogramowanie, napisałem:

Najważniejszym celem porządkowania pojęć w umowach, są kwestie praw stron i ochrony know-how. Bez wyraźnego rozdzielenia praw do Specyfikacji i Kodu programu, pojawiają się ogromne problemy z ustaleniem praw stron. Na tym tle wszelkie formy prowadzenia projektów i wdrożeń ograniczające powstawanie dokumentów, szczególnie wszelkich Specyfikacji, popularnie zwane metodami zwinnymi (Agile), prowadzą do ogromnych problemów. Typową konsekwencją tak zwanego zwinnego podejścia, jest przejmowanie praw do know-how przez wykonawców (niestety często celowe): autor Kodu programu, który to kod powstał z pominięciem tworzenia Specyfikacji oprogramowania, wyłącznie na podstawie wywiadów z przyszłymi użytkownikami i ich przełożonymi, ma do tego kodu wszelkie prawa, a Zamawiający żadnych (musiał by je nabyć od twórcy kodu). (źr.: Przedmiot Zamówienia ? instrukcja nie tylko dla prawników, na zupę pomidorową | | Jarosław Żeliński IT-Consulting)

Uwagi na temat projektów z jakimi spotykam się jako biegły u moich klientów:

1. Jeżeli zamawiający zbyt ogólnie opisze przedmiot zamówienia w umowie, traci nad nią panowanie, jeżeli zaangażuje dostawce w formie umowy zlecenia, jako dający zlecenie praktycznie w 100% ponosi odpowiedzialność za uzyskane efekty (mimo, że nie ma do tego kompetencji merytorycznych).
2. Ustne zbieranie materiałów (tak zwane wywiady, warsztaty, burze mózgów) przez przyjmującego zamówienie, stanowi ogromne ryzyko dla zamawiającego, bo nie ma on żadnych możliwości dochodzenia swoich racji w sporach (brak dowodów). Podpisywanie notatek i raportów z takich spotkań niewiele zmienia, bo ich autorem jest przyjmujący zamówienie (to on prowadzi te warsztaty), który z reguły ma ogromną przewagę merytoryczną nad zamawiającym.
3. Połączenie tych dwóch etapów w jeden, i bezpośrednie zamówienie analizy i projektowania u dostawcy oprogramowania, na podstawie tylko ogólnego opisu jego cech, prowadzi do sytuacji, w której przyjmujący takie zamówienie (dostawca oprogramowania) sam sobie stawia wymagania, często forsuje formę umowy zlecenia, i zleceniodawca ponosi 100% ryzyka, bo nie ma wiedzy merytorycznej by nadzorować zleceniobiorcę a bierze na siebie całą odpowiedzialność za skutki jego pracy. Biorąc pod uwagę fakt, że idee (ogólny opis wymagań biznesowych) nie podlegają ochronie, prawa autorskie do tak powstałego oprogramowania pozostają przy jego tworcy.

Zalecenia dla inwestorów:

1. Z zasady dzielić projekty na dwa etapy: analizę i projektowanie oraz dostarczenie oprogramowania. Oba powinny realizować odrębne i niepowiązane podmioty (konflikt interesów).
2. Żądać by produktem pierwszego etapu był projekt oprogramowania a nie tylko specyfikacja wymagań, bo ta nie jest projektem.
3. Żądać od projektanta także usługi nadzoru autorskiego (jako projektant ponosi on także odpowiedzialność za dostarczony przez dostawcę oprogramowania produkt).
4. Żądać od dostawcy oprogramowania wykonania koncepcji wdrożenia (projekt implementacji), bo to gwarantuje możliwość dochodzenia odszkodowań od dostawcy oprogramowania. Jeżeli na etapie tworzenia koncepcji wdrożenia, przyjmujący zamówienie  nie zgłosi uwag do materiałów jakie dostał (projekt), ponosi wszelkie konsekwencje skutków swojej pracy.

Są to kluczowe ryzyka w projektach. Generalnie należy zawsze przestrzegać zasady by nie łączyć w projekcie ról stwarzających ryzyko konfliktu interesów.