Wstęp

Na pewnym blogu, jego autor opisuje swoje uwagi do umowy, jaką zawarło Ministerstwo Cyfryzacji, na wykonanie aplikacji nadzorującej kwarantanny:

Dostałem z Ministerstwa Cyfryzacji kopię umowy na wykonanie aplikacji Kwarantanna Domowa ? części mobilnej, przeglądarkowej i serwerowej, wraz z informacją o zakresie i długości trwania wsparcia serwisowego. (źr.: Informatyk Zakładowy -)

Temat pandemii nośny więc i emocje wokół tej aplikacji nie małe. Autor bloga skupił się na wycenie. Nie raz pisałem a aspektach prawnych i projektowych umów na dostarczenie oprogramowania.

Popatrzmy na treść tej umowy

Nie będzie to dogłębna analiza a raczej wskazanie kluczowych moim zdaniem wad i ryzyk. Tę umowę spokojnie można uznać za antywzorzec umów tego typu.

Par. 2. Umowa przewiduje dwa etapy prac: oddanie aplikacji do testów oraz oddanie aplikacji w wersji produkcyjnej. Zakres nie zawiera więc etapu analizy i projektowania, innymi słowy, Zamawiający nie dostanie Projektu Technicznego Oprogramowania.

Par.3.

pkt. 8. Zawiera zapis o powstaniu dokumentacji technicznej, jednak nic o niej nie nie wiadomo, bo nie jest ona, jej powstanie, rozliczanym etapem prac (patrz wyżej).

Par. 6.

pkt. 1. Wykonawca ma prawa majątkowe do aplikacji. Wygląda na to, że ta aplikacja już istnieje. Jednak pkt. 2 jasno wskazuje, że przedmiot zamówienia powstanie “na bazie” tego co istnieje (co to znaczy?).

Pkt. 3. to dla mnie kuriozum: Wykonawca przeniesie na zamawiającego prawa majątkowe lub udzieli licencji. Czyli, że co? Pomyśli później i się zdecyduje? Po drugie skoro coś powstaje na bazie czegoś, to gdzie jest granica pomiędzy tym co było i tym co powstało? Jeżeli Wykonawca przeniesie prawa majątkowe to do czego? Do tego co już było czy tylko do tego co powstanie za owe 2 miliony?

Pkt. 5. zawiera sformułowanie “przekazane mu w ramach Umowy dobra własności intelektualne”… Co to za cudo te dobra? Prawo jasno określa, że mamy autorskie prawa osobiste i majątkowe, dotyczą całości utworu lub jego określonej części. O jakie dobra tu chodzi?

Pkt. 6. Umowa mówi o oprogramowaniu standardowym ale nie definiuje tego pojęcia. Cóż to jest?

Pkt. 7. Wykonawca może wykorzystać oprogramowanie open source, w jaki sposób? Jako komponent czy jako narzędzie?

Pkt. 11. Wykonawca zobowiązuje się i gwarantuje, że osoby uprawnione nie będą wykonywały autorskich praw osobistych. O ile wiem jest to zakazana klauzula, po drugie wykonawca tą metoda zrzeka sie całkowicie odpowiedzialności za swój produkt, a my nigdy nie dowiemy się kto stworzył ewentualnego bubla.

Pkt. 12. Tego nie rozumiem: “Jeżeli Zamawiający nie będzie mógł korzystać z Aplikacji, Wykonawca, na swój koszt, uzyska niezwłocznie dla Zamawiającego prawa do kontynuowania korzystania z niej”.

Par. 7.

Wykonawca przeniesie na Zamawiającego prawa Majątkowe do kodu źródłowego, czy projekt (nie tylko architektury) nie powstanie. Pkt. 5. i 7. powtórzone Par.6. Pkt.11.

Par. 8.

Licencja. Skoro Aplikacja powstaje na bazie TakeTask i nie określono granicy pomiędzy tym co było a co powstanie (brak modelu architektury) to co jest licencjonowane a do czego przekazano prawa majątkowe?

Par. 12. Poufność.

Pkt. 1. Znowu mamy zapisy brzmiące “wszelkie” przekazane informacje, mimo, że prawo stanowi, że informacje takie, strona udostępniająca, MUSI stosowanie oznaczyć. Domniemanie poufności czegokolwiek co przekazano jest nieskuteczne.

Pkt. 5. Moje ulubione usuwanie informacji, czyli “co prawda zobaczyłeś ale teraz odzobaczysz”. Prawo jasno mówi, że obowiązek ochrony otrzymanych informacji wygasa wyłącznie w przypadku gdy podmiot udostępniający informacje chronione sam jej upubliczni.

Na zakończenie

Kwestie praw autorskich do oprogramowania i ochrony know-how dość obszernie opisałem w artykule Ochrona praw autorskich i know-how zamawiającego

Nie będę jej komentował ani wyceny autora przywołanego na początku, bo autor użył metody którą krytykowałem tu już nie raz, np. w artykule: Wymiarowanie oprogramowania. Podziwiam każdego, kto potrafi na podstawie takiego jak tu opisu dokonać jakiejkolwiek wyceny (o ile nie narzuci ogromnego zapasu).

Na temat wymagań na oprogramowanie opisanych prozą, napisałem już tyle złych rzeczy, że tu mógłbym sie tylko powtarzać, polecam więc lekturę wpisu Opis przedmiotu zamówienia.

Jarosław Żeliński

Jarosław Żeliński: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: dostęp do treści Bloga jest bezpłatny, jednak wszelka pomoc oraz wyjaśnienia dotyczące treści artykułów autora bloga, udzielane są wyłącznie w ramach płatnych konsultacji.