Ministerstwo Cyfryzacji opublikowało Wzorcowe klauzule w umowach IT, jest to informacja do wersji pilotażowej (Opublikowano: 22.11.2017).

Klauzule zostały opracowane na zlecenie Ministra Cyfryzacji przez zespół kancelarii MARUTA WACHTA Sp. j. pod kierownictwem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich również uwagi pracowników administracji publicznej, zarówno prawników, jak i specjalistów z dziedziny IT. (źr. https://www.gov.pl/cyfryzacja/wzorcowe-klauzule-w-umowach-it)

Jako, że w podpisie napisano:

Bardzo mile widziane są wszelkie dalsze komentarze i uwagi do klauzul. Należy je przesyłać na adres: Klauzule@mc.gov.pl

Więc jako wieloletni teoretyk i praktyk, poczułem się w obowiązku takie uwagi zgłosić (te uwagi zostały także wysłane na powyższy adres, odpowiedzi nie otrzymałem).

Mimo, że to opracowanie powstało za pieniadze podatnika…

…zaskakuje mnie zapis na stronie MC: “klauzule nie mogą być wykorzystywane przez przedsiębiorców ani osoby fizyczne”

Po zapoznaniu się z dokumentem, uznałem, że uwagi swoje ograniczę do pierwszej części: Definicje. Zawiera ona definicje kluczowych pojęć wraz z komentarzami. Definicje pojęć są kluczowe dla zrozumienia umów i interpretowania ich zapisów w ich stosowaniu, a szczególnie w przypadku sporów. Innymi słowy, wady tej części umowy czynią wadliwą (ryzykowną) całą umowę. Pozwoliłem więc sobie na kilka uwag wyłącznie do tej części opracowania.

Pojęcie “błąd”

Autorzy rekomendują jego definiowanie w następujący sposób:

Błąd – nieprawidłowe działanie Oprogramowania, niezależnie od przyczyny takiej nieprawidłowości. W szczególności Błędem jest działanie Oprogramowania niezgodnie z Dokumentacją. Błędom przypisane są kategorie [opcjonalnie: priorytety].

W umowach bardzo często spotykam takie pojęcie błędu, jednak rodzi ono wiele problemów. Słownik języka polskiego podaje definicje:

błąd
1. niezgodność z obowiązującymi regułami pisania, liczenia, wymowy itp.
2. niewłaściwe posunięcie
3. fałszywe mniemanie o czymś

Są jednak jeszcze w języku polskim w użyciu pojęcia:

niezgodny
1. będący w sprzeczności z czymś
2. niedobrany w porównaniu z czymś innym

niesprawny
1. źle zorganizowany
2. niedziałający w ogóle lub działający wadliwie

awaria – uszkodzenie maszyny lub innego urządzenia technicznego

Jak widać, także w potocznym rozumieniu, popełnienie błędu dotyczy zachowań (niewłaściwe posunięcie, fałszywe mniemanie) lub ich skutków (uzyskanie złego wyniku). Oprogramowanie powstaje w wyniku umowy o dzieło, które to dzieło jest w umowie wyspecyfikowane (opisane). Tak więc oprogramowanie może być niezgodne z wymaganiami, z dołączoną instrukcją użytkownia np. oprogramowanie może generować błędne wyniki np. obliczeń (istotne jest to, czy powstało coś niezgodnie z wymaganiami, czy może jest to ludzki błąd autora kodu, to podobnie jak zamawianie opracowań: struktura treści jest niezgodna z zamówieniem, czy w treść wkradły się błędy).

Oprogramowanie stanowi także integralną część systemu informatycznego składającego się także ze sprzętu, może nim być nie tylko komputer służący do pisania lub księgowania ale także linia produkcyjna. Człowiek nigdy nie korzysta z samego oprogramowania, zawsze jest to jakieś urządzenie (komputer z edytorem tekstu, pralka z oprogramowaniem zamiast programatora mechanicznego, linia produkcyjna z oprogramowaniem sterującym, telefon komórkowy z oprogramowaniem do prowadzenia rozmów czy korzystania z Internetu itp.).

Tak więc z perspektywy użytkownika, korzysta on z całości urządzenia, nie wie on czy winą za stwierdzoną nieprawidłowość należy obciążyć akurat oprogramowanie (np. pralka nie pierze, system finansowo-księgowy nie księguje). Brak możliwości skorzystania z treści stron internetowych może być wynikiem awarii łącza internetowego, awarii komputera, błędu konfiguracji sieci Wi-Fi itp. Dlatego w umowach takich bezpieczniej jest użyć pojęcia zrozumiałego dla użytkownika, gdyż wtedy, nie będąc specjalistą, jest on w stanie stwierdzić niezgodność dostarczonego rozwiązania z opisem w umowie lub stwierdzić awarię urządzenia (systemu). Po drugie jedno urządzenie może zawierać więcej niż jedną aplikację, o czym użytkownik także może nie wiedzieć i nie będzie w stanie poprawnie (zgodnie z umową, skutecznie) zgłosić takiej wady. Mając tablet łatwo ocenić czy korzystając z niego uległ on awarii czy nie, ale stwierdzenie błędu konkretnego oprogramowania na nim zainstalowanego, może być niemożliwe dla nieprofesjonalisty.

W mojej ocenie, wymaganie od użytkownika rozumienia działania detali konstrukcyjnych urządzenia (wskazywanie, która aplikacja ‘błędnie” działa), które nabył, jest dużym nadużyciem, gdyż przewaga merytoryczna jego dostawcy, i takie formułowanie usterek jak w recenzowanym dokumencie (patrz do źródła, na końcu artykułu), powoduje trudność w dowodzeniu przed dostawcą tych nieprawidłowości, co autorzy sami przyznali w komentarzach.

W kwestii tworzenia kategorii awarii dość powszechnie przyjętą praktyką w inżynierii jest trzystopniowa ocena: w wyniku awarii (1) urządzenie stało się nieprzydatne, (2) urządzenie ma ograniczone możliwość użycia ale zachowuje przydatność, (3) spadł jedynie komfort korzystania z urządzenia. Dotyczy to także komputera z oprogramowaniem.

Pojęcie ?dokumentacja?

Zapewne jest to drobna “sprawa” ale tylko pozornie. W prawie operuje się pojęciem dokumentu (nie tylko elektronicznego) a nie ?dokumentacji? (nie licząc np. prawa budowlanego). Dlatego lepiej jest napisać, że ?dokument zawierający/opisujący? coś to ?dokumentacja czegoś? (dokumentacja może być “dokumentem” elektronicznym, papierowym). Jeżeli mają być stosowane kategorie lub typy dokumentacji, to logika tworzenia taksonomii nakazuje użycie typów: dokumentacja techniczna, dokumentacja analityczna, dokumentacja projektowa. Zamiast więc definiować pojęcie ?analiza? lepiej jest formułować treść zapisu umowy w postaci ?dokument zawierający treść analizy (jakiej, czego)?, bo wtedy samo ?analiza? nie kwalifikuje ?tego czegoś? jako dokumentu lub ?dokumentacji?, nie wiemy też czy “analiza” jest dokumentem czy pracą nad jego stworzeniem (przyjęte jest w nauce, że analiza i analizowanie to praca a nie przedmiot, podobnie jak operacja i operowanie).

Pojęcie “oprogramowanie”

Słownik języka polskiego:

oprogramowanie ?zbiór programów wprowadzonych do komputera?
program ?ciąg instrukcji napisanych w języku zrozumiałym dla komputera?
aplikacja ?komputerowy program użytkowy?

Autorzy wzoru jednak rekomendują:

Oprogramowanie ? całość lub dowolny element oprogramowania dostarczanego lub wykonywanego w ramach realizacji Umowy.

Nie rozumiem powodów, dla których w umowie, która w trakcie sporu, będzie z zasady interpretowana w języku polskim, ale też w tym języku intuicyjnie będzie prowadzona korespondencja pomiędzy stronami umowy, zmieniono definicję słownikową. Wprowadzanie typów oprogramowania: aplikacyjne, systemowe, dedykowane, itp.. (brakuje jednak dla konsekwencji niededykowanego) nie stanowi żadnej wartości, wręcz zaciemnia obraz, a o roli tego oprogramowania decydują cechy użytkowe a nie nadana mu nazwa (np. z perspektywy administratora serwera aplikacje wspomagające jego pracę są aplikacjami użytkowymi, dla przeciętnego człowieka są to ?programy administracyjne?). Po drugie wprowadzanie takich nazw nie pomaga a przeszkadza w stosowaniu pojęcia błędu/niezgodności/awarii.

Pojęcie “system”,  a może jednak “rozwiązanie”

I w tym momencie wręcz kuriozalne wydaje się wprowadzenie pojęcia system w brzmieniu:

System ? Oprogramowanie dostosowane do wymagań Umowy, w tym wymagań funkcjonalnych i pozafunkcjonalnych

Czyżby oprogramowanie gotowe “z pudełka”, będące przedmiotem umowy nie było by systemem (albo jego częścią)? Pojęcie system w inżynierii ma dość precyzyjne i ogólniejsze znaczenie, słownik języka polskiego podaje:

system
1. ?układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość?
2. ?zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość?

Tak więc komputer z oprogramowaniem, nowoczesna linia produkcyjna itp. To są systemy, częścią każdego z nich jest wiele różnych aplikacji, każda z nich to program komputerowy. Pojęcie “system”od wielu lat ma zdefiniowane, zarówno naukowe i branżowe znaczenie: “dowolny twór pojęciowy lub fizyczny, składając się z części wzajemnie powiązanych i oddziaływających na siebie” (Bertalanffy, Ackof), “zbiór elementów i związków między nimi zdolny to realizowania określonych celów” (www.omg.org, Model Driven Engineering).

Autorzy piszą, że ?System stanowi dzieło w rozumieniu przepisów kodeksu cywilnego?. Kodeks Cywilny podaje:

Umowa o dzieło
Art. 627. Przez umowę o dzieło przyjmujący zamówienie zobowiązuje się do wykonania oznaczonego dzieła, a zamawiający do zapłaty wynagrodzenia.

KC nie definiuje pojęcia dzieło, jednak słownik języka polskiego wydaje się wystarczająco precyzyjny:

dzieło
1. ?utwór literacki, naukowy lub artystyczny, zwłaszcza dużej wartości?
3. ?efekt czyjejś pracy lub jakichś procesów?

Ustawa Prawo autorskie… stwierdza:

Przedmiot prawa autorskiego
Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór).

