Niedawno bla­dy strach padł na użyt­kow­ni­ków opro­gra­mo­wa­nie SAP AG za spra­wą pew­ne­go pro­ce­su i wyroku: 

Po nie­daw­nym orze­cze­niu bry­tyj­skie­go Sądu Najwyższego, któ­ry potwier­dził pra­wo fir­my SAP do nali­cza­nia opłat za pośred­nie korzy­sta­nie z sys­te­mów SAP przy uży­ciu takich apli­ka­cji innych firm jak Salesforce, WorkDay i QlikView, korzy­sta­nie pośred­nie jest obec­nie wymie­nia­ne przez klien­tów fir­my SAP jako głów­na oba­wa w obsza­rze zarzą­dza­nia licen­cja­mi SAP i kon­tro­lo­wa­nia ich kosz­tów. […] W ostat­nich tygo­dniach ryzy­ko zwią­za­ne z korzy­sta­niem pośred­nim ? dotych­czas głów­nie teo­re­tycz­ne ? sta­ło się rze­czy­wi­sto­ścią, któ­ra może zmu­sić wie­le przed­się­biorstw do ponie­sie­nia milio­no­wych nie­za­bu­dże­to­wa­nych kosz­tów dodat­ko­wych licen­cji SAP. (Źródło: Korzystanie pośred­nie głów­ną oba­wą klien­tów SAP – ERP​-view​.pl

Cóż to jest to korzy­sta­nie pośred­nie” i w czym problem? 

In this instan­ce, the third par­ty sys­tems are acces­sing the SAP envi­ron­ment, pul­ling data and often wri­ting it back via a con­nec­tion to the SAP envi­ron­ment. Here a ?user? must be set up to gain access to the SAP sys­tem. On the sur­fa­ce then it can appe­ar like only one user (or a small num­ber of users) is per­for­ming actions on the SAP sys­tem. In reali­ty tho­ugh, the ?user? will be per­for­ming far more tasks than is possi­ble for a sin­gle per­son to under­ta­ke. (Źródło: SAP Audits ? Is it impos­si­ble to gau­ge finan­cial expo­su­re? – IT Asset Knowledgebase) 

Generalnie cho­dzi o to, że inte­gro­wa­ne ze sobą apli­ka­cje wymie­nia­ją dane i zle­ca­ją sobie” usłu­gi, i tu war­to wie­dzieć co (dane, logi­ka apli­ka­cyj­na) jest chro­nio­ne pra­wa­mi autor­ski­mi i co sta­no­wi know how. Problem tkwi w popraw­nym zde­fi­nio­wa­niu przed­mio­tu (obiek­tu) prze­twa­rza­nia, przed­mio­tu pra­wa autor­skie­go i tego co sta­no­wi know-how. 

W tek­ście Ochrona know-how orga­ni­za­cji ana­li­zo­wa­nej pisa­łem dość dokład­nie o pra­wach autor­skich i know-how. Tu kil­ka klu­czo­wych pojęć. 

USTAWA z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych mówi:

Art. 1. 1. Przedmiotem pra­wa autor­skie­go jest każ­dy prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci, nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (utwór).

Art. 2.
1. Opracowanie cudze­go utwo­ru, w szcze­gól­no­ści tłu­ma­cze­nie, prze­rób­ka, adap­ta­cja, jest przed­mio­tem pra­wa autor­skie­go bez uszczerb­ku dla pra­wa do utwo­ru pierwotnego.
2. Rozporządzanie i korzy­sta­nie z opra­co­wa­nia zale­ży od zezwo­le­nia twór­cy utwo­ru pier­wot­ne­go (pra­wo zależ­ne), chy­ba że autor­skie pra­wa mająt­ko­we do utwo­ru pier­wot­ne­go wyga­sły. W przy­pad­ku baz danych speł­nia­ją­cych cechy utwo­ru zezwo­le­nie twór­cy jest koniecz­ne tak­że na spo­rzą­dze­nie opracowania.
2. (1) Ochroną obję­ty może być wyłącz­nie spo­sób wyra­że­nia; nie są obję­te ochro­ną odkry­cia, idee, pro­ce­du­ry, meto­dy i zasa­dy dzia­ła­nia oraz kon­cep­cje matematyczne.

USTAWA z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji, mówi, że:

Art. 11.
4. Przez tajem­ni­cę przed­się­bior­stwa rozu­mie się nie­ujaw­nio­ne do wia­do­mo­ści publicz­nej infor­ma­cje tech­nicz­ne, tech­no­lo­gicz­ne, orga­ni­za­cyj­ne przed­się­bior­stwa lub inne infor­ma­cje posia­da­ją­ce war­tość gospo­dar­czą, co do któ­rych przed­się­bior­ca pod­jął nie­zbęd­ne dzia­ła­nia w celu zacho­wa­nia ich poufności.

Tak więc mamy klu­czo­we poję­cie: utwór oraz know-how. Utworem jest uni­kal­na treść zaś know-how to nie­ujaw­nio­ne i chro­nio­ne (!) infor­ma­cje (tre­ści) tech­nicz­ne, orga­ni­za­cyj­ne lub gospodarcze.

Czym jest owo pośred­nie korzy­sta­nie z sys­te­mu SAP”? Drugi tekst wyja­śnia: acces­sing the SAP envi­ron­ment, pul­ling data and often wri­ting it back via a con­nec­tion to the SAP envi­ron­ment. Here a ?user? must be set up to gain access to the SAP sys­tem”. Czyli pobie­ra­nie i zapi­sy­wa­nie danych”, użyt­kow­nik by mógł tego doko­nać” musi mieć dostęp Systemu SAP.

Jednak sam fakt ist­nie­nia dostę­pu i korzy­sta­nia z nie­go, nie ozna­cza korzy­sta­nia z cudzych war­to­ści intelektualnych!

Najpierw model takie­go przypadku:

Użytkownik bez­po­śred­ni Systemu to stan­dar­do­wy”, licen­cjo­no­wa­ny użyt­kow­nik. Aplikacja pośred­ni­czą­ca tak­że korzy­sta z licen­cjo­no­wa­ne­go dostę­pu (API). Jak, i z cze­go (i czy), korzy­sta Użytkownik pośred­ni Systemu?

Żeby wska­zać to, z cze­go korzy­sta zewnętrz­ny użyt­kow­nik (aktor) Systemu, nale­ży zaj­rzeć” do wnę­trza sys­te­mu. Architektura Systemu i inte­gra­cji ma taką postać:

Na tym dia­gra­mie mamy trzy klu­czo­we ele­men­ty (tu arte­fak­ty) repre­zen­tu­ją­ce war­to­ści inte­lek­tu­al­ne chro­nio­ne pra­wem: Logika biz­ne­so­wa, Zebrane dane i Strukturę danych. Logika biz­ne­so­wa to spo­sób (meto­dy) prze­twa­rza­nia infor­ma­cji (danych) zawar­te w pro­gra­mie kom­pu­te­ro­wym, sta­no­wią (mogą sta­no­wić) know-how fir­my, sam pro­gram kom­pu­te­ro­wy (jego treść) to usta­lo­ny utwór. Prawo autor­skie chro­ni bazy danych (zebra­ne i upo­rząd­ko­wa­ne dane) zaś struk­tu­ra danych (pro­jekt, model danych) to tak­że utwór chroniony.

Zintegrowana z Systemem apli­ka­cja korzy­sta z API Systemu. API stan­dar­do­wo pozwa­la np: na pobra­nie obiek­tu, wsta­wie­nie obiek­tu oraz wyko­na­nie ope­ra­cji z uży­ciem logi­ki biznesowej. 

Zasadnicze pyta­nie brzmi: co w Systemie sta­no­wi pro­dukt dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze”? Na pew­no jest to opro­gra­mo­wa­nie jako takie oraz struk­tu­ra (model) danych oraz baza danych, czy­li zebra­ne dane (z uwa­gi na ich uni­kal­ną struk­tu­rę, model, w bazie danych). Jednak pro­gram reali­zu­je okre­ślo­ną logi­kę biz­ne­so­wą (ope­ra­cje na danych) i prze­twa­rza okre­ślo­ne obiek­ty biz­ne­so­we, czy­li okre­ślo­ne zesta­wy danych takie jak fak­tu­ra czy doku­ment maga­zy­no­wy WZ. Ogólnie ope­ra­cje z uży­ciem Systemu (apli­ka­cji) mają np. taką postać:

Jest to przy­kład moż­li­we­go dia­lo­gu użyt­kow­ni­ka (aktor) z apli­ka­cją (System). Dialog taki, nie­za­leż­nie od stop­nia kom­pli­ka­cji, będzie się skła­dał z ope­ra­cji będą­cych logi­ką biz­ne­so­wą (czy­li spe­cy­fi­ką dzie­dzi­ny) lub tech­nicz­ną (spe­cy­fi­ką tech­no­lo­gii imple­men­ta­cji). Przedmiotem prze­twa­rza­nia będą okre­ślo­ne obiek­ty biz­ne­so­we (nazwa­ne zesta­wy danych), komu­ni­kat na ekra­nie tak­że może być takim obiek­tem (jeże­li tym komu­ni­ka­tem jest treść doku­men­tu a nie tyl­ko tekst mówią­cy, że coś zosta­ło wyko­na­ne np. bez błędu).

Tu jed­nak mamy do czy­nie­nia z opro­gra­mo­wa­niem wspie­ra­ją­cym mię­dzy inny­mi ope­ra­cje opi­sa­ne w usta­wach (księ­go­we). Niewątpliwie pra­wo chro­ni struk­tu­rę danych, dane zebra­ne w bazie danych oraz know-how, to któ­re jest nie­zna­ne innym”. Jednak pra­wo nie chro­ni idei, nie chro­ni też tego co jest powszech­nie zna­ne”. Warto tak­że wie­dzieć, że wdro­że­nie w toku któ­re­go mia­ła miej­sce tak zwa­na kasto­mi­za­cja, wno­si” know-how przy­szłe­go użyt­kow­ni­ka do kodu, i za korzy­sta­nie z tej logi­ki dostaw­ca opro­gra­mo­wa­nia nie ma pra­wa brać wyna­gro­dze­nia. Pod warun­kiem jed­nak, że kod reali­zu­ją­cy to wnie­sio­ne know-how jest jaw­nie wydzielony! 

Nie ma jed­no­znacz­nej odpo­wie­dzi na pyta­nie czy w danym przy­pad­ku ma miej­sce korzy­sta­nie pośred­nie z opro­gra­mo­wa­nia, nie­wąt­pli­wie sam fakt inte­gra­cji nie sta­no­wi korzy­sta­nia pośred­nie­go. Nie jest tez praw­dą, ze sam fakt inte­gra­cji auto­ma­tycz­nie impli­ku­je korzy­sta­nie pośred­nie wyma­ga­ją­ce opła­ty licen­cyj­nej. Kluczem do stwier­dze­nia tego jest wie­dza o archi­tek­tu­rze sys­te­mu, o archi­tek­tu­rze cało­ści inte­gra­cji i o tym jakie ope­ra­cje i gdzie są wyko­ny­wa­ne. Na szczę­ście to dostaw­ca Systemu musi uza­sad­nić swo­je rosz­cze­nia doty­czą­ce wła­sno­ści inte­lek­tu­al­nej, jed­nak korzy­sta­ją­cy z tego Systemu – jeże­li nie potra­fi podać kontr­ar­gu­men­tów – nie jest w sta­nie się obro­nić. Niestety naj­więk­szym pro­ble­mem jest wdro­że­nie pole­ga­ją­ce na kasto­mi­za­cji, gdyż docho­dzi do wple­ce­nia” nowej logi­ki biz­ne­so­wej do już ist­nie­ją­cej w dostar­cza­nym oprogramowaniu.

Skutek jest taki, że dostaw­ca opro­gra­mo­wa­nia ma pod­sta­wy praw­ne do ochro­ny kodu jaki dostar­czył, jed­nak kupu­ją­cy nie ma żad­nych pod­staw (doku­men­ty, pro­jekt itp.) by chro­nić swo­je know-how i by nie pła­cić za swo­je wła­sne know-how wło­żo­ne” w toku wdro­że­nia, do wdra­ża­ne­go oprogramowania. 

Dlatego war­to restryk­cyj­nie pro­wa­dzić pro­ces ana­li­zy i pro­jek­to­wa­nia, to jest umie­jęt­nie udo­ku­men­to­wać pro­jekt tak, by gra­ni­ca pomię­dzy war­to­ścia­mi inte­lek­tu­al­ny­mi dostaw­cy i nabyw­cy opro­gra­mo­wa­nia była jasno okre­ślo­na. I nie jest to rola praw­ni­ka a archi­tek­ta cało­ści sys­te­mu, któ­ry musi tak­że znać i rozu­mieć praw­ne aspek­ty tej architektury. 

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 2 komentarzy

    1. Jaroslaw Zelinski

      Obawiam się, że do cza­su… gdy dowia­du­jesz się czyj napraw­dę jest…

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.