Od czasu do czasu miewam dyskusje na temat tego, kto i co powinien wytworzyć w projekcie dostarczania oprogramowania. Pojawia się problem: czym jest ów projekt. Po drugie: kto jest autorem i czego. Po trzecie: czym jest ta dokumentacja. Problem w tym, że w projektach IT w wyniku analiz powstają „jakieś wymagania” i tak na prawdę nie wiadomo czym one są… Dziwne? Czym jest produkt, którego „cechą funkcjonalną jest możliwość wbijania gwoździ”? Otoczakiem, pneumatycznym młotem czy może prostym ręcznym młotkiem? Co wygra przetarg gdzie kryterium będzie cena w 100%? Otoczak?

Po co tworzymy dokumentację wymagań?

Mój kolega prawnik ostatnio, w prostych słowach, dał odpowiedź: „dokumentacja jest po to by w sądzie wiadomo było czy przedmiot umowy został wykonany zgodnie z treścią umowy”. Nie muszą chyba dodawać, że dokumentacja tu, to opis przedmiotu umowy (albo jak kto woli, Opis Przedmiotu Zamówienia zwany OPZ, czyli opis dzieła jakie należy dostarczyć), załącznik do umowy na wykonanie i dostarczenie czegoś (tu oprogramowania). Dlatego zawsze uważam, że projekt z zakresu inżynierii oprogramowania (i nie tylko, chyba każdy tego typu) powinien mieć dwie części:

1. umowa na projektowanie
2. umowa na realizacje projektu

Obie umowy bazują na kodeksie cywilnym (umowa o dzieło) i na prawie autorskim (projekt to utwór i program to utwór). Opracowanie opisu tego co ma powstać, powinno być po stronie zamawiającego oprogramowanie (najczęściej zleca się to tak zwanemu analitykowi wymagań). Projekt (prawa do niego) pozostaje wtedy w rękach zamawiającego, więc pozornie jego know-how nie zostanie przejęte przez (potencjalnie) nieuczciwego wykonawcę i dostawcę oprogramowania.

Z drugiej strony w kuluarach konferencji nie raz słyszę, że niektóre firmy świadomie szukają dostawcy, który zna ich branże (czytaj konkurencje) z nadzieją, że wraz z usługą lub systemem ERP, przejmą choć część know-how jednego ze swoich konkurentów (źr.Audyt organizacji czy analiza?).

Niestety autorem oprogramowania jest wykonawca i ma prawo dysponowania tym oprogramowanie (to on udziela na oprogramowanie licencji zamawiającemu). Nie musi mieć praw, innych niż prawo korzystania z egzemplarza (załącznik do umowy na wykonanie), do opisu na podstawie, którego oprogramowanie powstało. Jest tu na szczęście pewne „ale”, więcej o tym w dalszej części.

Teraz chyba jasno widać „Po co tworzy się dokumentację projektu IT?” Czy dokumentacja taka (jaka, co zawiera) chroni przed przejęciem wiedzy biznesowej przez wykonawcę oprogramowania? Po drugie słowo „dokumentacja”, bez określenia co jest jej przedmiotem, nic nie znaczy. Dlatego piszę tu o dokumentacji w rozumieniu „opis tego co ma powstać”.

Byłem świadkiem lub uczestnikiem wielu dyskusji o prawach do produktu jakim jest oprogramowanie. Dyskusje były burzliwe, dostawcy oprogramowania bronią jak lwy tezy, że są jego posiadaczami w 100% bo wymagania nie są dziełem ani projektem. Otóż wymagania są dziełem, tyle że literackim, podobnie zresztą jak i oprogramowanie.

