Nie licząc prostych systemów rejestrujących, aplikacje biznesowe mają zaimplementowane reguły biznesowe, algorytmy i inne elementy stanowiące know-how firmy. Znaczna część z nich to różnego rodzaju powszechnie znane najlepsze praktyki oraz reguły narzucone obowiązującym prawem. Wiele organizacji ma jednak swój własny dorobek budujący ich przewagę rynkową. Dorobek ten to receptury produktów, wypracowane procedury organizacyjne i reguły biznesowe, systemy zarządzania ryzykiem i wiele innych.

Ochrona know-how zamawiającego oprogramowanie (opis sposobu pracy organizacji) i ochrona tego, co zamówił i za co zapłacił (oprogramowanie jako utwór), to temat tabu większości projektów informatycznych.

Przytoczmy na początek definicję przedmiotu prawa autorskiego, czyli tego, co jest tym prawem chronione. Według art. 1 pkt 1 Ustawy z dnia 4 Lutego 1994 roku o prawie autorskim i prawach pokrewnych, „przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór)”.

Prawnicy od lat wskazują, że jedyne, co można skutecznie chronić prawem (albo wyceniać), to stan udokumentowany: opis przedmiotu umowy. Innymi słowy, aby chronić wiedzę o swojej wewnętrznej organizacji – tzw. know-how – oraz własny pomysł na to, jakie funkcje i w jaki sposób powinno realizować zamawiane oprogramowanie, należy posłużyć się prawem autorskim i tajemnicą przedsiębiorstwa. Koniecznie w postaci udokumentowanej.

Dokumentowanie know-how

W szczególności warto chronić wypracowaną wewnętrzną organizację pracy, czyli m.in. procedury, reguły biznesowe czy kompetencje pracowników. Kompletny opis tych kwestii, raport z audytu organizacji, powinien zawierać modele procesów biznesowych skojarzone z procedurami, zakresami obowiązków, regułami biznesowymi itp. Takie opracowanie, jeżeli jest dostatecznie precyzyjne i jednoznaczne, stanowi udokumentowane know-how opisanej organizacji.

W przypadku zamówienia oprogramowania u zewnętrznego dostawcy to zamawiający powinien dokładnie określić, jakie kwestie ma podejmować zamawiane rozwiązanie, a także w jaki sposób powinno to robić. Dlaczego? Ponieważ firmy różnią się sposobami realizacji poszczególnych procesów – to jeden z elementów know-how. Jeżeli autorem dokumentacji jest dostawca (wykonawca), to do niego będą należały prawa autorskie sporządzonego dokumentu, a tym samym do własności intelektualnej zawartej w oprogramowaniu. Co więcej, powierzenie dostawcy zadania dokumentowania pracy organizacji (analizy przedwdrożeniowej) z bardzo dużym prawdopodobieństwem zaowocuje opisem tego, co dostawca może zaoferować, a nie rzetelnym opisem procesów firmy i jej potrzeb.

Co i jak udokumentować?

Prawidłowo przygotowana dokumentacja powinna zawierać m.in. modele procesów, projektowane funkcje i zachowania oraz zapewniać separację warstwy biznesowej oraz aplikacyjnej od platform technologicznych. Dobrym standardem jest architektura MDA (www.omg.org/mda). Diagram przedstawia fragment opisu procesu projektowania zorientowanego na modele.

Etap pierwszy to udokumentowanie know-how firmy, czyli model organizacji i sposobu jej działania. Elementami know-how są udokumentowane modele procesów biznesowych, reguły biznesowe i struktura organizacji. Dokument zawierający taki opis jest – jako dzieło – chroniony prawem autorskim, jego treść z kolei (to, o czym napisano) jako know-how firmy podlega ochronie w związku z prawem o przeciwdziałaniu nieuczciwej konkurencji.

Pojawia się jednak warunek: opis musi być precyzyjny, a wyłączne prawa majątkowe do dokumentu i jego treści powinny być w posiadaniu opisanego w nim podmiotu. Jeżeli autor dokumentu nie był podczas jego tworzenia pracownikiem firmy, powinien mieć podpisaną dodatkowo umowę o poufności i po zakończeniu pracy przekazać pisemnie prawa majątkowe do dzieła swojemu klientowi, tj. firmie, dla której przygotowywał dokumentację. Jednoznaczność opisu (dokumentu) gwarantuje sformalizowana forma, jaką są systemy notacyjne.

