Podobno każdy lubi zupę pomidorową. Podobno każdy potrafi odróżnić dobrą pomidorówkę od innych zup. Podobno każdy od czasu do czasu ma ochotę na pomidorówkę. Bardzo wiele osób potrafi jakoś tam opisać jaka ta pomidorówka powinna być: lekko kwaskowata i pikantna, konsystencja tłustego rosołu, wyraźny smak pomidorów, podana z ryżem, makaronem lub łazankami, raczej gorąca. I teraz najważniejsze: jakie znaczenie dla samej pomidorówki ma to czy: zamówimy ją w restauracji, zamówimy z dostawą do domu czy sami zrobimy? W kwestii samej pomidorówki nie ma to żadnego znaczenia. Do rozważenia jest tylko to czy potrafimy ją sami ugotować, czy mamy na to czas, czy mamy budżet na gotowca z dostawą do domu czy może mamy czas i budżet na wizytę w dobrej restauracji. Jednak generalnie jest to cały czas ta sama pomidorówka (na razie pomijam pecha ze złym kucharzem ale tu jesteśmy troszkę bezbronni).

Wniosek jest jeden: na samym początku i długo jeszcze, a czasem nigdy, nie ma żadnego znaczenia czy ta pomidorówka będzie robiona dla nas czy nalana z wielkiego gara: opisując ją będzie to zawsze taki sam opis. Po prostu raz jest taniej a raz drożej, raz szybciej a raz trzeba poczekać. Wiemy dlaczego, i nie zależy to od opisu pomidorówki, bo zawsze jej smak jest taki sam.

Umowy

Od lat spotykam się w tej (IT) branży z, czasami bardzo kuriozalnymi, konstrukcjami prawnymi “przedmiotu umowy” w umowach jakie serwują moim klientom dostawcy oprogramowania. Postanowiłem jednak nie komentować tu tych umów, postanowiłem napisać “instrukcję” wraz z uzasadnieniem. Bo okazuje się, że prawie nikt nie ma problemu z pomidorówką ale wielu ma problem z oprogramowaniem, które się w pewnych kwestiach niczym od pomidorówki nie różni.

Na początek jednak schemat blokowy, na którym zobrazujemy nasz przedmiot dywagacji.

Opis diagramu

Aplikacja jest opisana w dokumencie Specyfikacja oprogramowania, jest realizacją tej Specyfikacji. Dokument ten zawiera opis tego, czym jest Aplikacja, czyli to jakie usługi świadczy ona użytkownikom i innym (zewnętrznym) aplikacjom. Każdy byt zewnętrzny w stosunku do Aplikacji jest na tym diagramie aktorem.  Byt korzystający bezpośrednio z usług Aplikacji, jest aktorem TEJ Aplikacji.  GUI oznacza, że Użytkownik to człowiek korzystający z niej za pośrednictwem “interfejsu użytkownika”. API oznacza, że Aplikacja_3 korzysta z usług Aplikacji (jest zintegrowana) za pośrednictwem interfejsu programistycznego.  Aplikacja jest uzależniona od Interesariusza 2, podobnie jak Aplikacja 1. Działanie Aplikacji (oprogramowania) jest uzależnione od dostępu do Aplikacji 1 i Aplikacji 2 (i nie świadczy im żadnych usług ze swojej strony). Interesariusz 2 i Interesariusz 4 są ze sobą związani Umową. Specyfikacja oprogramowania, podobnie jak Kod programu, ma trwały związek z Umową.

Specyfikacja oprogramowania to dokument zawierający jednoznaczny opis zachowania się Aplikacji i mechanizm jej działania. W tym miejscu informacja dla prawników: taki opis jest możliwy do wykonania, podobnie jak możliwy jest do wykonania opis maszyny do szycia czy wagonu kolejowego. Specyfikacja ta – jej treść – nie zależy w jakimkolwiek stopniu od tego, kto jest jej właścicielem i użytkownikiem (od aktorów na tym diagramie), nie zależy także od treści Umowy.

Kod programu to tekst niosący określoną treść, stanowiący wraz z nośnikiem, materialny byt analogicznie jak np. książka czy obraz.

Na diagramie pokazano różne, wyżej opisane, związki (nie nazwane, ich nazwy zależą od konkretnej sytuacji) pomiędzy elementami diagramu. Pomogą nam one w dalszej części.

Prawny status “oprogramowania”

