Wczoraj miała miejsce konferencja Forum prawa nowych technologii zorganizowana przez Centrum Promocji Informatyki. Jednak to nie mój referat z tego seminarium, a pewna konkluzja po burzliwej dyskusji, będzie dziś tematem przewodnim.

To o czym był mój referat, to ochrona know-how zamawiającego (opis sposobu pracy organizacji) i ochrona tego co zamówił i za co zapłacił (oprogramowanie jak utwór). Ale tu będzie o kodzie i prawach do niego… (kto nie był na konferencji niech żałuje ;))

Przytoczmy na początek definicję “tego co chroni prawo autorskie” czyli czym jest “przedmiot prawa autorskiego”:

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) (źr. Ustawa z dnia 4 Lutego 1994 roku o prawie autorskim i prawach pokrewnych).

2/3 konferencji prawnicy wykazywali, że jedyne co można skutecznie chronić prawem (albo wyceniać) to stan udokumentowany. Czyli, jeżeli chcemy chronić wiedzę o swojej wewnętrznej organizacji, tak zwany know-how, oraz pomysł na to co powinno “umieć” zamawiane oprogramowanie by nam pomagało, należy posłużyć się prawem autorskim, tajemnicą przedsiębiorstwa i mieć to w postaci udokumentowanej. Zapis, który od lat pomaga mi i moim klientom chronić projekty i know-how brzmi tak (można go użyć w swoich dokumentach :)):

Treść dokumentu jest chroniona na mocy USTAWY z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji oraz na mocy USTAWY z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Posiadanie egzemplarza tego opracowania nie stanowi nabycia jakichkolwiek praw do jego treści.

(szczegóły ustaw i paragrafów były prezentowane na seminarium, w razie potrzeby polecam wizytę w dobrej kancelarii prawnej).

Ale po kolei czyli…

Jak to – ochrona know-how i kodu który ktoś nam napisał – można robić

Opiszę to językiem dla  osób nie znających inżynierii oprogramowania.

Pierwszą rzeczą jaką warto chronić jest wypracowana wewnętrzna organizacja pracy, sposób pracy firmy czyli procedury, reguły biznesowe, kompetencje pracowników (i wiele innych). Kompletny taki opis, raport z audytu organizacji,  zawiera modele procesów biznesowych skojarzone z procedurami, zakresami obowiązków, regułami biznesowymi itp.  Tak powstaje udokumentowane nasze “know-how”.

Kolejna rzecz to opracowanie opisu a czasem projektu, oprogramowania, które chcemy nabyć lub zamówić, a konkretnie tego “co i jak ono powinno umieć”. Opis taki nie powinien  poprzestawać tylko na tym co-ma-system-robić (wymagania w postaci przypadków użycia). Firmy różnią się tym jak-to-jest-robione u nich, więc nie wystarczy napisać, że “system ma wspierać przyjęcia na magazyn i stosować ustalone metody zarządzania kosztami produktów”. Powierzenie dostawcy zadania udokumentowania (analiza przed-wdrożeniowa) np. “metody zarządzania produktami”  na 99% zaowocuje opisem tego co dostawca może zaoferować, a nie tego jak-pracuje-zamawiający i co jest mu potrzebne. Po drugie autorem “pomysłu” będzie dostawca (wykonawca) więc do niego będą należały prawa do własności intelektualnej zawartej w oprogramowaniu – a tego właśnie nie chcemy.

Co i jak udokumentować? Czy to się da?

Owszem, poniżej metoda opisana jako standard (opis dostępny za darmo bez żadnych opłat) na stronach https://www.omg.org/mda:

Co możemy. Etap pierwszy to udokumentowanie know-how firmy czyli model organizacji i sposobu jej działania (opisywany na stronach tego bloga wielokrotnie). Jak już wspomniałem, elementem know-how są udokumentowane modele procesów biznesowych, reguły biznesowe  i struktura organizacji. Ten opis, jako dokument,  jest chroniony prawem autorskim jako dzieło, treść zaś jest chroniona prawem o przeciwdziałaniu nieuczciwej konkurencji jako know-how firmy. Warunek: taki opis MUSI istnieć a prawa majątkowe do niego powinien posiadać opisany w nim podmiot. Autor, jeżeli nie był pracownikiem firmy podczas tworzenia, powinien mieć dodatkowo umowę o poufności i po zakończeniu pracy przekazać pisemnie prawa majątkowe do dzieła swojemu klientowi.

Tak więc, jeżeli ktoś z zewnątrz robi taką analizę (np. pracownik dostawcy oprogramowania czy niezależny konsultant) i nie chce przekazać praw majątkowych do opracowania, organizacji analizowanej, to należy się zacząć bać. Na powyższym diagramie ten etap nazywa Computing Independent Mode (model działania organizacji na poziomie niezależnym od używanych systemów IT).

Chcemy mieć oprogramowanie wspomagające nasz biznes

