Wprowadzenie

W roku 2017 komentowałem dokument, który Ministerstwo Cyfryzacji opublikowało (Opublikowano: 22.11.2017), zatytułowany “Wzorcowe klauzule w umowach IT”. Czytam tam między innymi:

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)

Moje uwagi umieściłem we wpisie: Wzorcowe klauzule w umowach IT. Gorąco polecam przeczytanie, opisałem tam kwestie słownika w Umowie, który jest kluczem dla brzmienia Umowy i jej późniejszej interpretacji. Te klauzule nadal są oficjalne na stronie Ministerstwa Cyfryzacji. Na otwartą prośbę Ministerstwa doręczyłem swoje krytyczne uwagi, do dziś nie dostałem żadnej odpowiedzi. To było w 2017 roku.

12 grudnia 2023 r. (wtorek) o godz. 10:00 miała miejsce prezentacja (webinar on-line) prowadzona przez prawników kancelarii Lawspective Litwiński Valirakis Radcowie Prawni Sp. k.. zatytułowana “Przed Tobą wdrożenie systemu IT?” link do źródła: https://www.linkedin.com/feed/update/urn%3Ali%3Aactivity%3A7134871019667808260/

Od strony prawnej trudno cokolwiek zarzucić prelegentom. Niestety prezenterzy powielają “mity” głoszone przez dostawców oprogramowania. Generalnie polecam obejrzenie prezentacji (prawa i miejsce prezentacji należą do ww. kancelarii).

Tu odniosę do niektórych kwestii dotyczących inżynierii oprogramowania i jej styku z prawem autorskim oraz z know-how. To te miejsca, w których – mom zdaniem – prawnicy Ci wykazali się niestety zupełnym brakiem wiedzy i zrozumienia tego czym jest oprogramowanie, jego tworzenie i wdrażanie. Momentami nawet rekomendowali szkodliwe zapisy w umowach na wdrożenia.

Wymagania: nie piszcie sami (NIE UCZCIE SIE NA SOBIE)

Zapisano wiele papieru na temat niespójności specyfikacji opracowywanych metodami burzy mózgów spisanych językiem naturalnym, jedna z nich poniżej:

Šenkýř, D.; Kroha, P. Problem of Incompleteness in Textual Requirements Specification: In Proceedings of the 14th International Conference on Software Technologies; SCITEPRESS – Science and Technology Publications: Prague, Czech Republic, 2019; pp 323–330. https://doi.org/10.5220/0007978003230330.

Wymagania na oprogramowanie to nie lista życzeń. Deweloper to firma inżynierska, powinna dostać projekt techniczny jako wymaganie.

Jeżeli ktoś Ci mówi, żeby nie pisać umowy samemu i skorzystać z pomocy prawnika, to ja powiem: nie pisz wymagań sam, skorzystaj z usług projektanta.

Kastomizacje vs. rozwiązania dedykowane

Kastomizacje? Jednym słowem: NIGDY. Bo stracisz gwarancję producenta, a jak nie masz rękojmi usługodawcy, to już nikt Ci nie pomoże. Tu więcej: Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Prawa autorskie

To kontynuacja poprzedniego punktu: Jak licencja to na oprogramowanie standardowe, jak autorskie prawa majątkowe, to z zasady do dedykowanej dla Ciebie części: moduły dedykowane tworzymy zawsze osobno i zintegrowane (jeżeli to możliwe, to w tej samej technologii i środowisku co integrowane systemu). Jednak prawa majątkowe do elementów dedykowanych i sugestia, że to ekstra koszt (za przekazanie praw majątkowych) to jest to nadużycie ze strony dostawcy (polecam tu lekturę wpisu: Prawo autorskie w projektach IT)

Uzależnienie od dostawcy

Jeżeli ktoś pozwolił się uzależnić od dostawcy to jest to na prawdę dramat, ale można tego uniknąć. Jak? Należy mieć DOKUMENTACJĘ tego jak działa oprogramowanie. Oprogramowanie standardowe powinno mieć co najmniej podręcznik użytkownika. Oprogramowanie dedykowane powinno mieć dokładną specyfikację mechanizmów działania (architektura, algorytmy, użyte metody). Brak dokumentacji prowadzi do sytuacji gdy tylko wykonawca zna mechanizm działania oprogramowanie i w efekcie ma monopol na usługi utrzymania i rozwoju, a tego nie chcemy. Oczywiście, prawa majątkowe do dedykowanego oprogramowania z zasady u zamawiającego i bez dopłaty.

Migracja

Każde nowe wdrożenie w obecnych czasach, to migracja ze starych rozwiązań do nowego. Problem w tym, że znakomita większość aplikacji jest zbudowana na tak zwanych relacyjnych bazach danych. Taka baza to setki wzajemnie połączonych tabel. problem w tym, że każda aplikacja ma inny układ tych tabel. W efekcie przeniesienie danych z jednej takiej struktury do drugiej w 100% jest praktycznie niemożliwe.

Nawet jeżeli dostawca obiecuje taką migrację, bardzo często okazuje się, że jest bardzo kosztowna, nie obejmuje wszystkich danych i bardzo często nie jest potrzebna. Z reguły wystarczy przeniesienie do nowego systemu kilku kluczowych rejestrów i słowników. Resztę można udostępnić innymi, tańszymi i pewniejszymi metodami.

Integracja

Integracja i wyimaginowany jej wielki koszt to jeden z kluczowych “straszaków” form oferujących stare, monolityczne ERP. Dzisiaj nie ma możliwości wdrożenia czegokolwiek bez integracji, bo żadna działalność gospodarcza nie mieści się w granicach jednej aplikacji. Po drugie tak zwana digitalizacja to nic innego jak integracja systemów informatycznych firmy, jej partnerów handlowych i instytucji publicznych (ze skarbówką na czele). Kluczem jest to, by te integrację zrozumieć i zaprojektować przed wyborem dostawcy oprogramowania (integracja powinna być wymaganiem).

