Korzystanie pośrednie nową obawą użytkowników systemów ERP

it consulting logoNiedawno blady strach padł na użytkowników oprogramowanie SAP AG za sprawą pewnego procesu i wyroku: "Po niedawnym orzeczeniu brytyjskiego Sądu Najwyższego, który potwierdził prawo firmy SAP do naliczania opłat za pośrednie korzystanie z systemów SAP przy użyciu takich aplikacji innych firm jak Salesforce, WorkDay i QlikView, korzystanie pośrednie jest obecnie wymieniane przez klientów firmy SAP jako główna obawa w obszarze zarządzania licencjami SAP i kontrolowania ich kosztów...."


 REKLAMA 
 Wdrażasz KSeF w firmie 
 
Cóż to jest to „korzystanie pośrednie” i w czym problem? 

In this instance, the third party systems are accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a “user” must be set up to gain access to the SAP system. On the surface then it can appear like only one user (or a small number of users) is performing actions on the SAP system. In reality though, the “user” will be performing far more tasks than is possible for a single person to undertake. (Źródło: SAP Audits – Is it impossible to gauge financial exposure? – IT Asset Knowledgebase

Generalnie chodzi o to, że integrowane ze sobą aplikacje wymieniają dane i „zlecają sobie” usługi, i tu warto wiedzieć co (dane, logika aplikacyjna) jest chronione prawami autorskimi i co stanowi know how. Problem tkwi w poprawnym zdefiniowaniu przedmiotu (obiektu) przetwarzania, przedmiotu prawa autorskiego i tego co stanowi know-how. 
 
W tekście Ochrona know-how organizacji analizowanej pisałem dość dokładnie o prawach autorskich i know-how. Tu kilka kluczowych pojęć. 
 
USTAWA z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych mówi:

Art. 1. 1. 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).

Art. 2.
1. Opracowanie cudzego utworu, w szczególności tłumaczenie, przeróbka, adaptacja, jest przedmiotem prawa autorskiego bez uszczerbku dla prawa do utworu pierwotnego.
2. Rozporządzanie i korzystanie z opracowania zależy od zezwolenia twórcy utworu pierwotnego (prawo zależne), chyba że autorskie prawa majątkowe do utworu pierwotnego wygasły. W przypadku baz danych spełniających cechy utworu zezwolenie twórcy jest konieczne także na sporządzenie opracowania.
2. (1) Ochroną objęty może być wyłącznie sposób wyrażenia; nie są objęte ochroną odkrycia, idee, procedury, metody i zasady działania oraz koncepcje matematyczne.

USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji, mówi, że:

Art. 11.
4. Przez tajemnicę przedsiębiorstwa rozumie się nieujawnione do wiadomości publicznej informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, co do których przedsiębiorca podjął niezbędne działania w celu zachowania ich poufności.

Tak więc mamy kluczowe pojęcie: utwór oraz know-how. Utworem jest unikalna treść  zaś know-how to nieujawnione i chronione (!) informacje (treści) techniczne, organizacyjne lub gospodarcze.
 
Czym jest owo „pośrednie korzystanie z systemu SAP”? Drugi tekst wyjaśnia: „accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a “user” must be set up to gain access to the SAP system„. Czyli „pobieranie i zapisywanie danych”, użytkownik by mógł „tego dokonać” musi mieć dostęp Systemu  SAP.
Jednak sam fakt istnienia dostępu i korzystania z niego, nie oznacza korzystania z cudzych  wartości intelektualnych!
 
Najpierw model takiego przypadku:
 
 Prawo autorskie Aplikacja 21
 
Użytkownik bezpośredni Systemu to „standardowy”, licencjonowany użytkownik. Aplikacja pośrednicząca także korzysta z licencjonowanego dostępu (API). Jak, i z czego (i czy), korzysta Użytkownik pośredni Systemu?
 
Żeby wskazać to, z czego korzysta zewnętrzny użytkownik (aktor) Systemu, należy „zajrzeć” do wnętrza systemu. Architektura Systemu i integracji ma taką postać:

Prawo autorskie Aplikacja 22

 