Zgodnie więc z prawem, zarówno sam program jak i dokument analizy, na bazie którego ono powstało, to równoprawne dzieła literackie w rozumieniu [[Ustawy o Prawie Autorskim i Prawach pokrewnych]]. Są chronione tylko jako treść. Jednak „treść” w wypadku programu to nic innego jak program.  W czym problem? W tym, że autor oprogramowania staje się posiadaczem i dysponentem wiedzy, jaką pozyskał i zawarł w oprogramowaniu w trakcie tworzenia tego oprogramowania. Dlaczego? Bo ta wiedza była konieczna do powstania oprogramowania a autorem opisu wymagań, treści analizy wymagań, projektu, i w końcu oprogramowania, jest najczęściej właśnie wykonawca oprogramowania.  Skoro jest autorem, jest także posiadaczem praw do niego (autorskich i majątkowych). Wytworzony program zawiera logikę biznesową zamawiającego  i jej posiadaczem oraz dysponentem całości jest wykonawca oprogramowania, jeżeli był także wykonawcą i autorem dokumentu opisującego wymagania.

Czy można temu zaradzić?

Tak. Przedmiotem ochrony prawnej może być algorytm, tu szczegółowy opis logiki biznesowej implementowanej w oprogramowaniu. Jeżeli taki opis powstanie, w wyczerpujący i jednoznaczny sposób opisujący nie tylko co, ale także jak program ma to robić, wykonawca tworząc oprogramowanie na bazie takiego opisu, tworzy utwór zależny i nie ma praw do dysponowania oprogramowaniem, które wytworzył bez zgody zamawiającego (posiadacza praw majątkowych do opisu tej logiki). Dlaczego? Bo to Zamawiający ma prawa autorskie majątkowe do opisu logiki biznesowej zaimplementowanej w programie. Twórca oprogramowania (programista) wykonał implementacje ale w tym wypadku nie jest autorem „algorytmu”  i nie może dysponować swobodnie wytworzonym tak oprogramowaniem, o ile oczywiście zamawiający nie przekazał mu praw do samego algorytmu.

Jak to zrobić? Opracować wymagania, ale nie w postaci typowej specyfikacji wymagań funkcjonalnych i poza-funkcjonalnych, bo ta nie niesie w sobie żadnego algorytmu. Modele przypadków użycia to także tylko funkcjonalności systemu, zgodnie z UML, przypadki użycia to opis tak zwanej „czarnej skrzynki”. Potrzebny jest tu opis tak zwanej „białej skrzynki”, czyli dokument zawierający szczegółowy opis tego jak realizowane są poszczególne cechy (funkcjonalności) systemu. Innymi słowy, opis dokumentujący dane jakie mają być przetwarzane i szczegółowy opis tego przetwarzania. W zasadzie jest to projekt tego oprogramowania (w metodyce MDA nazywa się to model systemu PIM czyli [[Platform Independent Model]], powinien go poprzedzać model CIM czyli [[Computation Independent Model]]). Taka dokumentacja nie pozostawia wątpliwości, który dokument co zawiera. Model PIM to właśnie owa biała skrzynka. Model PSM to już dzieło wykonawcy ale w tym przypadku jest to utwór zależny (powstało na bazie PIM) i wykonawca bez zgody autora modelu PIM nie może swobodnie dysponować oprogramowaniem jakie wytworzył.

Ale płyną wnioski z tych dyskusji z firmami programistycznymi:

• analiza biznesowa daje jako produkt opis (model) firmy, jest to niejako produkt audytu organizacji, stwierdzenie stanu faktycznego i nie ma tu mowy o prawach do czegokolwiek poza dziełem literackim jakim jest treść, w tym model CIM, takiej analizy (umowa o dzieło), można i należy taki dokument jednak potraktować  i chronić jednocześnie jako tajemnicę przedsiębiorstwa na mocy USTAWY z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji oraz jako dzieło na mocy USTAWY z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych, dodatkowo warto skorzystać z art. 72 prim Kodeksu Cywilnego (Art.72 prim, par.1. Jeżeli w toku negocjacji strona udostępniła informacje z zastrzeżeniem poufności, druga strona jest obowiązana do nieujawniania i nieprzekazywania ich innym osobom oraz do niewykorzystywania tych informacji dla własnych celów), jednak tu nadal chronimy tylko informacje źródłowe, wystarczająco dokładnie opisane stanowią jednak utrudnienie handlem efektami ich wykorzystania.
• projekt oprogramowania (model PIM, kompletny projekt implementacji logiki biznesowej np. w UML) to utwór (zawiera algorytmy), który wymaga udzielenia licencji wykonawcy oprogramowania na użycie go do wytworzenia oprogramowania, które staje się tym samym dziełem zależnym (prawo autorskie) i dostawca (programista) nie może tym programem dalej handlować bez zgody zamawiającego; warunek: projektant nie może być pracownikiem programisty, prawa do projektu muszą być po stronie zamawiającego oprogramowanie,