Chmura

Temat rzeka, często słyszę (tu prawnicy także to sugerowali), że to dostawca w ofercie proponuje (lub nie) rozwiązanie chmurowe. Nic bardziej błędnego: taka decyzja powinna być konsekwencją strategii firmy (należy taką mieć) a nie dostawcy oprogramowania (który z zasad oferuje rozwiązania korzystane dla niego). Wykonawca nigdy nie powinien sam decydować o tym czy system jest lokalnie instalowany czy w chmurze.

Harmonogram

Prawnicy mówią: w umowie musi być harmonogram wdrożenia. A jakim cudem, skoro nie ma projektu tego systemu, bo “analiza wymagań i analiza przedwdrożeniowa oraz projekt systemu” to treść zlecenia dla tego dostawcy oprogramowania? Brak projektu technicznego oznacza, że zbudowanie harmonogramu jest niemożliwe bo na etapie zawierania umowy dostawca nie wie co ma powstać! Przecież nie było jeszcze żadnej analizy!

Współdziałanie

Jest to bardzo ważna część zawieranej umowy. Podstawą współdziałania jest opis tego JAKIE i W JAKIEJ postaci materiały ma dostarczać zamawiający oraz w jakim terminie. Ale to dotyczy także DOSTAWCY, który nie powinien być świętą krową. Email i telefon, spotkania, jako metoda komunikacji to DRAMAT. Podobnym dramatem są tablice on-line typu MIRO. Kluczowym celem komunikacji w projekcie jest wiedza: KTO, CO, KIEDY I DO KOGO NAPISAŁ. Nie mniej kluczowe jest to, by dokumentacja systemu (patrz wpis: Opis Techniczny Oprogramowania) nie była zlepkiem notatek i ustaleń z niekończących sie spotkań, kolekcjonowanych od dnia podpisania umowy. Powinien to być jeden, spójny, aktualizowany dokument mający jawnie wskazanego autora. Współdziałanie to umowa SLA na wzajemną komunikację obowiązująca jednakowo obie strony umowy.

Umowa

Co do kwestii czysto cywilno-prawnych nie odnoszę się, bo tu detale to w 100% kompetencje prawników.

Jednak umowa na dostarczenie i wdrożenie oprogramowania była umową o dzieło, która musi zawierać OPIS PRZEDMIOTU ZAMÓWIENIA. Tym opisem powinien być opis techniczny oprogramowania. Przedmiot takiej umowy (szczególnie logika biznesowa) jest często tajemnicą przedsiębiorstwa.

Tu zwracam uwagę, że sam cel zamawiającego, jakim jest wdrożenie czegoś nieopisanego, nie jest takim opisem. Niestety nie są chronione prawem same spisane funkcjonalności programu czyli specyfikacja (lista) wymagań funkcjonalnych (wyrok SA w Poznaniu z dnia 4 stycznia 1995 r. I ACr 422/94). Precyzję opisu dającą ochronę uzyskuje się dopiero opracowując projekt stosując wzory matematyczne, algorytmy, unikalne struktury i schematy blokowe opisujące mechanizmy działania i struktury informacji.

Kolejna ważna rzecz, to konsekwencja powyższego: umowa powinna zawierać rolę generalnego projektanta/architekta systemu, który powinien być po stronie zamawiającego (analogicznie jak w każdej innej inżynierii).

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem

 (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Zapis o możliwości dobrowolnego odstąpienie od umowy, bez żadnych kar i bez podawania przyczyny (zaprzestanie współpracy), powinno być w nią wpisane, jako obrona przed vendor lock-in i jakimkolwiek perswazyjnym szantażem (dotyczy to obu stron umowy).

Wdrożenie

Jeżeli wdrożenie prowadzi partner producenta oprogramowania, wyłączenie rękojmi w umowie z pośrednikiem to samobójstwo. Gwarancje z zasady daje producent a wyłączanie rękojmi w takich wdrożeniach to nie jest żaden zwyczaj tylko manipulacja dostawcy! Tak więc partner producenta, który nie ma prawa udzielenia gwarancji na nie swój produkt, powinien udzielić rękojmi. W przeciwnym wypadku każdą niezgodność oprogramowania z jego opisem, kupujący będzie musiał osobiście wyjaśniać z jego producentem: życzę powodzenia w kontaktach z amerykańskimi firmami i nie nie tylko amerykańskimi.

Umowa z dostawcą powinna zawierać zapis o tym, że dostawca (producent) ponosi skutki wadliwości praw autorskich w umowach, to ZAWSZE można wynegocjować, a nawet należy tego żądać.

Umowy zwane “wdrożenie agile” … odradzam :). Dlaczego? Bo nie zawierają opisu przedmiotu umowy innego niż staranne działanie, a w takim przypadku odpowiedzialność za uzyskany efekt w całości spada na zamawiającego.

Odbiór

Przedmiotem odbioru jest co do zasady Przedmiot Zamówienia, więc jego precyzyjny opis powinien być załącznikiem do umowy. Przypomnę że, lista funkcjonalności nie powinna być przedmiotem umowy z dostawcą/wykonawcą oprogramowania : idea systemu nie jest opisem systemu. Taką umowę (funkcjonalności jako wymagania) można zawrzeć wcześniej z projektantem, gdzie przedmiotem umowy jest opracowanie opisu technicznego i – coraz częściej – nadzór autorski w toku pracy (patrz wyżej generalny projektant).

Bardzo ważna rzecz: NIE JEST PRAWDĄ ŻE SYSTEM MOŻE MIEĆ BŁĘDY w TRAKCIE ODBIORU!!!!!!! Wskazówką może tu być podział oprogramowania na niezależne moduły/komponenty, wtedy można je odbierać niezależnie, ale odbierany moduł nie moze mieć błędów!