Na bazie powyższej dokumentacji powstaje opis, które obszary działania firmy chcemy wspierać oprogramowaniem i jak. To określenie zakresu projektu. Następnie, w modelach procesów wskazujemy czynności, które mają być wspierane nowym oprogramowaniem. To oczekiwane funkcjonalności (usługi aplikacyjne) nowego oprogramowania (w notacji UML nazywane przypadkami użycia). Dodajemy do nich elementy jakościowe czyli wymagania poza-funkcjonalne (ograniczenia np. niezawodność, bezpieczeństwo itp.). To jednak za mało, to tylko opis tego co-system-ma-robić (idea).

Jednoznaczne są dopiero opisy logiki biznesowej, czyli jak-system-ma-to-robić (w końcu system poza zapisywaniem, przetwarza nasze dane), opis tego, czego oczekujemy od tego oprogramowania (co ono powinno umieć). To kolejny opis, udokumentowane coś, co chcemy chronić. Zakładam, że specyfika firmy, wypracowana logika biznesowa, to dobro warte ochrony.  Taki opis to warstwa druga od góry na powyższym diagramie (model oprogramowania PIM, Platform Independent Model). Do tego dokumentu także należy mieć prawa majątkowe. Ten model to już szczegółowy projekt, jedyne czego może nie zawierać to specyfika użytego języka programowania czy wykorzystane elementy cudzego oprogramowania (tak zwane biblioteki, frameworki, środowisko systemowe pracy itp…). Także inne, nie będące specyfiką firmy (tym co chcemy chronić) standardowe elementy takie jak logowanie do systemu czy np. sposób drukowania.

A teraz niech nam to dostarczą

No to szukamy dostawcy (wykonawcy) oprogramowania: robimy listę potencjalnych dostawców, ktoś wygrywa przetarg, podpisujemy umowę o poufności, wykonawca dostaje do wykorzystania udokumentowany know-how, prawo autorskie chroni  taki opis z zasady. Wyłaniamy dostawcę, projekt dobiega końca. Dostawca  nie ma możliwości prawnej zaoferowania tego oprogramowania (tego co obejmuje nasza specyfikę) nikomu innemu. Wszystko co zrobił na bazie naszej dokumentacji jest dziełem zależnym, bez naszej zgody wykonawca nie ma prawa tym kodem dysponować. Jesteśmy uratowaniu :)!

A może chcecie prawa do kodu źródłowego?

A jasne, możemy chcieć. “No to zapłaćcie za to prawo”. A przepraszam za co teraz? Kod, który powstał to utwór zależny, jest więc chroniony i już mamy na niego wyłączność, nie musimy ekstra za to płacić. Ale nie chcemy tego sami pisać (kodować) jeszcze raz. No dobrze, patrzymy na faktury, a tam jest kilkaset godzin programistów. Czyli co? Już zapłaciliśmy za ich pracę, za ten kod! Wystarczy!

Kiedy pojawia się problem?

W większości przypadków z jakimi się niestety spotykam to projekty, w których nie powstała opisana tu dokumentacja. Jaki mamy efekt? No jest kod, wszelkie prawa do niego i jego logiki ma wykonawca (jest autorem całości).  Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych podlega wyłącznie ochronie jako dzieło literackie, jednak niestety to-co-program-ma-robić to tylko idea, a ta nie podlega ochronie (stwierdzenie faktu, że wystawiamy faktury, jako treść, nie stanowi żadnego zdatnego do ochrony tajemnicą firmy know-how). Tak więc wszelkie prawa do kodu ma w takim wypadku programista bo sam od zera to napisał (kod).

Pada propozycja:  za dodatkowe pieniądze sprzedamy prawa majątkowe do kodu, będziecie się Państwo czuli bezpiecznie. I teraz pytanie: jaką wartość ma nieudokumentowany kod oprogramowania? Tysiące linii kodu programu, nie raz kilka milionów, pisany bez projektu w wielu iteracjach. Mamy którąś tam jego wersję, w końcu powstawał w bólach, wielokrotnie modyfikowany, bez projektu. Nakład pracy wielokrotnie przewyższający jego powtórne przepisanie. Kto i jakim kosztem będzie ten kod analizował by go zrozumieć i rozwijać? Ten kod, bez jego autora, jest z reguły BEZWARTOŚCIOWY a My, bez tej opłaty,  nie mamy żadnych praw do tego za co zapłaciliśmy (poza licencją czyli prawem do korzystania). Pat.

Tak więc niejednokrotnie oferta na sprzedaż praw do kodu to zwykła “ściema”!

A jak to wygląda w przypadku zakupu gotowego ERP i jego “kastomizacji”? Jest to cudzy produkt, zapewne możemy dostać prawa do kodu “na własny użytek” w co jednak wątpię, raczej dostaniemy licencje na używanie. A nasze know-how? Jeżeli nasze dedykowane wymagania zostały  “zrealizowane” w postaci kastomizacji kodu tego produktu, to i tak nadal jest on własnością dostawcy (producenta) i nic nam do niego. Niektóre firmy idą dalej, “podtykają” swoim klientom aneks do umowy, z zapisem, że kod powstały podczas wdrożenia (w tym kastomizacja), zawierający pomysły na nowe funkcjonalności  w całości przechodzi na własność dostawcy oprogramowania ERP. Jeżeli zgodzicie się na to, nie zdziwcie się gdy dowiecie się np. z gazety, że jakaś firma  kupiła od Waszego “partnera” moduł z logiką biznesową “waszego pomysłu”…