Generalnie warto umieścić wszystkie te elementy w umowie na dostarczenie oprogramowania. W przypadku umowy z analitykiem zalecam pierwszy punkt. Produkt analityka (podobnie jak dedykowany produkt biura architekta budowlanego) powinien w całości przejść na własność zamawiającego, w końcu opisuje dokładnie jego firmę.

Na zakończenie

Jak ustrzec się przed wyniesieniem z firmy tajemnicy jej funkcjonowania, tworzonej latami organizacji, procedur i procesów, reguł biznesowych?  Jak zatrzymać w firmie wiedzę mino zamawiania oprogramowania, które siła rzeczy ja zawiera?

Problem nie jest prosty. Sami prawnicy nie są między sobą zgodni co do tego, gdzie leży granica pomiędzy utworem literackim a szczegółowym opisem rozwiązania. Wydaje się, że kluczem jest to sposób tworzenia opisu tego co ma powstać. Standardem w IT jest opis wymagań, ten jednak z urzędu czyni autora oprogramowania także posiadaczem opisu logiki w nim zawartej, bo on jest autorem jej opisu.

Wyjściem wydaje się zawarcie w umowie nie opisu wymagań na oprogramowanie a projektu oprogramowania. Metodą zdefiniowania granicy, za którą mamy nie utwór literacki (specyfikacje wymagań) a projekt wraz z algorytmami, jest metodyka MDA. Wtedy firma realizująca zamówione oprogramowanie tworzy utwór zależny a zamawiający nie traci panowania nad tak powstałym produktem. Jest to sytuacja jaką znamy w branży budowlanej: developer dostaje projekt architektoniczny, i sam fakt, że postawił na jego podstawie obiekt nie daje mu żadnych praw do niego, gdyż wystarczająco szczegółowy projekt obiektu pozostaje dziełem projektanta a nie jego wykonawcy. Wielu dostawców oprogramowania, z oczywistych powodów, neguje to, że „nie będą posiadaczem wszelkich praw do wytworzonego przez siebie oprogramowania”,  ale tu niestety mogą nie mieć racji.

Jednak zawsze, bo nie ma złotej reguły,  wymaga to konsultacji i szczegółowego określenia zawartości dokumentacji, która ma stać się „opisem przedmiotu zamówienia”.

