Wraz z rozwojem automatyzacji w szeroko pojętej gospodarce, coraz większego ekonomicznego znaczenia nabiera kwestia oprogramowania komputerowego. Znaleźć je można obecnie wszędzie, rozpoczynając od domofonu i pralki, a kończąc na zaawansowanych aplikacjach analitycznych. Nikogo nie zaskoczy zatem fakt, że z punktu widzenia prawa, które stara się nadążać za gospodarką, znaczenia nabrały także umowy umożliwiające obrót owym oprogramowaniem.
Do grona najbardziej popularnych kontraktów IT należą tzw. umowy wdrożeniowe, w których wykonawca zobowiązuje się, jak sama nazwa wskazuje, do wdrożenia konkretnego oprogramowania. W zależności od potrzeb zamawiającego, jest to zestaw czynności mających doprowadzić do implementacji stworzonego kodu w infrastrukturze klienta, tak aby ten bez przeszkód mógł wykorzystywać zamówioną aplikację.
Wśród umów uregulowanych w kodeksie cywilnym (tzw. umów nazwanych) próżno szukać wyżej wspomnianych umów wdrożeniowych. Sytuacja ta nie powinna budzić zdziwienia, gdyż obowiązująca obecnie ustawa uchwalona została w latach 60. ubiegłego wieku. Również w dzisiejszych czasach ustawodawca nie widzi potrzeby uregulowania umowy wdrożeniowej w jakiejkolwiek ustawie. Czy oznacza to, że umowy takie nie istnieją w świetle prawa?
Oczywiście należy udzielić odpowiedzi przeczącej. Naczelną zasadą polskiego prawa jest swoboda umów, która umożliwia kształtowanie treści stosunku prawnego przez strony kontraktu. W tym świetle ważne jest każde zobowiązanie, które można wykonać zgodnie z prawem i zasadami współżycia społecznego. Powyższe pozwala na zawieranie umów, które doktryna prawa i praktyka obrotu nazywają umowami wdrożeniowymi.
Określenie to obejmuje bardzo szeroki wachlarz umów, które przypominać mogą niektóre z istniejących umów nazwanych. Ich rodzaj, a co za tym idzie kwalifikacja, zależeć będą w dużym stopniu od metodyki pracy przyjętej przez zespół deweloperów.
Tradycyjnym sposobem organizacji pracy nad stworzeniem nowego oprogramowania była tzw. metoda kaskadowa (waterfall). Charakteryzowała się ona dokładnym określeniem kształtu zamawianej aplikacji już na początkowym etapie prac. Szczegółowe opisanie przedmiotu zamówienia w umowie chroniło zamawiającego, lecz skutkowało również brakiem możliwości dokonania zmian w rozwijanym projekcie. Ponadto oprogramowanie poddawane było testom i weryfikacji przez klienta dopiero po zakończeniu prac, co tym bardziej utrudniało dokonanie zmian. Umowy takie co do zasady (choć orzecznictwo sądowe jest w tym zakresie zróżnicowane) kwalifikowane były przez sądy jako umowy o dzieło. Strony wskazywały bowiem konkretny i określony przedmiot zamówienia (dzieło), a także wynagrodzenie za jego stworzenie, co w istocie stanowi esencję wskazanej umowy.
Wraz z rozwojem technologii okazało się jednak, iż wykorzystywana metodyka waterfall jest nieskuteczna i nazbyt ograniczająca strony. Bardzo duży odsetek projektów informatycznych kończył się niepowodzeniem, czy to poprzez niespełnienie oczekiwań zamawiającego, czy też przekroczenie czasu realizacji zamówienia. Sytuacja ta wynikała z faktu, iż podmioty zamawiające oprogramowanie często nie zdają sobie sprawy z możliwości technologicznych, nie są zatem w stanie wybrać właściwych dla siebie rozwiązań w początkowej fazie prac.
Naturalnym następstwem takiego stanu rzeczy było opracowanie metody charakteryzującej się dużo większą elastycznością. Ogłoszono manifest agile, a zwinny sposób tworzenia oprogramowania przyjął się również w Polsce. Charakteryzuje się on brakiem zdefiniowania produktu końcowego w początkowych etapach pracy. Oprogramowanie tworzy się kawałek po kawałku, przedstawiając każdy element do weryfikacji klientowi lub wyznaczonemu project ownerowi, który ma możliwość wprowadzenia zmian na wszystkich etapach projektu.
Umowy tworzone na potrzeby takich zamówień charakteryzują się z pewnością dużo większym stopniem ogólności zawartych w nich klauzul. Ponadto z uwagi na brak dostatecznie sprecyzowanego efektu końcowego, umowy te nie mogą zostać zakwalifikowane jako umowy o dzieło. Uznaje się zatem, że są to umowy o świadczenie usług, a zatem typ umowy nazwanej i jako taki, większe przywileje przyznaje wykonawcy zamówienia.
Jak zatem widać, w praktyce występuje rozróżnienie na dwa podstawowe typy umów wdrożeniowych. Jedne stosowane w tradycyjnych projektach, prowadzonych w metodyce kaskadowej, w uproszczeniu kwalifikowane jako umowa o dzieło, a drugie – umowy o świadczenie usług, gdy wykorzystuje się agile.
Powyższe wyodrębnienie nie stanowi jedynie teoretycznego zagadnienia. Z uwagi na fakt, iż obie ww. umowy uregulowane są w kodeksie cywilnym z przepisów prawa wynikają inne, charakterystyczne dla nich, uprawnienia i obowiązki. Niezwykle istotne z punktu widzenia wykonania umowy. Pomimo tego, nie ma możliwości kategorycznego zakwalifikowania umowy wdrożeniowej, jako konkretnego typu umowy nazwanej. Nie pomaga tutaj także fakt, iż często kontrakty te zawierają również zobowiązania inne niż wdrożenie aplikacji, np. przeszkolenie pracowników, czy utrzymanie kodu.
Polskie sądy, borykając się z problemem odpowiedniego zakwalifikowania umów wdrożeniowych, najczęściej uznają je jako typ mieszany, dostrzegając zarówno elementy umowy o dzieło, jak i umowy o świadczenie usług. Niekiedy w umowach wdrożeniowych odnajduje się także elementy umowy dostawy. Taka rozbieżność orzecznicza prowadzi do konkluzji, iż każdy kontrakt analizować należy z punktu widzenia konkretnych postanowień umownych i nie jest możliwe aprioryczne przyporządkowanie umowy wdrożeniowej.
Oczywiście przedstawione pokrótce umowy wdrożeniowe nie stanowią jedynych możliwości wprowadzania oprogramowania do obrotu. W przypadku, gdy nie dochodzi do sprzedaży własności stworzonego kodu, a jedynie sprzedaje się możliwość korzystania z niego, wówczas można również oprzeć się na umowie licencyjnej. W takim przypadku zakupione oprogramowanie również podlega wdrożeniu, jednakże kupujący uzyskuje zazwyczaj jedynie prawo do korzystania z produktu bez możliwości rozporządzania nim dalej, tj. na rzecz innych podmiotów.
Możliwa jest również sprzedaż uprawnień do korzystania z aplikacji utrzymywanej w infrastrukturze sprzedającego. Nie dochodzi wówczas do klasycznego wdrożenia. Dotyczy to oprogramowania sprzedawanego w modelu Software as a Service, a kontrakty takie przyjmują nazwę “umów SaaS’owych”.
W ostatnim czasie pojawiają się także umowy dostosowane do produktów informatycznych sprzedawanych w formule biznesowej PaaS (Platform as a Service) oraz IaaS (Infrstructure as a Service), które również charakteryzują się swoją specyfiką i zostaną omówione w kolejnych tekstach na naszym blogu.
Powyższe wyszczególnienie stanowi jedynie wstęp do cyklu artykułów na temat kontraktów IT, które pojawiać będą się na naszej stronie internetowej. W przypadku pytań zachęcamy również do kontaktu.