Tak więc w prosty sposób wywodzimy, że każdy utwór to dzieło (ale uwaga: nie każde dzieło to utwór). Tak więc dziełem jest zarówno dokumentacja jak i oprogramowanie (patrz Ustawa o prawach autorskich ?). Jako, że dostarczenie “działającego systemu? jest określonym efektem, działać może dopiero oprogramowanie zainstalowane na komputerze, wykonanie oprogramowania (utwór) i dostarczenie lub zainstalowanie go na komputerze (dopiero) jest dziełem (samo oprogramowanie jako utwór, to także – odrębne – dzieło). O ile tylko ten efekt (dzieło) został precyzyjnie opisany w dokumentacji stanowiącej Opis Przedmiotu Zamówienia (czyli w umowie) jest on przedmiotem tej umowy. Opis ten musi być jednak na tyle precyzyjny, by zamawiający był w stanie stwierdzić ewentualne niezgodności z tym opisem, a także stwierdzić wystąpienie ewentualnej awarii, czyli jest w stanie stwierdzić, że dostawca wywiązał się należycie z umowy.

Jak więc nazwać przedmiot umowy? 

Autorzy 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 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).

Słownik języka polskiego mówi:

rozwiązanie ?projekt i realizacja założeń architektonicznych, konstrukcyjnych, plastycznych itp.?