Przedmiotem umowy i odbioru nie powinno być “oprogramowanie” a “działający komputer”!

Podsumowanie

Powyższe to, poparte okresem 20 lat reprezentacji nabywców oprogramowania, rekomendacje. Nie jedyne, bo na moim blogu znajdziesz czytelniku więcej takich. Powyższe nie wyczerpuje problemów w umowach, celem moim było zwrócenie uwagi na częste propozycje wielu prawników, pokazujące, że zawarcie umowy na wdrożenie oprogramowania, bez merytorycznego wsparcia (jak sie okazuje prawnik nim nie jest) jest ogromnym ryzykiem.

Biorąc pod uwagę fakt, że z zasady dostawca zaawansowanych technologii ma ogromną przewagę merytoryczną nad swoim klientem, niezapewnienie sobie, po swojej stronie, eksperta z dziedziny inżynierii oprogramowania, to prosta droga do kłopotów.

Jeżeli Twój prawnik ma inne zdanie to, zanim podpiszesz niekorzystną dla siebie umowę, zapraszam na spotkanie. Z jakiegoś nieznanego mi powodu, prawnicy często bezgranicznie wierzą dostawcom oprogramowania mimo, że nie rozumieją tego co jest przedmiotem tych umów. A nabywcy oprogramowania bezgranicznie zaś wierzą tym prawnikom. Ot taka zabawa w głuchy telefon, w której dostawca oprogramowania najczęściej wygrywa.

Taka ciekawostka: fraza “ERP implementation failure” w Goole, wynik: ok. “5,330,000 results”. Czyli generalnie ryzyko jest bardzo duże. Zwracam uwagę, że skrót ERP w prasie branżowej i w blogach, w zasadzie z zasady oznacza znane monolityczne produkty w tej kategorii.

Wprowadzenie

Nieco ponad dwa lata temu napisałem, że od lat stosuję w swoich analizach i projektach (między innymi) różnego rodzaju diagramy. Pomagają one ustalić precyzyjnie wszelkie aspekty i prawne i projektowe w umowach, do czego gorąco zachęcam. Niestety wielu prawników przyjmuje za cel swojej pracy ?obudowanie? paragrafami tego, czego żądają  od nich w umowach ich klienci. Owszem firmy płacą prawnikom za to, że Ci chronią ich interes, ale wiele z tych umów to niestety manipulacje i korzystanie z niewiedzy partnera, nie raz z jego gorszej znajomości (niezrozumienia) prawa. ?(Żeliński, 2017)?

W tym artykule kilka uzupełnień, gdyż uważam że warto nie zapominać o tym, że termin ten (Opis Przedmiotu Zamówienia, dalej OPZ) nie dotyczy tylko (jak się potocznie uważa) Zamówień Publicznych.

Czym jest OPZ

Jednak Prawo Zamówień Publicznych “ładnie” opisuje czym jest OPZ. A celem jest tu zachęta do tego, by OPZ zawsze wyłączać z treści umowy, jako jej załącznik. Na początek polecam w tym miejscu świetny tekst napisany okiem prawnika:

Zdarza się wam czasem otworzyć plik z umową i po przejrzeniu kilku akapitów zastanawiać się czy aby na pewno posługujecie się tym samym językiem? Lękiem napawa już sam paragraf z definicjami, który kończy się na?czwartej stronie? A kolejne nasuwają skojarzenia z szatańskimi wersetami? […] Jeżeli twój prawnik rozumie kontrakt lepiej niż twoi ludzie z biznesu, oznacza to że zarówno prawnik może mieć problem z tłumaczeniem prawnych komponentów całej transakcji, ale także że twój biznes w niewłaściwy sposób komunikuje prawnikowi cele i założenia biznesu, którego umowa dotyczy. Może czas coś z tym zrobić? ?(Lewicka, 2018)?

Prawnik to nie jest osoba, która wie (zna się na tym) co jest przedmiotem zamówienia, powinna (analogicznie jak sędzia, i z tego samego powodu) korzystać z wiedzy biegłego. Skoro tak, to OPZ, szczególnie gdy jest to rozwiązanie techniczne, nie powinien być treścią części prawnej umowy, powinien być do niej załącznikiem.

Pojęcie przedmiot zamówienia, zgodnie z Kodeksem Cywilnym, jako opis tego czego oczekuje Zamawiający od Dostawcy, dotyczy każdego zamówienia. Dlatego każda umowa, o ile tylko dotyczy zakupu usługi lub przedmiotu materialnego, nie tylko ta z podmiotem publicznym, powinna zawierać wyodrębniony Opis Przedmiotu Zamówienia.

Ustawodawca pisze ?(?Ustawa z dnia 29 stycznia 2004 r. Prawo zamówień publicznych,? 2004)?:

Art. 29. Opis przedmiotu zamówienia

1. Przedmiot zamówienia opisuje się w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wszystkie wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty.

[…]

3b. Zamawiający może określić w opisie przedmiotu zamówienia konieczność przeniesienia praw własności intelektualnej lub udzielenia licencji.

Jak widać, opis ten powinien spełniać określone rygory, kluczem jest zaś to, że opis ten służy do złożenia oferty, a ta – po jej przyjęciu – wiąże kupującego w umowie. To główny powód by OPZ był załącznikiem, odrębnym bytem wydzielonym z umowy.

Dialog podmiotu szukającego odpowiedniego dla siebie produktu lub usługi, z dostawcami, wygląda z reguły podobnie jak dialog: “A – Kto mi sprzeda Jabłko?, B- Ja sprzedam Jabłko za 2 zł!, A – Poproszę to Jabłko i płacę.” Słowo Jabłko powtarza się w całym tym dialogu, i jest to nic innego jak przedmiot zapytania, przedmiot oferty i przedmiot umowy zakupu, czyli jest to to samo. Rozsądek więc, co najmniej, nakazuje, by był to także ten sam i taki sam opis (ten sam dokument).