Jeżeli analizę na rzecz firmy prowadziła osoba z zewnątrz, np. pracownik dostawcy oprogramowania czy niezależny konsultant, brak zgody na przekazanie praw majątkowych do opracowania powinien wzbudzić daleko posunięte podejrzenia. Na sąsiednim diagramie ten etap nazywa się Computation Independent Model (model organizacji niezależny od technologii IT). Zwyczajowo jego autora nazywa się analitykiem biznesowym.

Cel: oprogramowanie wspomagające biznes

Na bazie dokumentacji powstaje opis wskazujący obszary działania firmy, które chcemy wspierać oprogramowaniem, oraz sposób, w jaki ma się to odbywać. Opis określa zarazem zakres projektu. Następnie w modelach procesów należy wskazać czynności, które mają być wspierane nowym oprogramowaniem. To oczekiwane funkcje (usługi) nowego oprogramowania (nazywane w notacji UML przypadkami użycia). Do tych funkcji dodać należy elementy jakościowe, czyli wymagania pozafunkcjonalne, takie jak niezawodność czy odpowiedni poziom bezpieczeństwa.

Trzeba przy tym pamiętać, że opis obszarów działania i funkcji to wciąż za mało, by przygotować oprogramowane; to jedynie opis idei, czyli „tego, co system ma robić”. Kolejny etap to uzgodnienie „przypadków użycia”, czyli przekształcenie procesów na usługi aplikacyjne (ten etap nie został ujęty na sąsiednim diagramie). Jednoznaczny opis aplikacji, a więc mechanizmu jej działania, to wciąż jedynie opis logiki biznesowej i oczekiwań, wskazujący, w jaki sposób system ma realizować usługi. Taki opis dokumentuje to, co firma powinna chronić, w tym m.in. specyfikę procesów czy wypracowaną logikę biznesową.

Konieczny jest także model przedstawiający logikę oprogramowania (na diagramie to druga od góry warstwa – PIM, Platform Independent Model). Proces jego budowania, uwzględniający rolę projektanta, wykonawcy analizy, także powinien zakładać przekazanie praw majątkowych na rzecz zamawiającego. Tak przygotowany model zawierać będzie już szczegółowy projekt logiki biznesowej i mechanizm działania aplikacji. Nie ma tu jeszcze mechanizmu implementacji, który projektować będzie deweloper.

Poszukiwania właściwego dostawcy

Mając przygotowaną dokumentację, można przystąpić do poszukiwania dostawcy oprogramowania. W tym celu należy przygotować listę potencjalnych partnerów; w końcu któryś z nich wygra przetarg. Konieczne będzie podpisanie umowy o poufności. Następnie wykonawca dostaje do wykorzystania udokumentowane know-how w postaci modelu CIM (kontakt projektu) oraz PIM projektu (opisy obszarów, które ma pokrywać oprogramowanie, oraz sposób, w jaki ma to robić). Taki dokument z zasady także chroniony jest prawem autorskim.

Po zakończeniu implementacji projektu dostawca nie będzie miał prawnej możliwości zaoferowania wykonanego oprogramowania (komponentu, modułu realizującego opisaną specyfikę) nikomu innemu. Wszystko, co zrobił na bazie naszej dokumentacji, jest dziełem zależnym; bez zgody zamawiającego wykonawca nie ma prawa obracać tym kodem.

Prawa do kodu źródłowego

Dostawcy niejednokrotnie żądają dodatkowej zapłaty za dostęp do kodu źródłowego. Tymczasem zamawiający ma pełne prawo oczekiwać dostępu do stworzonego dla siebie kodu źródłowego. Dlaczego? Ponieważ kod, który powstał na jego zamówienie, jest dziełem zależnym projektu PIM. Oznacza to, że jest chroniony, a zamawiający ma do niego wyłączność – nie musi ponosić z tego tytułu dodatkowych kosztów; kilkaset opłaconych godzin pracy programistów jest wystarczającą zapłatą. Oczywiście, osobną kwestią jest prawo do modyfikacji kodu, to także dzieło chronione.

Co w przypadku braku dokumentacji?

W większości projektów, z jakimi się spotykam, niestety nie dba się o stworzenie opisanej tu dokumentacji. Jaki jest efekt podobnej sytuacji? Wszelkie prawa do kodu i logiki biznesowej, jaka za nim stoi, ma wykonawca oprogramowania – w końcu jest autorem całości. Specyfikacja wymagań funkcjonalnych i pozafunkcjonalnych podlega ochronie wyłącznie jako dzieło literackie; niestety, „to, co system ma robić”, to jedynie idea, a ta ochronie już nie podlega. Stwierdzenie faktu, że np. ktoś komuś wystawia fakturę w toku sprzedaży, nie stanowi żadnej podstawy do ochrony firmowego know-how. Wszelkie zaś prawa do kodu ma dostawca, ponieważ od zera stworzył kod aplikacji tylko na bazie rozmów i wywiadów.