Na tym diagramie mamy trzy kluczowe elementy (tu artefakty) reprezentujące wartości intelektualne chronione prawem: Logika biznesowa, Zebrane dane i Strukturę danych. Logika biznesowa to sposób (metody) przetwarzania informacji (danych) zawarte w programie komputerowym, stanowią (mogą stanowić) know-how firmy, sam program komputerowy (jego treść) to ustalony utwór. Prawo autorskie chroni bazy danych (zebrane i uporządkowane dane) zaś struktura danych (projekt, model danych) to także utwór chroniony.
 
Zintegrowana z Systemem aplikacja korzysta z API Systemu. API standardowo pozwala np: na pobranie obiektu, wstawienie obiektu oraz wykonanie operacji z użyciem logiki biznesowej. 
 
Zasadnicze pytanie brzmi: co w Systemie stanowi produkt „działalności twórczej o indywidualnym charakterze”? Na pewno jest to oprogramowanie jako takie oraz struktura (model) danych oraz baza danych, czyli zebrane dane (z uwagi na ich unikalną strukturę, model, w bazie danych). Jednak program realizuje określoną logikę biznesową (operacje na danych) i przetwarza określone obiekty biznesowe, czyli określone zestawy danych takie jak faktura czy  dokument magazynowy WZ. Ogólnie operacje z użyciem Systemu (aplikacji) mają np. taką postać:
 
Prawo autorskie Aplikacja 23
 
Jest to przykład możliwego dialogu użytkownika (aktor) z aplikacją (System). Dialog taki, niezależnie od stopnia komplikacji, będzie się składał z operacji będących logiką biznesową (czyli specyfiką dziedziny) lub techniczną (specyfiką technologii implementacji). Przedmiotem przetwarzania będą określone obiekty biznesowe (nazwane zestawy danych), komunikat na ekranie także może być takim obiektem (jeżeli tym komunikatem jest treść dokumentu a nie tylko tekst mówiący, że coś zostało wykonane np. bez błędu).

Tu jednak mamy do czynienia z oprogramowaniem wspierającym między innymi operacje opisane w ustawach (księgowe). Niewątpliwie prawo chroni strukturę danych, dane zebrane w bazie danych oraz know-how, to które jest nieznane „innym”. Jednak prawo nie chroni idei, nie chroni też tego co „jest powszechnie znane”. Warto także wiedzieć, że wdrożenie w toku którego miała miejsce tak zwana kastomizacja, „wnosi” know-how przyszłego użytkownika do kodu, i za korzystanie z tej logiki dostawca oprogramowania nie ma prawa brać wynagrodzenia. Pod warunkiem jednak, że kod realizujący to wniesione know-how jest jawnie wydzielony! 

Nie ma jednoznacznej odpowiedzi na pytanie czy w danym przypadku ma miejsce korzystanie pośrednie z oprogramowania, niewątpliwie sam fakt integracji nie stanowi korzystania pośredniego. Nie jest tez prawdą, ze sam fakt integracji automatycznie implikuje korzystanie pośrednie wymagające opłaty licencyjnej. Kluczem do stwierdzenia tego jest wiedza o architekturze systemu, o architekturze całości integracji i o tym jakie operacje i gdzie są wykonywane. Na szczęście to dostawca Systemu musi uzasadnić swoje roszczenia dotyczące własności intelektualnej, jednak korzystający z tego Systemu – jeżeli nie potrafi podać kontrargumentów – nie jest w stanie się obronić. Niestety największym problemem jest wdrożenie polegające na kastomizacji, gdyż dochodzi do „wplecenia” nowej logiki biznesowej do już istniejącej w dostarczanym oprogramowaniu.

Skutek jest taki, że dostawca oprogramowania ma podstawy prawne do ochrony kodu jaki dostarczył, jednak kupujący nie ma żadnych podstaw (dokumenty, projekt itp.) by chronić swoje know-how i  by nie płacić za swoje własne know-how „włożone” w toku wdrożenia, do wdrażanego oprogramowania.
Dlatego warto restrykcyjnie prowadzić proces analizy i projektowania, to jest umiejętnie udokumentować projekt tak, by granica pomiędzy wartościami intelektualnymi dostawcy i nabywcy oprogramowania była jasno określona. I nie jest to rola prawnika a architekta całości systemu, który musi także znać i rozumieć prawne aspekty tej architektury. 

Źródło: www.it-consulting.pl 

 

PRZECZYTAJ RÓWNIEŻ:


Back to top