Ważna rzecz: opis usługi, np. wsparcia technicznego i utrzymania, też powinna stanowić OPZ a nie treść umowy, z tego samego powodu: wykorzystuje język techniczny i opisuje techniczne aspekty przedmiotu zapytania i oferty zarazem.

Jeżeli dochodzi do negocjacji, to należy pamiętać, że ich przedmiotem powinien być zakres opisany w OPZ, a skutkiem cena. W przypadku PZP takie negocjacje (zmiana OPZ) w zasadzie nie mogą mieć miejsca, ostatnim czasem na nie jest dialog techniczny.

W przypadku postępowania prowadzonego przez podmiot nie podlegający PZP, negocjacje są jak najbardziej możliwe a nie raz wskazane, gdyż w zasadzie pełnią rolę dialogu technicznego.

Kolejna ważna rzecz, o której nie raz pisałem: kto jest autorem OPZ? I tu już w kontekście powyższego widać, że nie ma sensu by wymagania na oprogramowanie pisał przyszły jego dostawca dopiero po zawarciu umowy. Ustawodawca i sądy, zwracają uwagę, że to Zamawiający ma dostarczyć opis przedmiotu zamówienia, a wykonawca ma wyjaśnić wszelkie swoje wątpliwości w toku składania oferty.

Odpowiednikiem obowiązku należytego opisania przedmiotu zamówienia leżącego po stronie zamawiającego jest obowiązek wykonawcy zadbania o doprecyzowanie i wyjaśnienie wszelkich aspektów zamówienia istotnych dla jego prawidłowego wykonania. O tym, że nie jest to obowiązek jedynie teoretyczny przekonywał Sąd Najwyższy w wyroku z dnia 5 czerwca 2014 r w sprawie o sygn. IV CSK 626/2013. Sąd stwierdził, iż niektórych ?okolicznościach składanego i przyjmowanego zamówienia publicznego oraz wątpliwości występujących po stronie wykonawcy, art. 38 p.z.p. stanowi w związku z art. 354 § 2 k.c. nie tylko uprawnienie, ale także obowiązek wykonawcy zwrócenia się do zamawiającego o wyjaśnienie treści SIWZ; zaniechanie tej powinności może być podstawą zarzucenia wykonawcy niedochowania należytej staranności wymaganej od przedsiębiorcy przez art. 355 § 2 k.c.?Rozstrzygnięcie Sądu Najwyższego ma fundamentalne znaczenie dla praktyki wykonywania umów w sprawie zamówienia publicznego.?(Wójcik, 2015)?

Innymi słowy, złożenie oferty jest oświadczeniem Wykonawcy o braku wątpliwości co do treści zapytania, w szczególności co do treści Opisu Przedmiotu Zamówienia.

Tak więc:

Podsumowując, opis przedmiotu zamówienia musi być:

1)      jednoznaczny ? niebudzący wątpliwości, dopuszczający tylko jedną możliwość interpretacyjna;

2)      wyczerpujący ? przedstawiający dane zagadnienia wszechstronnie, szczegółowo; gruntowny, dokładny;

3)      sporządzony za pomocą dokładnych i zrozumiałych określeń, przy użyciu sformułowań, które są w danej branży zrozumiałe, choć nie muszą być znane ogółowi.?(?OPIS PRZEDMIOTU ZAMÓWIENIA,? 2018)?

Jaki z tego wniosek dla pracowników firm, i ich prawników, budujących treść umów i dokumentów stanowiących Specyfikacje Istotnych Warunków Zamówienia czy po prostu tylko zapytania ofertowe?

…na zamawiającym spoczywa obowiązek jasnego i precyzyjnego określenia przedmiotu zamówienia, a co za tym idzie, wykorzystania do jego opisania standardowych określeń technicznych, które są zwykle używane w danej dziedzinie, zrozumiałych dla wszystkich osób trudniących się działalnością w danej branży.?(Urząd Zamówień Publicznych, n.d.)?

Biorąc pod uwagę powyższe oraz to, że mowa tu o produktach inżynierskich (oprogramowanie) rekomenduje się:

1. Opracowanie OPZ w postaci precyzyjnych schematów blokowych i wzorów matematycznych, jest zawsze lepsze niż niejednoznaczny opis wykonany językiem naturalnym, ten może być co najwyżej uzupełnieniem lub komentarzem. Ideałem jest tu precyzyjna dokumentacja techniczna (projekt techniczny). Należy pamiętać, że taki OPZ (w odróżnieniu od SIWZ) jest zawsze przedmiotem prawa autorskiego ?(Koralewski, 2014)?.^?*?
2. OPZ, będący dokumentem technicznym, specjalistycznym, nie musi być zrozumiały dla prawnika, a nie raz nawet dla samego Zamawiającego.
3. Jeżeli sam zamawiający nie potrafi stworzyć poprawnego OPZ, powinien najpierw zlecić usługę opracowania OPZ, a potem dopiero szukać dostawcy tego, co opisano w tym OPZ. ?(Urząd Zamówień Publicznych, 2009)?.
4. Usługa techniczna, oczekiwany sposób jej świadczenia, i jakość, to także przedmiot zamówienia, skuteczną praktyką jest więc umieszczenie ich opisu w OPZ a nie w treści umowy.?(Urząd Zamówień Publicznych, 2009)?

Źródła

• ^?
  Sąd Najwyższy wielokrotnie wskazywał, że utworem podlegającym ochronie prawnoautorskiej jest każde dzieło, jeśli przynajmniej pod względem formy wskazuje pewne elementy twórcze, choćby minimalne (wyrok Sądu Najwyższego z 31 marca 1953 r.; sygn. akt II C 834/52).