W przestrzeni publicznej toczą się spory co do tego “czym jest oprogramowanie”, jednak moim zdaniem, większość tych sporów ma swoje źródła w niezrozumieniu specyfiki technologii informatycznych i samego prawa, część jest skutkiem celowego lub nie, mataczenia w samych umowach.

Ustawodawca, moim zdaniem bardzo słusznie, zakwalifikował oprogramowanie do utworów literackich, gdyż w swej istocie jest ono zawsze zapisem analogicznym do tekstu. Osobną kwestią jest treść tkwiąca w takim utworze (o czym on jest), co podobnie jak w przypadku literackich tekstów, może mieć ale nie musi, znaczenie. Tekst Kodu programu zinterpretowana przez odpowiednią maszynę, potocznie zwaną komputerem, decyduje o tym “czym dany komputer jest”. Raz jest programatorem pralki a raz edytorem tekstu czy grą interaktywną. Oprogramowanie często cechuje się określonym “mechanizmem działania”.  W literaturze z obszaru technik komputerowych i filozofii, bardzo często można spotkać teorię mówiącą, że “komputer to uniwersalny mechanizm”. Innymi słowy komputer może być “czymkolwiek”, decyduje o tym  “program komputerowy”. Podam przykład.

Zegar to przyrząd wskazujący aktualną godzinę. Chyba każdy czytający ten tekst spotkał się w swoim życiu z wieloma wersjami tego przyrządu. To co obserwujemy na swoich nadgarstkach czy ścianach mieszkań (i dworców kolejowych) to konkretne zegary (mechaniczne, cyfrowe, itp.). Mimo wielu ich odmian i konstrukcji, zawsze służą do tego samego celu: wskazują aktualną godziną  (pomija tu te uszkodzone). Zawsze też mają ten sam mechanizm działania. Poniżej mamy diagram opisujący mechanizm działania zegara. 

Celowo nie opisuję detalicznie tego diagramu, zakładam, że jest “oczywisty” (poza pewnymi detalami użytej notacji). Diagram ten należałoby uzupełnić regułami, np. tą że wskazania minut zerują się zawsze po 59 sekundzie. Zestaw takich reguł, uzupełniony opisem (jest jego elementem) to “mechanizmu działania zegara”.

Jak nietrudno się przekonać, wykonań (implementacji) tego mechanizmu jest na świecie ogrom, część z nich to właśnie komputer i “program realizujący mechanizm zegara”. Wersji takiego programu (tekstu decydującego o tym jak zachowa się komputer)  także może być ogrom. Tak więc program jako treść (utwór literacki) spełnia definicję ustawową utworu. W swej treści może zawierać opis mechanizmu przedstawionego na powyższym diagramie, zakładam, że nikt z czytających nie ma wątpliwości, że konkretna treść programu i konkretny użyty komputer, to inwencja twórcza “autora programu”, nie zmienia to faktu, że programy te będą realizowały mechanizm opisany w powyższej Specyfikacji oprogramowania, Kod programu będzie tu dziełem zależnym (autor Kodu programu nie jest autorem Specyfikacji oprogramowania, opracował swój utwór jako realizację tej specyfikacji). Zarówno Kod programu jak i Specyfikacja są utworami (także w rozumieniu ustawy). Poniżej użyte pojęcia i zależności między nimi:

Z jakimi umowami mamy do czynienia?

Podmioty zobrazowane jako Interesariusz 2 i Interesariusz 4 zawierają Umowę, przedmiotem umowy mogą być usługi, wartości niematerialne i produkty.

Najczęściej spotykaną sytuacją jest tak zwany “zakup oprogramowania”, a konkretnie jest to jego licencjonowanie i jednorazowa opłata z tego tytułu. Interesariusz 4 jest posiadaczem praw majątkowych do Aplikacji. Kupując np. grę komputerową lub program do wystawiania faktur, faktycznie mamy następującą sytuację: podmiot kupujący (Interesariusz 2) zawiera z posiadaczem praw majątkowych (Interesariusz 4) Umowę licencyjną pozwalającą mu na korzystanie z Aplikacji. Użytkownik korzysta z Aplikacji (jest np. pracownikiem Interesariusza 2, lub Interesariusz 2 i Użytkownik to ta sama osoba fizyczna).