Dostawca może zaproponować, że za dodatkowe pieniądze sprzeda prawa majątkowe do kodu. W tej sytuacji należy zadać sobie pytanie, jaką wartość ma nieudokumentowany kod oprogramowania? To przecież tysiące linii kodu, pisane bez projektu w wielu iteracjach; wdrożony program to dopiero kolejna z wielokrotnie modyfikowanych wersji. Kto i jakim kosztem miałby ten kod analizować, aby go zrozumieć i rozwijać? Kod bez autora jest zwykle bezwartościowy, a zamawiający i tak nie ma do niego żadnych praw – oczywiście poza licencją, czyli prawem do korzystania – dopóki nie dopłaci za przekazanie praw majątkowych. Oznacza to, że bardzo często oferta na dodatkową sprzedaż praw do kodu to po prostu nadużycie.

Zakup i customizacja gotowych aplikacji

Inaczej mają się sprawy w przypadku zakupów gotowych rozwiązań, np. aplikacji ERP. To cudze produkty, na które trudno otrzymać prawa do kodu choćby na własny użytek – zwykle zakup gotowego oprogramowania odbywa się poprzez udostępnienie przez dostawcę licencji na używanie. Co w takim przypadku z firmowym know-how? Jeżeli wymagania zamawiającego zostały zrealizowane w postaci specjalnie opracowanej customizacji kodu gotowego produktu, wciąż pozostaną własnością dostawcy (producenta).

Niektórzy dostawcy podpisują z klientami aneksy do umów zawierające zapisy, że kod powstały podczas wdrożenia (w tym customizacja) w całości przechodzi na własność dostawcy oprogramowania ERP – wraz z pomysłami na nowe funkcjonalności. Jeżeli zamawiający zgodzi się na taki zapis, nie powinno go dziwić, gdy z mediów dowie się, że inna firma kupiła od danego dostawcy moduł zawierający logikę biznesową wypracowaną przy jego projekcie…

Podkreślam: ochrona prawna przyznana programowi komputerowemu obejmuje wszystkie formy jego wyrażenia. Natomiast idee i zasady będące podstawą którejkolwiek z funkcji programu komputerowego nie podlegają ochronie; w prawie autorskim idee nie są chronione. O ile zatem elementy tekstowe programu (w znaczeniu konkretnego przedstawienia ciągu instrukcji) podlegają ochronie, o tyle w przypadku elementów pozatekstowych (know-how) trzeba się raczej liczyć z ich wyłączeniem spod ochrony prawa autorskiego.

„Ochrona przyznana programowi komputerowemu obejmuje wszystkie formy jego wyrażenia" – oznacza to, że ochronie podlega także każdy jego jednoznaczny projekt. Nie tylko forma tekstowa, ale i zdjęcia, prace graficzne czy schemat blokowy (szczegółowy algorytm) – wszystkie te elementy spełniają kryterium unikalności.

Skoro mamy technologię (metody) pozwalającą napisać kod programu na bazie jego schematu blokowego (a nawet czasem automatycznie wygenerować), to taki dokładny schemat blokowy także podlega ochronie z tytułu prawa autorskiego jako dzieło. To już nie jest tylko idea. Co więcej, jeżeli taki algorytm dodatkowo opisuje specyfikę pracy danej firmy, podlega także ochronie jako tajemnica przedsiębiorstwa. Jest więc niejako podwójnie chroniony. Warunkiem będzie jednoznaczność schematu blokowego – nie może to być tylko zapis „pomysłu”. Z perspektywy diagramów BPMN i UML (graficzne języki) mamy więc możliwość jednoznacznego dokumentowania i ochrony know-how.

Kod napisany pod dyktando projektanta nie jest niezależnym dziełem programisty; osoba ta nie ma prawa do swobodnego dysponowania takim kodem, podobnie jak tłumacz tekstu nie nabywa praw do dysponowania tłumaczeniem, które opracował, ani do tekstu źródłowego, który przetłumaczył. Know-how firmy, zawarte w oprogramowaniu, nadal jest chronione.

Autor jest niezależnym analitykiem IT i projektantem systemów wyspecjalizowanym w modelowaniu procesów biznesowych, analizie wymagań i pomocy wdrożeniowej.