1. Koralewski, M. (2014, April 28). Trzeba uważać na prawo autorskie w przetargach. Retrieved June 28, 2019, from portalzp.pl website: https://www.portalzp.pl/top-tematy/trzeba-uwazac-na-prawo-autorskie-w-przetargach-1065.html
2. Lewicka, R. W. (2018, March 7). TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK. Retrieved June 28, 2019, from LinkedIn.com website: https://www.linkedin.com/pulse/twój-prawnik-rozumie-kontrakt-lepiej-niż-twoi-ludzie-warchol-lewicka/
3. OPIS PRZEDMIOTU ZAMÓWIENIA. (2018, May 30). Retrieved June 28, 2019, from Portal Zamówień Publicznych website: https://www.portalzp.pl/o/opis-przedmiotu-zamowienia-8904.html
4. Urząd Zamówień Publicznych. (2009). UDZIELANIE ZAMÓWIEŃ PUBLICZNYCH NA SYSTEMY INFORMATYCZNE (p. 33) [REKOMENDACJE]. Urząd Zamówień Publicznych.
5. Urząd Zamówień Publicznych. (n.d.). Opinia dotycząca opisu przedmiotu zamówienia. Retrieved June 28, 2019, from Urząd Zamówień Publicznych website:
6. Ustawa z dnia 29 stycznia 2004 r. Prawo zamówień publicznych. (2004, February 9). Retrieved June 28, 2019, from Internetowy System Aktów Prawnych website: http://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20040190177
7. Wójcik, P. (2015, May 25). Precyzyjny opis przedmiotu zamówienia to obowiązek zamawiającego. Retrieved June 28, 2019, from Prawo.pl website: https://www.prawo.pl/samorzad/precyzyjny-opis-przedmiotu-zamowienia-to-obowiazek-zamawiajacego,230550.html
8. Żeliński, J. (2017, February 16). Przedmiot Zamówienia ? instrukcja nie tylko dla prawników, na zupę pomidorową. Retrieved June 28, 2019, from IT-Consulting.pl website: https://it-consulting.pl//2017/02/16/przedmiot-zamowienia-instrukcja-dla-prawnikow-na-zupe-pomidorowa/

Pojęcie nadzoru autorskiego budzi wiele emocji, w branży IT jest to chyba temat tabu, głównie z powodu nadużyć twórców i dostawców oprogramowania, a także dlatego, że tu (branża IT) prawo nie zabrania pełnienia przez jeden podmiot roli projektanta i wykonawcy.

Z danych Panorama Consulting wynika, że zaledwie 12% przedsiębiorstw nie wprowadza żadnych modyfikacji systemu ERP jednak 70% firm wprowadza modyfikacje w aplikacji sięgające 25% (źr. 2017-ERP-Report):

Na budowie

Autor pewnego bloga prawnego poruszył ciekawy problem, który występuje także w projektach IT. Tu niezbyt często (a szkoda) ale występuje prawie zawsze w moich projektach, bo ja akurat realizuje projekty, w których jestem zewnętrznym projektantem. Inwestorzy to moi klienci, developer realizuje mój projekt.

Warto tu zwrócić uwagę na to, że projekty programistyczne są w prawie (prawo autorskie i ochrona know-how) pełną analogią projektów budowlanych, i przepisy te stosuje się odpowiednio. Więcej napisałem o tym w artykule o ochronie know-how.

Problem, o którym pisze autor jest zarządzanie zmianą (w IT mówimy o kastomizacji systemów np. ERP):

Wybudowanie obiektu to złożony i długotrwały proces. Od projektu do obiektu upływa dużo czasu, a inwestor często zmienia zdanie co do ostatecznego kształtu powstającego budynku. Czy inwestor może żądać wprowadzenia wszelkich zmian, wedle własnego uznania? Czy może zlecić dokonanie zmian innemu projektantowi? Czy twórca może się zmianom sprzeciwić? Jak wygląda ta sprawa na gruncie prawa autorskiego? Wcześniej pisałem o zmianach na etapie projektowania, dziś o zmianach na etapie budowania.

Projekt z dziedziny inżynierii oprogramowania, prowadzony zgodnie z najlepszymi praktykami, ma etap analizy problemu, projektowania architektury rozwiązania oraz tworzenia (dostarczenia i dostosowania) samego rozwiązania, które realizuje wybrany wykonawca. Tu także ma miejsce nadzór autora projektu nad jego realizacją (wytwarzaniem, dostosowaniem aplikacji).

To czego faktycznie inwestor może się obawiać, a z czego niestety nagminnie korzystają twórcy oprogramowania, to nadużywanie pozycji monopolu autorskiego:

[…] Warto zasygnalizować jeszcze jeden aspekt związany ze źródłem potencjalnego konfliktu między projektantem, a inwestorem. Mianowicie zdarzają się w praktyce sytuacje, gdy architekci uzależniają wprowadzenie zmiany do projektu zgodnie z zamysłem inwestora od ustanowienia dodatkowego wynagrodzenia. W takim przypadku, projektant powołuje się na swoje autorskie prawa osobiste, które zakazują osobą trzecim zmieniać jego utwór, chcąc uzyskać dodatkową korzyść majątkową. Inwestor w takich sytuacjach często byłby zupełnie pozbawiony ochrony. W literaturze pojawiły się sugestie, mimo licznych wątpliwości, żeby w takich przypadkach powoływać się na art. 5 kc, zarzucając projektantom nadużycie swoich praw. (Źródło: Prawa autorskie w ARCHITEKTURZE – Potencjalny konflikt inwestora z projektantem na tle prawa autorskiego – część 2 | IPblog – o prawie własności intelektualnej i nowych technologii)

Oprogramowanie

W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię praw autorskich do kodu jaki tworzy a jego klient żadnych mimo, że jest inwestorem! Poniżej przykład zapisu w umowie, którą niedawno audytowałem:

Wykonawca nie przenosi na Zamawiającego jakichkolwiek autorskich praw majątkowych do Oprogramowania (co dotyczy także wszystkich adaptacji, modyfikacji i kopii Oprogramowania oraz jego Dokumentacji).