Umowa może zawierać zapisy o przeniesieniu praw majątkowych z Interesariusza 4 na Interesarusza 2. Integralną częścią takiej Umowy, załącznikiem do niej, jest Kod programu (jego egzemplarz na nośniku).  Aplikacja może posiadać swoją Specyfikację. Przeniesienie praw majątkowych do Kodu programu może (nie musi) wiązać się z przeniesieniem praw majątkowych do jego Specyfikacji. Jej treść także może być przedmiotem odrębnej umowy. Decyduje o tym fakt, że Kod programu jest dziełem zależnym w stosunku do jego Specyfikacji.

Specyfikacja oprogramowania może zawierać w swej treści opis określonego mechanizmu, np. ustalanie scoringu kredytobiorcy albo przyznawanie określonych upustów określonym grupom klientów. Treść ta może więc stanowić know-how, które może być chronione np. jako tajemnica firmy.

Teraz nieco trudniej. Na rynku spotykamy pojęcia “oprogramowanie w chmurze”, SaaS (Software as a Service), outsourcing.  Pojęcia te, w swych nazwach, nie mają żadnego umocowania w prawie. Czym więc są? Osobiście jestem zwolennikiem nieużywania ich inaczej niż jako komentarza. Innymi słowy Umowa powinna być skonstruowana z terminów prawnych (użytych i zdefiniowanych w Ustawach), terminy stworzone na użytek komunikacji rynkowej (np. “cloud computing”) powinny być w tych umowach każdorazowo definiowane z użyciem terminów prawnych.

Jeżeli więc ktoś korzysta “w chmurze” z oprogramowania pozwalającego np. zarządzać kontaktami z klientami, to znaczy, że za pośrednictwem sieci Internet Użytkownik ma dostęp do Aplikacji, korzysta z Usług aplikacji. Robi to na podstawie Umowy jaką zawarł Interesariusz 2 z Interesariuszem 4 (tu także Interesariusz 2 i Użytkowmik mogą być tą samą osobą fizyczną). Umowa określa tu np. ilu Użytkowników może korzystać z Usług aplikacji oraz to, czy użytkownikiem może być ktokolwiek czy konkretne osoby z imienia i nazwiska.

Hosting. Jest to usługa zaliczana do outsourcingu. W tym przypadku mamy sytuację taką:

1. Prawa do Aplikacji ma Interesariusz 2.
2. Aplikacja zainstalowana jest na Komputerze będącego własnością Interesariusza 4.
3. Użytkownicy, np. pracownicy Interesariusza 2, zdalnie za pośrednictwem sieci Internet, korzystają z Usług aplikacji.
4. Umowa precyzuje szczegółowo opłaty i odpowiedzialność obu interesariuszy.

Takich “kombinacji” może być wiele, jednak na koniec opiszę to co nazywamy przetargami. Pojawia się w nich pojęcie Opis Przedmiotu Zamówienia, które moim zdaniem sprawa w tej branży, sporo kłopotu także prawnikom.

Typowym celem ogłaszającego przetarg (każdego “kupującego” oprogramowanie) jest możliwość korzystania z Usług aplikacji. W tym celu zawrze umowę (outsourcingową, licencyjną, itp.), która mu na to pozwoli. I tu wracamy do naszej pomidorówki. Kluczem jest Specyfikacja, która zawiera opis tego jakie to usługi i jaki jest mechanizm ich realizacji. Dla kupującego nie ma tu (na tym etapie) absolutnie żadnego znaczenia, czy ta aplikacja będzie specjalnie dla niego tworzona czy nie. Specyfikacja MUSI powstać, bez czego nie da się stwierdzić, czy dana Aplikacja jest tą, którą zamawiamy i której potrzebujemy. Do tego korzystanie z zakupionej Aplikacji może wymagać pewnych prac, takich jak jej zainstalowanie, skonfigurowanie, przeszkolenie Użytkowników, umieszczenie w niej pewnych danych (np. migracja danych z poprzednio używanej aplikacji), czasami zintegrowanie z innymi, już wykorzystywanymi, aplikacjami. Ogłaszający taki przetarg zapłaci za:

1. prawo korzystania z Aplikacji (w ustalonej firmie np. licencji),
2. wszelkie konieczne usługi poprzedzające normalne użytkowanie Aplikacji,
3. jeżeli na rynku nie jest oferowane wymagane oprogramowanie, zostanie ono “napisane” na podstawie Specyfikacji specjalnie dla Zamawiającego.