Jakie mogą być skutki takich zaniedbań? Np. przetargi z wolnej ręki (czyli uniemożliwianie konkurencji lub jak kto woli vendor-lock czyli uzależnianie klientów od siebie a czym troszkę tu (Urzędnikom i ustawodawcy zawdzięczamy utratę 100 mln euro), więcej tu: http://pppit.org.pl/?a=98). Polecam też lekturę opracowania:

brak przeniesienia autorskich praw majątkowych do oprogramowania i/lub brak zapewnienia dostępu do kodu źródłowego rozwiązania informatycznego i należycie opracowanej dokumentacji. (źr. Analiza rynku zamówień publicznych na narzędzia informatyczne w okresie od 1 stycznia do 30 czerwca 2011 r..)

Z innej strony temat poruszyłem także tu:

W kuluarach konferencji nie raz słyszę, że niektóre firmy świadomie szukają dostawcy, który zna ich branże (czytaj konkurencje) z nadzieją, że wraz z usługą lub systemem ERP, przejmą choć część know-how jednego ze swoich konkurentów (źr. Audyt organizacji czy analiza?).

P.S.

Pewien lider na rynku dostawców systemów ERP, ma zapis w umowie mówiący, że przejmuje prawa autorskie do całości pomysłów i kodu (funkcjonalności) jaki powstanie podczas prac z klientem nad dostosowaniem dostarczanego systemu ERP (czyli tak zwana kastomizacja). Czyli know-how zamawiającego idzie do konkurencji – firma ta chwali się na rynku, że ma referencyjne branżowe rozwiązania ?

Byli bardzo zaskoczeni (i wściekli) gdy dowiedzieli się, że zgodnie z umową analizę i projekt implementacji (model PIM) nowych funkcjonalności, których nie ma ich ERP robię ja. Ich tłumaczenie, że  tylko oni maja wiedzę by to robić bo to ich ERP było nie do obrony: pokazałem im opis ich własnego systemu, jego metodyki wdrożenia i informację, że jest wykonany znanym narzędziem obiektowym i w znanej technologii, i że projekt jaki ode mnie dostaną będzie wystarczający i prawidłowy by go zaimplementować w tym ERP. Niestety, tu nie przejęli wiedzy i pomysłów zamawiającego. Tak się da zrobić, trzeba nie dać się szantażować swojemu własnemu dostawcy. 

To dlatego dostawcy Ci (nie tylko ERP i inne gotowe systemy, także firmy tworzące oprogramowanie dedykowane) zrobią wszystko, by zastana u klienta analiza poszła do kosza i naciskają na to, by analizę wymagań (przedwdrożeniową) powtarzać rękami ich pracowników. Nie prawdą jest, że analizę wymagań może poprawnie zrobić wyłącznie dostawca oprogramowania. Dostawca gotowego systemu ma wykonać analizą pokrycia wymagań przez dostarczane przez siebie oprogramowanie (opisana tu kiedyś analiza gap/fit). Deweloperzy dostawcy spokojnie mogą wykonać implementację wymaganych nowych funkcjonalności  na bazie poprawnego projektu. Problem mają w tym, że wtedy nie mogą go przejąć.

Tu o różnicy pomiędzy analizą biznesową a przedwdrożniową: https://it-consulting.pl//index.php/2011/01/21/analiza-przedwdrozeniowa-%E2%80%93-czym-jest/

P.S. 2

Niezależnie od powyższego zalecam konsultacje z prawnikiem w celu ustalenia stanu prawnego na dzień zawarcia umowy.

Składam także specjalne podziękowania Piotrowi Waglowskiemu, prowadzącemu świetny, prawniczy blog  VaGla.pl Prawo i Internet za przejrzenie tego artykułu i cenne wskazówki.

P.S. 3, 29 Listopad 2011, zapada orzeczenie potwierdzające powyższe:

Court of Justice of the European Union, PRESS RELEASE No 129/11, Luxembourg, 29 November 2011, Press and Information Advocate General?s Opinion in Case C-406/10, SAS Institute Inc. v World Programming Ltd

1. The source code, which underlies a computer program, is written by the programmer. That code, composed of words, is intelligible to the human mind. However, it is not executable by the computer. To become so, it needs to be compiled so that it can be translated into binary-form computer language, usually the figures 0 and 1. This is known as the object code.
2. Council Directive of 14 May 1991 on the legal protection of computer programs (OJ 1991 L 122, p. 42).
3. Amongst other things, preparatory design work, where it leads to the creation of a program, is also protected by copyright applicable to computer programs. That design work can include, for example, a structure or organisational chart developed by the programmer which is liable to be re-transcribed in source code and object code, thus enabling the machine to execute the computer program. That organisational chart developed by the programmer could be compared to the scenario of a film (see the Opinion in Case C-393/09).

Link: http://curia.europa.eu/jcms/upload/docs/application/pdf/2011-11/cp110129en.pdf