Ten zapis oznacza, że dostawca oprogramowania, np. opracował (udokumentował) jakiś mechanizm działania swojego klienta (na podstawie wywiadów z nim) i zaimplementował go w wytwarzanym (rozwijanym, kastomizowanym) oprogramowaniu, jednak staje się także posiadaczem praw autorskich osobistych i majątkowych do tak opracowanej logiki biznesowej, którą potem sprzedaje (a konkretnie tylko licencjonuje) swojemu sponsorowi (i innym swoim klientom, nie raz także konkurentom sponsora). Ta logika bardzo często stanowi know-how sponsora projektu!

Zapis w innej audytowanej umowie dotyczący prac kastomizacyjnych w systemie ERP, dokonywanych przez firmę wdrażająca a nie przez producenta producenta:

W przypadku wykonania modyfikacji i dostosowania oprogramowania do potrzeb Zamawiającego, Wykonawca z dniem zapłaty wynagrodzenia za Usługi dodatkowe obejmujące ww. modyfikacje, udziela Zamawiającemu licencji na korzystanie z tych modyfikacji przez Zamawiającego, na warunkach na jakich udzielono uprzednio licencji na korzystanie z Oprogramowania. Wynagrodzenie za wykonanie przedmiotowych modyfikacji wskazanych powyżej wydzielonych części oprogramowania, obejmuje wynagrodzenie z tytułu udzielenia licencji.

To już jest kuriozum, znane z anegdot w rodzaju: “konsultant, by odpowiedzieć na pytanie Która jest teraz godzina, prosi Klienta o jego zegarek, odpowiada na pytanie, a zabrany Klientowi zegarek wypożycza mu za sowitym wynagrodzeniem”.

Ta wadliwa sytuacja, jaką tu opisałem, to np. cecha wszystkich projektów agile i tych gdzie programista jest także analitykiem i projektantem (jeżeli taki etap jest w projekcie). W efekcie projektant/wykonawca bardzo często wykorzystuje swoją pozycję podwójnie: nie wprowadza zmian dla siebie niekorzystnych (np. trudna i kosztowna realizacja) i narzuca zmiany poprawiające marże na realizowanym projekcie (upraszczanie), z czego sponsor z reguły nie zdaje sobie sprawy.  Trzecim “narzędziem” budowy marży jest godzenie się na wszelkie propozycje inwestora mając kontrakt T&M, bez ostrzegania go o konsekwencjach wprowadzanych zmian dla całego projektu (a jest nią z reguły dodatkowa pracochłonność).

Bardzo wiele  projektów programistycznych kończy się nie dlatego, że uzyskano oczekiwaną funkcjonalność a dlatego, że wyczerpano budżet lub czas, lub oba te zasoby.

Czy można inaczej? Oczywiście.

źr. Figure 1: Computers, Models, and the Embedding World (Smith 1985)

W umowie należy zaznaczyć, że wszelkie prace programistyczne poprzedzane są udokumentowaną analizą i projektowaniem, i że prawa majątkowe do treści tych dokumentów przechodzą na Zamawiającego. Taka sytuacja nadal jest jednak niezdrowa, bo nadal wykonawca łączy rolę projektanta i developera (czego np. prawo budowlane zabrania z uwagi na powstałą tak uprzywilejowaną pozycję developera).

Ideałem, który można łatwo osiągnąć, jest całkowite oddzielenie analizy i projektowania od realizacji (dla projektów IT zaleca to UZP w dokumencie z 2009 roku). W razie braku takich kompetencji po stronie Zamawiającego, wystarczy zatrudnić projektanta. Po prawej stronie powyżej, ilustracja z 1985 roku: MODEL to owa precyzyjna dokumentacja (to znaczy musi być precyzyjna, by można ją było uznać za projekt – utwór – chroniony prawem).

Model oprogramowania (źr. Large Scale Software Architecture, A practical Guide Using UML)

Co ciekawe, można to zrobić w dowolnej chwili nawet po podpisaniu niekorzystnej umowy (zawierającej zapisy jak te omówione powyżej). W takiej sytuacji, wykonawca, realizując projekt, otrzymuje od Zamawiającego, nie ustne czy nawet pisemne, ogólne idee swoich potrzeb, a dokumenty zawierające dokładne opracowanie projektu implementacji (logika biznesowa i architektura), którą Wykonawca ma zgodnie z umową zrealizować. Warunkiem powodzenia jest to, by autorskie prawa majątkowe do tych dokumentów były przy Zamawiającym (projektant powinien przekazać prawa majątkowe do projektu w pisemnie zawartej umowie). W takiej sytuacji Wykonawca wykonuje prawa zależne do utworu i mimo, że jest autorem implementacji, nie ma żadnych praw do dysponowania nią.

Autor cytowanego artykułu powołuje się pod jego koniec na ważny, i często zapominany paragraf Kodeksu Cywilnego:

Art. 5. Nie można czynić ze swego prawa użytku, który by był sprzeczny ze społeczno-gospodarczym przeznaczeniem tego prawa lub z zasadami współżycia społecznego. Takie działanie lub zaniechanie uprawnionego nie jest uważane za wykonywanie prawa i nie korzysta z ochrony.  (KC)

I tym akcentem, zakończę ten krótki wpis 🙂  i polecam też lekturę całego cytowanego artykułu.

Ty razem pewna ciekawostka, pokazująca jak ważne są ścisłe dziedzinowe, logiczne analizy pojęciowe oraz jak ważne jest by normy (reguły biznesowe) budować w sposób zgodny z regułami logiki i w oparciu o poprawnie zdefiniowane pojęcia. Tą ciekawostką jest niedawne orzeczenie Trybunału Konstytucyjnego:

W wyroku z 13 grudnia Trybunał Konstytucyjny orzekł, że art. 1a ust. 1 pkt 2 ustawy z 12 stycznia 1991 r. o podatkach i opłatach lokalnych w zakresie, w jakim umożliwia uznanie za budowlę obiektu budowlanego, który spełnia kryteria bycia budynkiem, przewidziane w art. 1a ust. 1 pkt 1 powołanej ustawy, jest niezgodny z zasadą szczególnej określoności regulacji daninowych, wywodzoną z art. 84 w związku z art. 217, w związku z art. 64 ust. 3 Konstytucji Rzeczypospolitej Polskiej.¹

Zamieszanie było spowodowane pojęciami użytymi w Ustawach. Najpierw przytaczam sporne pojęcia w brzmieniu z ustaw:

Art. art. 1a wspomnianej  ustawy brzmi²:

Art. 1a. 1. Użyte w ustawie określenia oznaczają:
1) budynek ? obiekt budowlany w rozumieniu przepisów prawa budowlanego, który jest trwale związany z gruntem, wydzielony z przestrzeni za pomocą przegród budowlanych oraz posiada fundamenty i dach;

2) budowla ? obiekt budowlany w rozumieniu przepisów prawa budowlanego niebędący budynkiem lub obiektem małej architektury, a także urządzenie budowlane w rozumieniu przepisów prawa budowlanego związane z obiektem budowlanym, które zapewnia możliwość użytkowania obiektu zgodnie z jego przeznaczeniem;

Prawo budowlane:

Art. 3. Ilekroć w ustawie jest mowa o:
1) obiekcie budowlanym ? należy przez to rozumieć budynek, budowlę bądź obiekt małej architektury, wraz z instalacjami zapewniającymi możliwość użytkowania obiektu zgodnie z jego przeznaczeniem, wzniesiony z użyciem wyrobów budowlanych;
2) budynku ? należy przez to rozumieć taki obiekt budowlany, który jest trwale związany z gruntem, wydzielony z przestrzeni za pomocą przegród budowlanych oraz posiada fundamenty i dach;
2a) budynku mieszkalnym jednorodzinnym ? należy przez to rozumieć budynek wolno stojący albo budynek w zabudowie bliźniaczej, szeregowej lub grupowej, służący zaspokajaniu potrzeb mieszkaniowych, stanowiący konstrukcyjnie samodzielną całość, w którym dopuszcza się wydzielenie nie więcej niż dwóch lokali mieszkalnych albo jednego lokalu mieszkalnego i lokalu użytkowego o powierzchni całkowitej nieprzekraczającej 30% powierzchni całkowitej budynku;
3) budowli ? należy przez to rozumieć każdy obiekt budowlany niebędący budynkiem lub obiektem małej architektury, jak: obiekty liniowe, lotniska, mosty, wiadukty, estakady, tunele, przepusty, sieci techniczne, wolno stojące maszty antenowe, wolno stojące trwale związane z gruntem tablice reklamowe i urządzenia reklamowe, budowle ziemne, obronne (fortyfikacje), ochronne, hydrotechniczne, zbiorniki, wolno stojące instalacje przemysłowe lub urządzenia techniczne, oczyszczalnie ścieków, składowiska odpadów, stacje uzdatniania wody, konstrukcje oporowe, nadziemne i podziemne przejścia dla pieszych, sieci uzbrojenia terenu, budowle sportowe, cmentarze, pomniki, a także części budowlane urządzeń technicznych (kotłów, pieców przemysłowych, elektrowni jądrowych i innych urządzeń) oraz fundamenty pod maszyny i urządzenia, jako odrębne pod względem technicznym części przedmiotów składających się na całość użytkową;
3a) obiekcie liniowym ? należy przez to rozumieć obiekt budowlany, którego charakterystycznym parametrem jest długość, w szczególności droga wraz ze zjazdami, linia kolejowa, wodociąg, kanał, gazociąg, ciepłociąg, rurociąg, linia i trakcja elektroenergetyczna, linia kablowa nadziemna i, umieszczona bezpośrednio w ziemi, podziemna, wał przeciwpowodziowy oraz kanalizacja kablowa, przy czym kable w niej zainstalowane nie stanowią obiektu budowlanego lub jego części ani urządzenia budowlanego;
4) obiekcie małej architektury ? należy przez to rozumieć niewielkie obiekty, a w szczególności:
a) kultu religijnego, jak: kapliczki, krzyże przydrożne, figury,
b) posągi, wodotryski i inne obiekty architektury ogrodowej,
c) użytkowe służące rekreacji codziennej i utrzymaniu porządku, jak: piaskownice, huśtawki, drabinki, śmietniki;
5) tymczasowym obiekcie budowlanym ? należy przez to rozumieć obiekt budowlany przeznaczony do czasowego użytkowania w okresie krótszym od jego trwałości technicznej, przewidziany do przeniesienia w inne miejsce lub rozbiórki, a także obiekt budowlany niepołączony trwale z gruntem, jak: strzelnice, kioski uliczne, pawilony sprzedaży ulicznej i wystawowe, przekrycia namiotowe i powłoki pneumatyczne, urządzenia rozrywkowe, barakowozy, obiekty kontenerowe;³

Po tej lekturze zapoznajmy się z opisem orzeczenia:

Trybunał Konstytucyjny stwierdził, że za akceptacją kwestionowanego zapatrywania miały przemawiać dwa niezbyt klarowne argumenty ? językowy i celowościowy. Ich krytyczna analiza doprowadziła do wniosku, iż są one nieuzasadnione. Argument językowy opierał się na przyjęciu, że skoro ustawodawca nie zastrzegł w definicji pojęcia budynku warunku, iż nie może on być budowlą, czyniąc jedynie zastrzeżenie w definicji pojęcia budowli, iż nie może być ona budynkiem, to nie jest wykluczone, by pewne budynki uznać za budowle, z czym ostatecznie nie sposób się zgodzić ze względu na twierdzenia samej logiki ? relacja wykluczania się zbiorów jest bowiem symetryczna. Argument celowościowy, powiązany wprost z argumentem językowym, opierał się z kolei na konstatacji, że skoro niektóre budynki można uznać za budowle, to dokonując takiej rekwalifikacji należy odwołać się do ? nieprzewidzianej przez ustawodawcę ? przesłanki funkcji danego obiektu, biorąc pod uwagę, przykładowo, jego przeznaczenie, wyposażenie oraz sposób i możliwość wykorzystania. Uwzględnienie tej przesłanki prowadziłoby jednak do rozszerzającej wykładni definicji budowli, powodując zarazem zwężającą wykładnię definicji budynku. W konsekwencji, taki zabieg stanowiłby nieakceptowalną na gruncie polskiej kultury prawnej ingerencję w treść definicji legalnej, a co więcej skutkowałby funkcjonalną reinterpretacją regulacji podatkowej na niekorzyść podatnika. ⁴

Po powyższym wywodzie “słownym” (patrz wytłuszczenia) popatrzmy na poniższy diagram.

Jest to model pojęciowy zbudowany na gruncie semiotyki (trójkąt semiotyczny), stosowanej w systemowej metodzie budowania reguł biznesowych, w której pojęcia (terminy) stosowane do budowy norm (reguł), muszą mieść ścisłe definicje. Definicje pojęć muszą spełniać logiczne zasady, w szczególności regułę wyłączonego środka (brzmiącą “jeżeli coś jest czymś to nie jest niczym innym”). Poniżej taksonomia pojęcia obiekt budowlany zbudowana na bazie treści przytaczanych ustaw ustawy:

Pojęcie obiekt budowlany ma dwa typy kategorii: (1) wg. trwałości: tymczasowy i trwały obiekt budowlany, (2) wg. rodzaju: budynek, budowla, obiekt małej architektury. Z zasady logiki tworzenia przestrzeni pojęciowych wywodzimy, że każdy obiekt budowlany można zakwalifikować wyłącznie do jednej z kategorii w ramach typu. Innymi jeżeli coś jest budynkiem, to nie jest niczym innym, jeżeli coś jest budowlą, to nie jest niczym innym, więc budynkiem też nie jest.

Powyższy model treści ustawy (w obszarze definicji pojęć) wskazuj na pewną w niej wadę: otóż co do zasady jeżeli pojęcie ma typy to muszą musi być co najmniej dwa. Jeżeli pojęcie ma jeden dodatkowy typ, z zasady oba są synonimami. Zakładam (muszę tak założyć, jeżeli wierzę w poprawność tych definicji, a chce wierzyć), że intencją prawodawcy jest właśnie wskazanie kategorii. Tak więc należy wywieść, że budynki dzielimy na budynki mieszkalne jednorodzinne oraz budynki mieszkalne nie będące budynkami jednorodzinnymi (co można spotkać w postaci pojęcia budownictwa wielorodzinnego). Analogicznie budowle mogą być obiektami liniowymi oraz innymi obiektami. Jeżeli ustawodawca definiuje tymczasowy obiekt budowlany, oznacza to że istnieją “nietymczasowe” czyli trwałe obiekty budowlane. To jednak materiał na inny spór…

Dziwi mnie, że trzeba było aż TK by to rozstrzygnąć, jednak z drugiej strony niestety spotykam nie raz u prawników, zarówno reprezentujących urzędy, jaki i reprezentujących podatników i przedsiębiorców, owe “celowościowe” (niestety pozbawione logiki) wywody, które w moich oczach, można zaliczyć do erystycznych zabiegów prawników obu stron tego typu sporów.

Jako uzupełnienie przytoczę fragment swojego tekstu  sprzed dwóch lat:

To dlatego reguły biznesowe są ?regułami postępowania? a nie ?regułami podejmowania decyzji?. Decyzja to konkretne postanowienie, zachowanie się w konkretnej sytuacji i konkretnych warunkach. Podejmowanie decyzji może być opisane procedurą, sekwencją kroków, można je zapisać w postaci tablicy decyzyjnej.Bardzo ważne jest pojęcie ?termin?, jest to definicja pozwalająca na zaklasyfikowanie czegoś jako tego co określono nazwą ?termin? (termin czyli pojęcie w słowniku terminów, pojęć). Słownik pojęć to lista terminów będących klasyfikatorami. Np. termin pismo musi mieć definicję pozwalająca odróżniać pisma od ?niepism? a spam od ?niespamu?. ⁵

Tak więc ustawodawca, używają pojęć zdefiniowanych, tworzy normy postępowania, nie ma tu miejsca na podejmowanie decyzji (np. o kwalifikacji budowli), takie decyzje zapadają w momencie tworzenia definicji pojęć użytych w normie (tworzenia samej normy). Tak zwane “celowościowe interpretacje” to  próby ingerowania w decyzje prawodawcy, który – umieszczając w normie definicje użytych w niej pojęć – podjął już  wymagane decyzje.

Dla porządku przywoływane wyżej zapisy Konstytucji:

Art. 64. 1. Każdy ma prawo do własności, innych praw majątkowych oraz prawo dziedziczenia.
2. Własność, inne prawa majątkowe oraz prawo dziedziczenia podlegają równej dla wszystkich ochronie prawnej.
3. Własność może być ograniczona tylko w drodze ustawy i tylko w zakresie, w jakim nie narusza ona istoty prawa własności.
Art. 84. Każdy jest obowiązany do ponoszenia ciężarów i świadczeń publicznych, w tym podatków, określonych w ustawie.
Art. 217. Nakładanie podatków, innych danin publicznych, określanie podmiotów, przedmiotów opodatkowania i stawek podatkowych, a także zasad przyznawania ulg i umorzeń oraz kategorii podmiotów zwolnionych od podatków następuje w drodze ustawy.