Skoro więc uznać, że “systemy informatyczne są i do czegoś służą”, że są wdrażane z określanego, często biznesowego, powodu, należy więc mówić o “rozwiązaniach”, bo wymagania biznesowe opisują rozwiązanie biznesowego problemu. “Rozwiązaniem” problemu (cel biznesowy) jest wdrożenie oprogramowania czyli jego wytworzenie, dostarczenie, uruchomienie oraz dostosowanie do niego istniejących procedur, przeprowadzenie szkoleń użytkowników. Trudno sobie wyobrazić poważną umowę na dostarczenie oprogramowania w postaci przysłania pudełka z kodem na nośniku. Autorzy wspominają o SLA, czyli z góry zakładają, że przedmiotem umowy jest właśnie “całe rozwiązanie” (lub znaczna jego część) a nie tylko “oprogramowanie dostosowane do wymagań Umowy, w tym wymagań funkcjonalnych i pozafunkcjonalnych”.

Tak wiec przedmiotem umowy, pojęciem użytym do jego nazwania, opisującej nietrywialny projekt techniczno-organizacyjny,  raczej powinno być słowo rozwiązanie.

Na zakończenie

Autorzy piszą:

Definicje są jednym z najtrudniejszych do opracowania elementów umowy. Nie istnieją wypracowane jednoznaczne standardy, definicje różnią się w zależności od projektu, a wielu pojęć nie da się zdefiniować w pełni precyzyjnie. Podane propozycje powinny być dokładnie zweryfikowane i zmodyfikowane na potrzeby konkretnej umowy.