U niektórych prawników można się spotkać z tezą:

Zgodnie ustawą o prawie autorskim i prawach pokrewnych programy komputerowe podlegają ochronie jak utwory literackie, o ile przepisy rozdziału VII ustawy nie stanowią inaczej. Taki zapis statuuje więc ogólną zasadę włączenia programów komputerowych pod reżim ochrony prawnoautorskiej, zrównując je w tym aspekcie z utworami literackimi.

Ochrona przyznana programowi komputerowemu obejmuje wszystkie formy jego wyrażenia. Natomiast idee i zasady będące podstawą jakiegokolwiek elementu programu komputerowego, w tym podstawą łączy, nie podlegają ochronie (w prawie autorskim idee ? wszelakie ? nie są chronione). O ile elementy tekstowe programu (w znaczeniu konkretnego przedstawienia ciągu instrukcji) podlegają ochronie, o tyle w przypadku elementów pozatekstowych (algorytm – struktura programu języka programowania) trzeba się raczej liczyć z ich wyłączeniem spod ochrony prawa autorskiego.  (Kod źródłowy – aspekty prawne).

To podejście jest niekompletne, gdyż pomija aspekt (ewentualny etap) projektowania jako etapu tworzenia oprogramowania. Zresztą nie tylko oprogramowania ale także specyfiki organizacji, która może zostać “zawarta” w oprogramowaniu w postaci specyficznej, unikalnej  logiki działania. 

Skoro “Ochrona przyznana programowi komputerowemu obejmuje wszystkie formy jego wyrażenia” to znaczy, że każdy jednoznaczny jego projekt także. Ustawa nie stanowi, że jedynie forma tekstowa programu podlega ochronie, ochronie podlega każda forma wyrażenia dzieła. Prawo autorskie chroni w jednakowym stopniu tekst, zdjęcia czy prace graficzne, schemat blokowy (szczegółowy algorytm) także podlega ochronie, bo spełnia 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 idea a program.

Jeżeli dodatkowo ten algorytm opisuje specyfikę pracy danej firmy to podlega także ochronie jako tajemnica przedsiębiorstwa. Jest więc niejako podwójnie chroniony. Oczywiście, co podkreślam po raz kolejny, schemat blokowy o jakim mowa musi być jednoznaczny, nie może to być tylko zapis “pomysłu”. Z perspektywy diagramów BPMN i UML (graficzne języki) mamy więc:

1. BPMN: model procesu na wysokim poziomie abstrakcji (np. dwa bloczki: proces sprzedaży połączony z procesem obsługi reklamacji) to idea,
2. BPMN: dokładny scenariusz (procedura) obsługi sprzedaży specyficzny dla  konkretnej firmy, obrazujący specyfikę kompetencji jej pracowników i funkcjonowania, to podlegający ochronie opis know-how firmy, diagram to opisujący wraz z opisem i komentarzami to utwór chroniony prawem autorskim. Stanowi zapis know-how. 
3. UML: diagram przypadków użycia: to idea pomysłu (podobnie jak tekstowa specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych), to wyłącznie dzieło literackie, program jaki powstanie na tej podstawie nie jest wiązany z taką specyfikacją jako utwór zależny, jest dziełem programisty.
4. UML: diagram klas – model pojęciowy, to jedynie idea,
5. UML: diagram klas jako projekt logiki i struktury programu (zawiera atrybuty i operacje, tam gdzie to konieczne, także algorytmy metod) oraz uzupełniające go diagramy maszyny stanowej i sekwencji (obrazują szczegółowo jak oprogramowanie ma działać) to już zapis analogiczny do kodu programu, jest chroniony jako dzieło literackie, ale kod jaki powstanie na tej postawie jest praktycznie w 100% jego odzwierciedleniem (wierne odzwierciedlenie schematu blokowego). Podlega ochronie jako dzieło literackie oraz także jako know-how. Program jaki powstanie na podstawie tak opracowanego opisu ma status tłumaczenia (utwór zależny). 

Więc kod napisany “pod dyktanto” projektanta nie jest niezależnym dziełem programisty, nie ma on (programista) prawa do swobodnego dysponowania takim kodem, podobnie jak tłumacz tekstu nie nabywa automatycznie ani praw do dysponowania tłumaczeniem, które opracował, ani,  w szczególności,  do tekstu źródłowego, który przetłumaczył.

Zaprezentowana opinia prawna, moim zdaniem pomija więc ważny fakt, że poza językami programowania “tekstowymi”: takimi jak Java, Pascal czy .NET istnieją także języki graficzne takie jak np. UML. Opinia powyższe (przytoczony cytat) jest prawdziwa pod warunkiem, że mowa o powyższych diagramach na poziomie ogólnym, idei. Jednak projekty oznaczone kolorem czerwonym to przypadki podlegające już pełnej ochronie.