Jak widać, Specyfikacja jest tu bardzo istotnym elementem, wręcz niezbędnym. To co nazywamy Opisem Przedmiotu Zamówienia jest czymś więcej niż tylko Specyfikacja oprogramowania. Dobrą praktyką jest rozdzielanie tych trzech powyższych elementów, ogromną wygodą jest jeżeli są to odrębne umowy lub odrębne załączniki Umowy głównej. Splatanie razem tych aspektów najczęściej prowadzi do nieporozumień, problemów z interpretacją umowy w czasie sporów. W skądinąd ciekawym artykule pewna kancelaria wskazuje przyczyny, a jako rozwiązanie problemu wskazuje jedynie prawo do wycofania sie z umowy:

Nie ma recepty na poprawne opisanie przedmiotu świadczenia. Jeśli mamy rozbudowane, precyzyjne specyfikacje, to i tak musimy w umowie opisać zarządzanie zmianą, ze szczególnym uwzględnieniem roli analizy. W większości wypadków specyfikacje są na tyle ogólne, że dopiero analiza (projekt funkcjonalny, koncepcja itp.) opisuje prawdziwe ?co”. Już na początku kontrakt musi zadbać o interesy stron (zwłaszcza zamawiającego), jeżeli okaże się, że analiza ? choć przeprowadzona poprawnie ? prowadzi do wniosków nieakceptowalnych (koszty, zakres zmian, terminy). Jednym ze sposobów jest wprowadzenie umownego prawa odstąpienia od umowy. To minimum prawniczej przyzwoitości, pozwalające małym kosztem wycofać się z umowy. (Źródło: Pięć typowych błędów w umowach wdrożeniowych) 

Recepty na opisanie opisanie nie ma (a na co jest?), ale są zasady, o których tu piszę. Kilka uwag do powyższego. Rozbudowana specyfikacja to gwarantowane problemy związane z zarządzaniem zmianą i tu należy sie zgodzić zaś zbyt ogólny opis jest jeszcze gorszy, bo po prostu nie wiadomo co jest przedmiotem zawieranej umowy. Kluczem jest to: “W większości wypadków specyfikacje są na tyle ogólne, że dopiero analiza (projekt funkcjonalny, koncepcja itp.) opisuje prawdziwe ?co””. W takim przypadku niestety dostawca po prostu dostarczy to co chce, bo skoro jest wykonawcą i autorem analizy wymagań to znaczy jest że jest autorem opisu przedmiotu umowy. Biorąc pod uwagę fakt, że w takich sytuacjach z zasady dostawca technologii ma przewagę merytoryczną nad swoim klientem (bo ten z jakiegoś powodu nie zrobił opisu sam),  zamawiający w zasadzie nie panuje na tym co dostanie. Słowo “analiza” nie definiuje tego co jest produktem analizy, ten powinien zostać zdefiniowany. Doświadczenie autora cytowanego artykułu, mogę potwierdzić, on sam zaś przyznaje, że “poprawnego” opisania przedmiotu zamówienia prawnicy nie są w stanie dokonać co jest prawdą. W części “Prawa autorskie i kod źródłowy” w zasadzie Pan Marcin Maruta nie napisał nic o prawach autorskich do kodu oprogramowania a szkoda.

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 Specyfikacji, popularnie zwane metodami zwinnymi, 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ć do twórcy kodu).

Na zakończenie

Oczywiście nie wyczerpałem tu wszystkich kombinacji bytów prawnych w zawieranych umowach. Należy pamiętać o umowach z dostawcami aplikacji integrowanych, komponentów itp.. Celem moim było zwrócenie uwagi na najczęściej spotykane problemy, ich źródła i wskazanie jak się przed nimi zabezpieczyć.

Chętnie odpowiem na pytania i podejmę polemikę. Mam świadomość, że opisane tu zagadnienia bywają przedmiotem wielu sporów, sam je niejednokrotnie toczę i z dostawcami oprogramowania i z ich prawnikami. Uważam także, że obecne prawo pozwala na bardzo dobrą ochronę stron takich umów, wymaga to jednak ogromnej precyzji w konstruowaniu treści umów i tworzeniu dokumentów opisujących ich przedmiot co absolutnie nie wymusza tak zwanych “metod wodospadowych” w projektach.

Od lat stosuję w swoich analizach i projektach między innymi, diagramy takie jak powyższej. 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. 

Polecam też świetny tekst napisany okiem prawnika (autor mec. Renata Warchol-Lewicka):

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ć? (Source: TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK | Renata Warchol-Lewicka | Pulse | LinkedIn)