Należy się zgodzić z tym, że definiowanie pojęć jest bardzo trudne, jednak teza, że nie istnieją standardy nie jest prawdą (autorzy w dokumencie, przecząc sobie, przywołują standard jakim jest ITIL). Teza, że pewnych pojęć nie da się zdefiniować precyzyjnie, jest w moich oczach nadużyciem, gdyż albo w umowie pojęcie definiujemy, co pozwala użyć go w celu zachowania jednoznaczności treści zapisów umowy, albo nie należy stosować tych definicji. Definicje pojęć, poprawnie zbudowane, stanowią kryterium pozwalające jednoznacznie zaklasyfikować np. zdarzenie jako awarię. Jeżeli definicja na to nie pozwala, skuteczne zgłoszenie awarii staje się wątpliwe (niemożliwe?).

Wielu autorów książek, nie tylko w branży IT, standaryzuje pojęcia jakich używa w swoich opracowaniach, każda branża ma swoje, wypracowane jako standardy lub zalecenia, definicje pojęć, część ma swoje źródło w opracowaniach naukowych. Prowadzę i ja taki słownik, jest opublikowany, pomaga  mi w komunikacji, także  na tym blogu: Słownik pojęć. O tworzeniu definicji pojęć pisałem także tu: Słownik pojęć biznesowych: najbardziej podstawowe wymaganie.

Projekty inżynierskie to projekty multidyscyplinarne, opisanie przedmiotu umowy w projektach inżynierskich jest trudne, dlatego moim zdaniem należy przykładać ogromną wage do precyzji formułowania treści takich umów. Jestem zdania, że podobnie jak to ma miejsce w innych dziedzinach inżynierii, tu (inżynieria oprogramowania) także należy stosować uznane metody opisu dzieła w postaci schematów blokowych, gdyż słowami nie zawsze łatwo (nie raz jest to wręcz niemożliwe) opisać inżynierską konstrukcję (system). Projekty informatyczne cechują się coraz większą złożonością. Myślę, że nikt w dzisiejszych czasach nie wyobraża sobie zawarcia umowy na wykonanie inwestycji budowlanej, z użyciem wyłącznie tekstu jako opisu dzieła. Jest to praktycznie niemożliwe. Dlatego brnięcie w opisy tekstowe przedmiotów umów na dostarczanie nietrywialnych (autorzy wspominają o projektach wysokiej wartości) systemów informatycznych należy dzisiaj uznać za poważny błąd. Oprogramowanie ma także swoją specyfikę: jest to byt wirtualny, dlatego tym bardziej precyzja stosowanych pojęć staje się kluczowa dla powodzenia tych projektów.

Dokument recenzowany:
https://www.gov.pl/documents/31305/0/umowa_wdrozeniowa_z_uslugami_utrzymania_-_wzorcowe_klauzule_komentarz_cz_i.pdf

P.S.

Jako ciąg dalszy polecam artykuł Opis Przedmiotu Zamówienia ? instrukcja nie tylko dla prawników.