Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Tym razem o czymś co potra­fi zabić 😉 czy­li czym jest doku­ment oraz fakt i obiekt. Czym się róż­ni zakup kil­ku pro­duk­tów, w tym samym skle­pie, w np. godzin­nych odstę­pach cza­su, od zaku­pu wszyst­kich razem? Poza for­mą udo­ku­men­to­wa­nia, niczym: w skle­pie to samo i tyle samo zeszło ze sta­nu maga­zy­nu, a my wyda­li­śmy w obu przy­pad­kach tyle samo pie­nię­dzy (o pro­mo­cjach póź­niej)! W pierw­szym przy­pad­ku mamy kil­ka fak­tów zaku­pu, w dru­gim, jeden, ale zawsze tyle samo obiek­tów (pro­dukt). Faktura (para­gon) to doku­ment opi­sją­cy fakt, przed­miot sprze­da­ży jest obiek­tem. Tu obiek­tem jest opi­sy­wa­ny przed­miot zaku­pu. Ten arty­kuł to przy­kład archi­tek­tu­ry usłu­gi apli­ka­cji, któ­ra jest nie­czu­ła na takie różnice. 

Wprowadzenie

Żeby upo­rząd­ko­wać treść, w sto­sun­ku to archi­tek­tu­ry apli­ka­cji tu nie będę uży­wał pojęć kla­sa i obiekt” a kom­po­nent i doku­ment. Pojęcia obiekt i fakt tu będą doty­czy­ły świa­ta real­ne­go, to odpo­wied­nio: opi­sy­wa­ny przed­miot i zda­rze­nie z nim powią­za­ne. Innymi sło­wy: doku­ment może opi­sy­wać obiekt lub zda­rze­nie z nim powią­za­ne. Np. pro­dukt oraz fakt jego sprze­da­nia (dwa byty: sepa­ro­wa­nie kon­tek­stu doku­men­tów). Konkretne opro­gra­mo­wa­nie jako sys­tem, to kom­po­nen­ty (w UML obiek­ty okre­ślo­nej kla­sy) oraz dane zor­ga­ni­zo­wa­ne np. jako doku­men­ty (doku­ment: nazwa­na, okre­ślo­na struk­tu­ra danych). Aplikacje prze­twa­rza­ją dane opi­su­ją­ce real­ny świat, co ład­nie poka­zał i opi­sał Smith :

computer model real world
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Projektowanie opro­gra­mo­wa­nia to two­rze­nie jego mode­lu, potem pozo­sta­je już tyl­ko jego imple­men­ta­cja. Obecnie pra­ce pro­jek­to­we i przy­go­to­wa­nie do imple­men­ta­cji tak­że są zali­cza­ne do pro­gra­mo­wa­nia” .

Projekt systemu sprzedaży

Każda ana­li­za powin­na być opar­ta na onto­lo­gii z dzie­dzi­ny pro­ble­mu. Dzięki cze­mu nazwy doku­men­tów, atry­bu­tów i ich war­to­ści będą spój­ne, jed­no­znacz­ne i nie­sprzecz­ne. Poniżej pro­sty model poję­cio­wy dla dzie­dzi­ny opi­sy­wa­ne­go tu problemu:

Model poję­cio­wy (dia­gram fak­tów SBVR lub model poję­cio­wy, dia­gram klas UML)

(UWAGA! Powyższy model nie jest żad­nym mode­lem dzie­dzi­ny” ani mode­lem danych”. To model pojęciowy). 

Modele poję­cio­we słu­żą do zarzą­dza­nia sys­te­mem pojęć (onto­lo­gia) dla dane­go mode­lu opro­gra­mo­wa­nia. Testowanie tego mode­lu pole­ga na spraw­dze­niu czy każ­da para połą­czo­nych seman­tycz­nie pojęć two­rzy popraw­ne i praw­dzi­we(!) zda­nie w języ­ku natu­ral­nym (tu musi­my brać popraw­kę na flek­sję języ­ka pol­skie­go), np. «sprze­da­ją­cy wysta­wia fak­tu­rę» (fakt) lub «fak­tu­ra jest doku­men­tem» (typ).

Oprogramowanie słu­ży do prze­twa­rza­nia danych, dla­te­go war­to opi­sać jak się to odby­wa. Bardzo wygod­ną meto­dą pro­jek­to­wa­nia struk­tur danych doku­men­ty (w tym opi­sie dia­gram struk­tur zło­żo­nych nota­cji UML). Po pierw­sze są one zro­zu­mia­łe dla przy­szłe­go użyt­kow­ni­ka, po dru­gie meto­da ta pozwa­la uwol­nić się od wad mode­li rela­cyj­nych: usu­nię­cie redun­dan­cji nazw co pro­wa­dzi do utra­ty ich kon­tek­stu. Dokumenty czę­sto mają róż­ny kon­tekst, zna­cze­nie pojęć zale­ży od kon­tek­stu. Relacyjny model danych, pozba­wio­ny redun­dan­cji, jest strat­ny: utrwa­lo­ne dane nie sta­no­wią żad­nej infor­ma­cji a doku­men­tem jest dopie­ro wynik zapy­ta­nia SQL do tabel. 

W przy­pad­ku opi­sy­wa­ne­go tu pro­jek­tu wyglą­da to tak:

Struktury danych zor­ga­ni­zo­wa­nych w doku­men­ty (nota­cja UML)

Mamy tu dwa doku­men­ty: Oferta i Faktura. Pojęcie Produkt ma swo­ją defi­ni­cję real­na (defi­ni­cja atry­bu­to­wa: poprzez cechy): jest to cos co ma nazwę, cenę i ilość”. Atrybuty Produktu na doku­men­tach przyj­mu­ją war­to­ści opi­sa­ne tym typem. Po dru­gie doku­ment nie­sie kon­tekst więc nada­je nazwie zna­cze­nie: np. data to data fak­tu­ry i data ofer­ty. To nie są te same daty, a pro­dukt ofe­ro­wa­ny (jako atry­but ofer­ty) nie musi być tym samym pro­duk­tem sprze­da­nym (jako atry­but Faktury).

Projekt powyż­szy poka­zu­je tak­że waż­ną rzecz: sepa­ro­wa­nie danych o obiek­tach (pro­duk­ty) i fak­tach (fak­tu­ra). Nie nale­ży na jed­nym doku­men­cie łączyć (mie­szać) kon­tek­stów (uwspól­nia­nie danych w mode­lu rela­cyj­nym). (Więcej na temat sepa­ra­cji kon­tek­stów obiek­tu i fak­tu w publi­ka­cji Chapter 3 Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases”).

Poniżej, na dia­gra­mie sekwen­cji, widać, że dla kom­po­nen­tu zarzą­dza­ją­ce­go sta­na­mi maga­zy­no­wy­mi nie ma żad­ne­go zna­cze­nia ile jest (było) fak­tur, ope­ra­cje zmia­ny ilo­ści to poje­dyn­cze ope­ra­cje. Tak zapro­jek­to­wa­na apli­ka­cja jest odpor­na na to ile pro­duk­tów jest na ofer­cie i fak­tu­rze, mogą to być róż­ne ilo­ści. Oba te doku­men­ty: ofer­ta i fak­tu­ra, to cał­ko­wi­cie odręb­ne kon­struk­cje, to doku­men­ty rzą­dzą­ce się każ­dy inną logi­ką i mają­ce każ­dy inny cykl życia (tu np. Oferta nie jest utrwa­la­na). Często sto­so­wa­ne kon­struk­cje, takie jak dzie­dzi­cze­nie fak­tu­ry i ofer­ty po doku­men­cie” są tu naj­gor­szym pomysłem. 

Architektura. Nasza apli­ka­cja to kil­ka współ­pra­cu­ją­cych komponentów:

Obiektowy (kom­po­nen­to­wy) model dziedziny. 

Klasy ozna­czo­ne ste­reo­ty­pem «Document» to cią­gi zna­ków (np. XML) sta­no­wią­ce war­to­ści atry­bu­tów i para­me­try wywo­łań ope­ra­cji. (w UML: ?Document? A human-reada­ble file. Subclass of ?File?. )

Model archi­tek­tu­ry to sta­tycz­ny model, a ten może być nie­zro­zu­mia­ły, dla­te­go zawsze wzbo­ga­ca­my pro­jekt tech­nicz­ny archi­tek­tu­ry mode­lem dyna­mi­ki sys­te­mu: dia­gra­mem sekwen­cji. Diagram taki powi­nien powstać dla każ­dej usłu­gi apli­ka­cji (przy­pad­ku użycia):

Scenariusz reali­za­cji sprze­da­ży (dia­gram sekwen­cji UML)

Powyższy dia­gram poka­zu­je współ­pra­cę kom­po­nen­tów, opi­sa­ne wcze­śniej doku­men­ty są war­to­ścia­mi atry­bu­tów i para­me­tra­mi wywo­ły­wa­nych ope­ra­cji i ich odpo­wie­dzi. Powyższa archi­tek­tu­ra z powo­dze­niem wyko­na tak­że usłu­gi wglą­du do histo­rycz­nych fak­tur czy aktu­ali­za­cję cennika. 

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! 

Samo opra­co­wa­nie rela­cyj­ne­go mode­lu danych oraz zapy­tań SQL, by gene­ro­wać powyż­sze doku­men­ty z warian­ta­mi doty­czą­cy­mi róż­nych ilo­ści ofe­ro­wa­nych i zama­wia­nych, zaj­mie kil­ka­krot­nie wię­cej cza­su niż opra­co­wa­nie powyż­sze­go, goto­we­go do imple­men­ta­cji, pro­jek­tu. Opracowanie mode­lu rela­cyj­ne­go bazy danych, wyma­ga­ło by dodat­ko­wo wie­dzy o wszyst­kich pozo­sta­łych doku­men­tach w tym sys­te­mie, a tego z regu­ły nigdy nie wie­my na początku!

Powyższy model to w peł­ni współ­pra­cu­ją­ce obiek­ty mają­ce ope­ra­cje, a pod­sta­wo­wym związ­kiem mode­lu obiek­to­we­go jest zwią­zek uży­cia (wywo­ła­nia ope­ra­cji), czy­li nie jest to tak zwa­ny ane­micz­ny model dzie­dzi­ny.

Tu tak­że war­to zwró­cić uwa­gę na kolej­ny czę­sty błąd i antyw­zo­rzec w pro­jek­tach dekla­ro­wa­nych jako obiek­to­we: sto­so­wa­nie dzie­dzi­cze­nia. Jest to mie­sza­nie mode­li poję­cio­wych i archi­tek­tu­ry (dzie­dzi­cze­nie, jako współ­dzie­le­nie, łamie pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest her­me­ty­za­cja). Dlatego model poję­cio­wy i model archi­tek­tu­ry to z zasa­dy dwa odręb­ne mode­le z powo­dów jak wyżej opisane.

Modelowanie archi­tek­tu­ry systemu 

Podsumowanie

Powyższy opis to krót­ki ale prak­tycz­nie kom­plet­ny Opis Techniczny Oprogramowania. Wymaga nie­wiel­kich uzu­peł­nień (ewen­tu­al­ne sche­ma­ty opi­su­ją­ce meto­dy ope­ra­cji). Wykonanie imple­men­ta­cji na jego pod­sta­wie nie powin­no spra­wić pro­ble­mu oso­bie radzą­cej sobie z czy­ta­niem nota­cji UML. Projekt jest na tyle pre­cy­zyj­ny, że sta­no­wi utwór w rozu­mie­niu pra­wa autor­skie­go (pro­gra­mi­sta nie ma tu żad­nej swo­bo­dy decy­zji w pisa­niu kodu dla tej czę­ści). Projekt taki to tak­że opis okre­ślo­ne­go mecha­ni­zmu dzia­ła­nia, zawie­ra więc opis know-how i jako jego udo­ku­men­to­wa­na for­ma chro­ni to know-how (usta­wa o prze­ciw­dzia­ła­niu nie­uczci­wej konkurencji). 

Dlatego każ­dy pro­gram kom­pu­te­ro­wy napi­sa­ny na pod­sta­wie takiej doku­men­ta­cji, z zasa­dy jest utwo­rem zależ­nym. Developer ma pra­wa autor­skie oso­bi­ste do kodu jaki napi­sze, ale nie ma pra­wa do dys­po­no­wa­nia tym kodem: ma je posia­dacz praw mająt­ko­wych do pro­jek­tu, któ­ry jest tu utwo­rem pier­wot­nym. Jedyny wybór jaki ma tu deve­lo­per to wybór tech­no­lo­gii jakiej użyje.

https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​e​m​e​r​g​i​n​g​-​c​h​a​l​l​e​n​g​e​s​-​s​o​l​u​t​i​o​n​s​-​b​e​s​t​-​p​r​a​c​t​i​c​e​s​/​2​7​1​7​3​3​#​t​a​b​l​e​-​o​f​-​c​o​n​t​e​nts

Powyższy pro­jekt wyko­na­no z uży­ciem Visual Paradigm.

Źródła

OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Weilkiens, T. (2007). Systems engi­ne­ering with SysML/UML: mode­ling, ana­ly­sis, design (1. Aufl). Morgan Kaufmann OMG Press/Elsevier.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

Projekt aplikacji – przykład

Wstęp

Napisałem o orien­ta­cji na doku­men­ty w toku analiz:

Często jestem i ja pyta­ny o to ??Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?? Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. (Wymagania na for­mu­la­rze czy­li dia­gra­my struk­tur zło­żo­nych i XML)

Dzisiaj pój­dzie­my dalej, omó­wi­my to gdzie i jak zacho­wać tę infor­ma­cję. Posłużę się pro­stym przy­kła­dem przy­chod­ni wete­ry­na­ryj­nej. Artykuł będzie opi­sem meto­dy podej­ścia do ana­li­zy zorien­to­wa­nej na pro­ce­sy i dokumenty. 

Tekst ma dwie czę­ści: pierw­sza jest opi­sem dro­gi jaka pro­wa­dzi nas do zde­fi­nio­wa­nia tego jakie doku­men­ty, jaką mają (mieć) zawar­tość i struk­tu­rę. Praktycznie jest to opis ana­li­zy i pro­jek­to­wa­nia. Druga – krót­ka – to przy­kła­do­wa archi­tek­tu­ra logi­ki reali­za­cji apli­ka­cji, poka­zu­ją­ca miej­sce doku­men­to­wej bazy danych w archi­tek­tu­rze i pro­jek­cie, czy­li tak­że projektowanie. 

Celem tego wpi­su jest poka­za­nie czym może być ana­li­za oraz jej pro­dukt jakim jest Techniczny Projekt Oprogramowania.

Czytaj dalej… Projekt apli­ka­cji – przy­kład”
złodziej

Czy podpisywanie umów o poufności ma jeszcze sens?

Wstęp

Podstawowym narzę­dziem ochro­ny infor­ma­cji jest jej sto­sow­ne ozna­cze­nie, bez cze­go wg. pra­wa nie pod­le­ga ona ochro­nie. Zawarcie umo­wy na ochro­nę infor­ma­cji jest nie­sku­tecz­ne, gdy odróż­nie­nie infor­ma­cji chro­nio­nej od nie­chro­nio­nej jest nie­moż­li­we, zaś sto­sow­ne ozna­cze­nie infor­ma­cji samo z sie­bie stwa­rza obo­wią­zek praw­ny jej ochro­ny.?1?

Temat nie­uczci­wej kon­ku­ren­cji poja­wia się prak­tycz­nie w każ­dym pro­jek­cie zwią­za­nym z jaką­kol­wiek reor­ga­ni­za­cją przed­się­bior­stwa. Właśnie weszła w życie nowe­li­za­cja ustawy:

We wto­rek, tj. 04.09.2018 r. w życie weszła nowe­li­za­cja usta­wy z dnia 16.04.1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji (dalej jako: ?UZNK?). Zmiany doty­czą głów­nie kwe­stii defi­ni­cyj­nych, zwią­za­nych z rozu­mie­niem czym jest ?tajem­ni­ca przed­się­bior­stwa? i wyni­ka­ją z obo­wiąz­ku imple­men­ta­cji dyrek­ty­wy Parlamentu Europejskiego i Rady (UE) 2016/943 z dnia 08.06.2016 r. w spra­wie ochro­ny nie­jaw­ne­go know ? how i nie­jaw­nych infor­ma­cji han­dlo­wych (tajem­nic przed­się­bior­stwa) przed ich bez­praw­nym pozy­ska­niem, wyko­rzy­sta­niem i ujaw­nia­niem (dalej jako: ?Dyrektywa o pouf­no­ści?, jej głów­ne zało­że­nia przed­sta­wia­li­śmy tutaj).?2?

(peł­na treść usta­wy?3?).

O poufności regulowanej ustawą

Emocje budzą zawsze dwie klu­czo­we spra­wy: co moż­na chro­nić i jak to sku­tecz­nie moż­na chro­nić. Do tego docho­dzi for­so­wa­nie przez kor­po­ra­cyj­nych praw­ni­ków pod­pi­sy­wa­nie umów o zacho­wa­niu poufności.

W kwe­stii umów o pouf­no­ści nadal sto­ję na sta­no­wi­sku, że ich pod­pi­sy­wa­nie to tak zwa­na ostroż­ność pro­ce­so­wa praw­ni­ków czy­li nie­uczci­we a prio­ri zrzu­ca­nie winy z sie­bie i prze­ro­sze­nie wszel­kich ryzyk ujaw­nie­nia infor­ma­cji na part­ne­rów. Dlaczego? Przede wszyst­kim Art.11. par.2. mówi:

2. Przez tajem­ni­cę przed­się­bior­stwa rozu­mie się 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ą, któ­re jako całość lub w szcze­gól­nym zesta­wie­niu i zbio­rze ich ele­men­tów nie są powszech­nie zna­ne oso­bom zwy­kle zaj­mu­ją­cym się tym rodza­jem infor­ma­cji albo nie są łatwo dostęp­ne dla takich osób, o ile upraw­nio­ny do korzy­sta­nia z infor­ma­cji lub roz­po­rzą­dza­nia nimi pod­jął, przy zacho­wa­niu nale­ży­tej sta­ran­no­ści, dzia­ła­nia w celu utrzy­ma­nia ich w pouf­no­ści.

Wytłuszczona część to klu­czo­wa, w moich oczach, przy­czy­na ser­wo­wa­nia umów o pouf­no­ści. Znakomita część zna­nych mi orga­ni­za­cji, nie podej­mu­je prak­tycz­nie żad­nych kro­ków opi­sa­nych w tym para­gra­fie. Wysyłanie infor­ma­cji sta­no­wią­cej tajem­ni­cę przed­się­bior­stwa bez ozna­cze­nia, że to infor­ma­cja chro­nio­na, oraz czy­nie­nie tego z pomo­cą środ­ków komu­ni­ka­cji elek­tro­nicz­nej takich jak ema­il, świad­czy tyl­ko o tym, że poli­ty­ki ochro­ny nie ma żad­nej. Forsowanie więc przez fir­my pod­pi­sy­wa­nia umo­wy o zacho­wa­niu infor­ma­cji w pouf­no­ści, zawie­ra­ją­cej zapi­sy o domnie­ma­niu winy part­ne­ra za wyciek takich infor­ma­cji i wyso­kich karach za to, jest kurio­zal­ne i po pro­stu nieuczciwe.

Powyższa defi­ni­cja po nowe­li­za­cji, zosta­ła doprecyzowana:

Wprowadzone zmia­ny mają ogrom­ne zna­cze­nie dla prak­ty­ki. Nowa defi­ni­cja w więk­szej mie­rze chro­ni bowiem te oso­by, któ­re na co dzień mają do czy­nie­nia z infor­ma­cja­mi poten­cjal­nie mogą­cy­mi sta­no­wić tajem­ni­cę przed­się­bior­stwa (np. spo­sób wytwa­rza­nia jakie­goś pro­duk­tu), jed­nak wie­dza ta może być przez nich z łatwo­ścią ?odko­do­wa­na? na pod­sta­wie ogól­no­do­stęp­nych danych, przy wyko­rzy­sta­niu posia­da­nej wie­dzy i doświad­cze­nia. Zawężenie zatem przez usta­wo­daw­cę zakre­su infor­ma­cji z ?nie­ujaw­nio­nej do wia­do­mo­ści publicz­nej? do infor­ma­cji ?nie­zna­nej powszech­nie oso­bie trud­nią­cej się daną dzie­dzi­ną nauki?, nale­ży uznać za roz­wią­za­nie korzyst­ne i pożą­da­ne.?2?

Taki zapis tym bar­dziej pro­wa­dzi do wnio­sku, że pod­pi­sy­wa­nie umów o pouf­no­ści jest w wie­lu przy­pad­ków szko­dli­we dla stro­ny, na któ­rą prze­no­si się w tej umo­wie odpo­wie­dzial­ność za skut­ki ujaw­nie­nia. Dlaczego? Bo:

Nadal szcze­gól­nie istot­ny będzie spo­czy­wa­ją­cy na przed­się­bior­cy obo­wią­zek usta­le­nia kon­kret­ne­go kata­lo­gu infor­ma­cji, któ­re mają być chro­nio­ne oraz zazna­jo­mie­nia współ­pra­cow­ni­ków z tym kata­lo­giem (co ozna­cza, że współ­pra­cow­nik nie może decy­do­wać sam co jest tajem­ni­cą przed­się­bior­stwa, a co nie).?2?

Powszechnie przy­ję­tą for­mą usta­la­nia tego, któ­ra infor­ma­cja jest chro­nio­na, jest jej ozna­cza­nie. Innymi sło­wy: albo chro­nio­na infor­ma­cja sta­no­wi sobą utrwa­lo­ną i sto­sow­nie ozna­czo­ną treść w posta­ci doku­men­tu, albo nie jest chro­nio­na i jej ujaw­nie­nie nie jest prze­stęp­stwem.

Dalej. Skoro 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ą, któ­re jako całość lub w szcze­gól­nym zesta­wie­niu i zbio­rze ich ele­men­tów nie są powszech­nie zna­ne oso­bom zwy­kle zaj­mu­ją­cym się tym rodza­jem infor­ma­cji albo nie są łatwo dostęp­ne dla takich osób” mają być chro­nio­ne, to przede wszyst­kim muszą być naj­pierw utrwa­lo­ne (i ewen­tu­al­nie ska­ta­lo­go­wa­ne), bez tego nie da się ich ozna­czyć i chronić.

Sądy bar­dzo poważ­nie pod­cho­dzą do wymo­gu łącz­ne­go speł­nia­nia wszyst­kich usta­wo­wych prze­sła­nek uzna­nia infor­ma­cji za tajem­ni­cę przed­się­bior­stwa. Jeżeli oka­że się, że jed­na z tych prze­sła­nek nie zosta­nie speł­nio­na, infor­ma­cja nie sta­no­wi tajem­ni­cy przed­się­bior­stwa i każ­dy może z niej korzy­stać bez ogra­ni­czeń. ?1?

Kolejna rzecz to:

…doty­czy pod­mio­tu, któ­ry powi­nien kie­ro­wać się nale­ży­tą sta­ran­no­ścią w celu zacho­wa­nia infor­ma­cji sta­no­wią­cych tajem­ni­cę przed­się­bior­stwa w pouf­no­ści. Nie jest to już tyl­ko sze­ro­ko rozu­mia­ny ?przed­się­bior­ca? (przede wszyst­kim wła­ści­ciel infor­ma­cji). Są to tak­że oso­by, któ­re infor­ma­cja­mi roz­po­rzą­dza­ją i z nich korzy­sta­ją. Dookreślenie kata­lo­gu pozwo­li sze­rzej chro­nić infor­ma­cje sta­no­wią­ce tajem­ni­cę przed­się­bior­stwa tak­że przez oso­by, któ­re w trak­cie świad­czo­nych usług posłu­gu­ją się nimi.?2?

Oznacza to, kwe­stie ochro­ny infor­ma­cji doty­czą z zasa­dy wszyst­kich zaan­ga­żo­wa­nych w pra­cę, człon­ków pro­jek­tów IT (i nie tyl­ko IT). Sam fakt ich poin­for­mo­wa­nia o tym wystar­czy, a wystar­cza­ją­ce jest umiesz­cze­nie takiej infor­ma­cji, na wymie­nia­nych doku­men­tach. Co cie­ka­we, defi­ni­cja usta­wo­wa czy­ni nie­sku­tecz­ny­mi, zapi­sy o ochro­nie tego co tu napi­sa­no” w stop­kach mali, gdyż więk­szość z nich i tak zawie­ra infor­ma­cje powszech­nie zna­ne a sam ema­il jako medium, nie jest bez­piecz­nym środ­kiem komunikacji.

Kolejna waż­na zmiana:

Z defi­ni­cji czy­nu nie­uczci­wej kon­ku­ren­cji zawar­te­go w art. 11 ust. 1 UZNK usu­nię­to czyn­ność ?prze­ka­za­nia? infor­ma­cji sta­no­wią­cych tajem­ni­cy przed­się­bior­stwa, sank­cjo­nu­jąc nato­miast ich ?pozy­ska­nie?. W ten spo­sób roz­sze­rzo­no odpo­wie­dzial­ność rów­nież na te pod­mio­ty, któ­re w spo­sób bez­praw­ny sta­ły się posia­da­cza­mi tajem­ni­cy przedsiębiorstwa.

To koń­czy bez­kar­ność” osób, któ­re tyl­ko otrzy­ma­ły” (nawet w wyni­ku prze­stęp­stwa) infor­ma­cje chro­nio­ne, o ile jed­nak zosta­ły one sto­sow­nie ozna­czo­ne. Przestępstwem jest obra­ca­nie infor­ma­cją o któ­rej wie­my, że jest chroniona.

Biorąc pod uwa­gę wcze­śniej­sze, dość lako­nicz­ne prze­pi­sy UZNK odno­szą­ce się do ochro­ny tajem­ni­cy przed­się­bior­stwa i rosz­czeń jakie przy­słu­gu­ją za ich naru­sze­nie, moż­na odnieść wra­że­nie, że imple­men­ta­cja Dyrektywy moc­no skom­pli­ko­wa­ła tę kwe­stię. Wydaje się , że szer­sze regu­la­cje pozwa­la­ją na uszcze­gó­ło­wie­nie zakre­su odpo­wie­dzial­no­ści oraz pena­li­za­cję tyl­ko tych zacho­wań, któ­re rze­czy­wi­ście mogą nega­tyw­nie wpły­nąć na pra­wi­dło­we dzia­ła­nie kon­ku­ren­cji na ryn­ku. Czas poka­że jak nowe prze­pi­sy będą sto­so­wa­ne w prak­ty­ce.?2?

O dokumentowaniu know-how

Jak już wspo­mnia­no, sku­tecz­nej ochro­nie pod­le­ga wyłącz­nie to co udo­ku­men­to­wa­no. Owszem, toczą się nie­koń­czą­ce dys­ku­sje na temat ochro­ny infor­ma­cji prze­ka­za­nych ust­nie, jed­nak nie­ste­ty nie sta­no­wią one mate­ria­ły dowo­do­we­go w przy­pad­ku spo­ru, a dowo­dy z prze­słu­cha­nia mają tu tę wadę, że świa­dek stro­ny pozwa­nej musiał by zezna­wać prze­ciw­ko sobie, cze­go zapew­ne nie zro­bi. To dla­te­go w innym arty­ku­le napi­sa­łem, że:

Twoje tajem­ni­ce są chro­nio­ne tyl­ko wte­dy gdy możesz je zamknąć w sej­fie. A więc albo je udo­ku­men­tu­jesz i scho­wasz albo nie są Twoje??czyli? jeże­li w umo­wie z dostaw­cą opro­gra­mo­wa­nia masz zapi­sy mówią­ce, że wszel­kie war­to­ści inte­lek­tu­al­ne powsta­łe w toku pro­jek­tu są wła­sno­ścią dostaw­cy opro­gra­mo­wa­nia to masz poważ­ny pro­blem ??4?

Niestety powszech­ną prak­ty­ką na ryn­ku opro­gra­mo­wa­nia są ust­ne wywia­dy i roz­mo­wy tak zwa­nych ana­li­ty­ków, ci są w więk­szo­ści jedy­nie sekre­ta­rza­mi, spi­su­ją­cy­mi pozy­ska­ne infor­ma­cje, a te są doku­men­ta­mi dostaw­cy opro­gra­mo­wa­nia (pra­wa oso­bi­ste i mająt­ko­we ma fir­ma ana­li­zu­ją­ca) i naj­czę­ściej żaden tego typu doku­ment nie zawie­ra infor­ma­cji, że to infor­ma­cje chro­nio­ne pod­mio­tu ana­li­zo­wa­ne­go. W efek­cie know-how ana­li­zo­wa­nej fir­my gład­ko” prze­cho­dzi na wła­sność dostaw­cy opro­gra­mo­wa­nia (lub usług wdra­ża­nia norm jako­ści itp.). Co cie­ka­we, ana­li­zo­wa­ne fir­my z regu­ły nie mają świa­do­mo­ści tego fak­tu do cza­su gdy nie odkry­ją , że ich kon­ku­rent nabył opro­gra­mo­wa­nie zawie­ra­ją­ce ich know-how. Bardzo czę­sto fir­my chwa­lą, że ofe­ru­ją bran­żo­we mode­le refe­ren­cyj­ne” a te są nie raz po pro­stu cudzym know-how zdo­by­tym w toku wcze­śniej­szych projektów.

Celem i przed­mio­tem umo­wy z ana­li­ty­kiem z regu­ły jest opra­co­wa­nie roz­wią­za­nia lub pro­jek­tu pro­duk­tu, któ­re­go opis i spo­sób wyko­rzy­sta­nia sta­no­wi okre­ślo­ne roz­wią­za­nie. Wymaga to pra­wie zawsze uprzed­nie­go zro­zu­mie­nia i opi­sa­nia mecha­ni­zmu ana­li­zo­wa­nej orga­ni­za­cji, któ­ry to mecha­nizm to nic inne­go jak opis (pro­jekt) logi­ki dzia­ła­nia tego oprogramowania.

Takie opra­co­wa­nia i pro­jek­ty, jako doku­men­ty (treść), sta­no­wią przed­miot Prawa Autorskiego. Zawierają w sobie nie raz tre­ści nio­są­ce know-how orga­ni­za­cji będą­cej przed­mio­tem ana­li­zy i opi­su. Posiadanie praw mająt­ko­wych do takich opra­co­wań i pro­jek­tów sta­no­wi o moż­li­wo­ści sku­tecz­nej, praw­nej ochro­ny przez przed­się­bior­stwo jego know-how i opra­co­wa­nych dla nie­go, na bazie tego know-how, roz­wią­zań (np. pro­ce­dur, dedy­ko­wa­ne­go oprogramowania).

W celu zagwa­ran­to­wa­nia tej ochro­ny wyma­ga­na jest pre­cy­zja opi­su pozwa­la­ją­ca uznać uni­kal­ność tre­ści ana­li­zy i doku­men­ta­cji projektu.

Niestety nie są chro­nio­ne pra­wem same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94). Precyzję opi­su dają­cą ochro­nę uzy­sku­je się dopie­ro opra­co­wu­jąc pro­jekt sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we opi­su­ją­ce mecha­ni­zmy dzia­ła­nia i struk­tu­ry infor­ma­cji.?4?

Tak więc, o czym wie­lo­krot­nie już pisa­łem, roz­wle­kłe epic­kie opi­sy funk­cjo­no­wa­nia ana­li­zo­wa­nej orga­ni­za­cji, nie tyl­ko nie sta­no­wią wystar­cza­ją­ce­go mate­ria­łu do powsta­nia opro­gra­mo­wa­nia, nie sta­no­wią nie­jed­no­krot­nie mate­ria­łu zdat­ne­go do ochro­ny jako tajem­ni­ca przedsiębiorstwa.

Na zakończenie

Prawo chro­nią­ce war­to­ści inte­lek­tu­al­ne chro­ni tak­że know-how, któ­re to jest taką war­to­ścią. Ochrona know-how jest coraz lepiej opi­sy­wa­na w Ustawach. Biorąc pod uwa­gę, że prze­pi­sy­wa­nie Ustaw do umów nie wno­si żad­nej war­to­ści do tre­ści umo­wy, zaś wszel­kie domnie­ma­nia winy są szko­dli­we dla stro­ny, na któ­rą prze­no­si się domnie­ma­nie winy za ujaw­nia­nie infor­ma­cji, czy­ni w moich oczach, umo­wy o pouf­no­ści szko­dli­wy­mi. Ogrom nie­chluj­stwa w obsza­rze ochro­ny infor­ma­cji jaki obser­wu­ję w wie­lu fir­mach, nie da się przy­kryć nie­uczci­wą umo­wą o zacho­wa­niu pouf­no­ści. Częste tłu­ma­cze­nia, że to wyma­ga­ny stan­dard kor­po­ra­cyj­ny” to tyl­ko praw­ni­cza for­ma mani­pu­la­cji i per­swa­zji lub zwy­kłe kor­po­ra­cyj­ne nadużycie.

Prawnicy wie­lu firm poświę­ca­ją ogrom­ne ilo­ści cza­su (i środ­ków) na ochro­ną danych oso­bo­wych, a cał­ko­wi­cie baga­te­li­zu­ją kwe­stie ochro­ny know-how. Jest to dla mnie wręcz niepojęte.

Bez wyraź­ne­go roz­dzie­le­nia praw do Specyfikacji i Kodu pro­gra­mu, poja­wia­ją się ogrom­ne pro­ble­my z usta­le­niem praw stron. Na tym tle wszel­kie for­my pro­wa­dze­nia pro­jek­tów i wdro­żeń ogra­ni­cza­ją­ce powsta­wa­nie doku­men­tów, szcze­gól­nie Specyfikacji, popu­lar­nie zwa­ne meto­da­mi zwin­ny­mi, pro­wa­dzą do ogrom­nych pro­ble­mów. Typową kon­se­kwen­cją tak zwa­ne­go zwin­ne­go podej­ścia, jest przej­mo­wa­nie praw do know-how przez wyko­naw­ców (nie­ste­ty czę­sto celo­we): autor Kodu pro­gra­mu, któ­ry to kod powstał z pomi­nię­ciem two­rze­nia Specyfikacji opro­gra­mo­wa­nia, wyłącz­nie na pod­sta­wie wywia­dów z przy­szły­mi użyt­kow­ni­ka­mi i ich prze­ło­żo­ny­mi, ma do tego kodu wszel­kie pra­wa, a Zamawiający żad­nych (musiał by je nabyć do twór­cy kodu).?5?

Bardzo czę­ste zapi­sy w umo­wach z dostaw­ca­mi opro­gra­mo­wa­nia, mówią­ce że wszel­kie war­to­ści inte­lek­tu­al­ne powsta­ją­ce w trak­cie pro­jek­tu, prze­cho­dzą na wła­sność dostaw­cy opro­gra­mo­wa­nia, są potęż­nym nad­uży­ciem, żeby nie powie­dzieć: kra­dzie­żą know-how. 

I uwa­ga do pra­cy wie­lu prawników:

Jeżeli twój praw­nik rozu­mie kon­trakt lepiej niż twoi ludzie z biz­ne­su, ozna­cza to że zarów­no praw­nik może mieć pro­blem z tłu­ma­cze­niem praw­nych kom­po­nen­tów całej trans­ak­cji, ale tak­że że twój biz­nes w nie­wła­ści­wy spo­sób komu­ni­ku­je praw­ni­ko­wi cele i zało­że­nia biz­ne­su, któ­re­go umo­wa doty­czy. Może czas coś z tym zro­bić??6?

Czytelnikom zain­te­re­so­wa­nym szcze­gó­ła­mi pole­cam lek­tu­rę cało­ści cyto­wa­nych dokumentów.

__________________
  1. 1.
  2. 2.
  3. 3.
    Ustawa z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji. Dz.U. 1993 nr 47 poz. 211. Baza Internetowy System Aktów Prawnych – ISAP. http://​pra​wo​.sejm​.gov​.pl/​i​s​a​p​.​n​s​f​/​D​o​c​D​e​t​a​i​l​s​.​x​s​p​?​i​d​=​W​D​U​1​9​9​3​0​4​7​0​211. Published September 8, 2018. Accessed September 8, 2018.
  4. 4.
    Zelinski J. Ochrona know-how Prawo autor­skie | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//prawa-autora-analizy-i-ochrona-know-how-organizacji-analizowanej/. Published September 8, 2018. Accessed September 8, 2018.
  5. 5.
    Zelinski J. Przedmiot Zamówienia ? instruk­cja nie tyl­ko dla praw­ni­ków, na zupę pomi­do­ro­wą | | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//2017/02/16/przedmiot-zamowienia-instrukcja-dla-prawnikow-na-zupe-pomidorowa/. Published February 16, 2017. Accessed September 8, 2018.
  6. 6.
    TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK . LinkedIn. https://pl.linkedin.com/pulse/twój-prawnik-rozumie-kontrakt-lepiej-niż-twoi-ludzie-warchol-lewicka. Published March 7, 2018. Accessed September 8, 2018.

Know-how a Zasada Kerckhoffs’a i bezpieczeństwo

Wprowadzenie

Tematem numer jeden, nie­mal­że w każ­dym moim pro­jek­cie, jest model biz­ne­so­wy i tajem­ni­ca przed­się­bior­stwa. Z per­spek­ty­wy lat muszę powie­dzieć, że to fobia wie­lu (jak nie więk­szo­ści) przed­się­bior­ców i nie tyl­ko przed­się­bior­ców. Nie dla­te­go, że chcą coś chro­nić, ale dla­te­go co i jak chro­nią. Nie raz już pisa­łem, że fir­my nie raz, naj­pierw pod­pi­su­ją z dostaw­ca­mi roz­wią­zań i kon­sul­tan­ta­mi umo­wy o pouf­no­ści, a potem wyzby­wa­ją praw do swo­je­go know-how na ich rzecz:

W bran­ży inży­nie­rii opro­gra­mo­wa­nia dość powszech­na jest sytu­acja, gdy pro­gra­mi­sta jest tak­że pro­jek­tan­tem, inny­mi sło­wy pro­gra­mi­sta ma peł­nię praw autor­skich do kodu jaki two­rzy a jego klient żad­nych mimo, że jest inwe­sto­rem!1

Dzisiaj dru­gi pro­blem czy­li bez­pie­czeń­stwo infor­ma­cji a nie raz i całej firmy.

Na począ­tek coś z zakres teo­rii informacji:

Zasada Kerckhoffs’a to jed­na z pod­sta­wo­wych reguł współ­cze­snej kryp­to­gra­fii. Została sfor­mu­ło­wa­na pod koniec XIX wie­ku przez holen­der­skie­go kryp­to­lo­ga Augusta Kerckhoffs’a (ur. 19 stycz­nia 1835, zm. 9 sierp­nia 1903). Zasada ta mówi, że sys­tem kryp­to­gra­ficz­ny powi­nien być bez­piecz­ny nawet wte­dy, gdy są zna­ne wszyst­kie szcze­gó­ły jego dzia­ła­nia oprócz sekret­ne­go klucza. […]

  1. System powi­nien być, jeśli nie teo­re­tycz­nie, to w prak­ty­ce nie do złamania.
  2. Projekt sys­te­mu nie powi­nien wyma­gać jego taj­no­ści, a ewen­tu­al­ne jego ujaw­nie­nie nie powin­no przy­spa­rzać kło­po­tów korespondentom.
  3. Klucz powi­nien być moż­li­wy do zapa­mię­ta­nia bez noto­wa­nia i łatwy do zmienienia.
  4. Kryptogramy powin­ny być moż­li­we do prze­sła­nia dro­gą telegraficzną.
  5. Aparatura i doku­men­ty powin­ny być moż­li­we do prze­nie­sie­nia i obsłu­że­nia przez jed­ną osobę.
  6. System powi­nien być pro­sty ? nie wyma­ga­ją­cy zna­jo­mo­ści wie­lu reguł ani nie obcią­ża­ją­cy zbyt­nio umysłu.

Właśnie dru­ga z tych reguł nosi obec­nie nazwę zasa­dy Kerckhoffs’a.

[…]Ideę zasa­dy Kerckhoffs’a wyra­ża rów­nież przy­pi­sy­wa­ne Claude’owi Shannon’owi powie­dze­nie Wróg zna sys­tem” (ang. The ene­my knows the sys­tem), zna­ne pod nazwą Maksymy Shannona (ang. Shannon’s maxim).2

Zasadę tę, jako kry­te­rium, moż­na łatwo posze­rzyć, usu­wa­jąc ostat­nie sło­wo do postaci:

Projekt sys­te­mu nie powi­nien wyma­gać jego taj­no­ści, a ewen­tu­al­ne jego ujaw­nie­nie nie powin­no przy­spa­rzać kłopotów.

Na ryn­ku mamy dwa prze­ciw­staw­ne w pew­nym sen­sie (o tym dalej) poję­cia: patent oraz know-how, dodać nale­ża­ło by do tego zesta­wu poję­cie pra­wo autor­skie oso­bi­ste i mająt­ko­we.

O bezpieczeństwie biznesowym

Na począ­tek kla­sycz­nie klu­czo­we definicje:

know-how: rozu­mia­ne jest jako pakiet nie­opa­ten­to­wa­nych infor­ma­cji prak­tycz­nych, wyni­ka­ją­cych z doświad­cze­nia i badań, któ­re są:
1. nie­jaw­ne (nie są powszech­nie zna­ne lub łatwo dostęp­ne);
2. istot­ne (waż­ne i uży­tecz­ne z punk­tu widze­nia wytwa­rza­nia Szczegóły:

">pro­duk­tów obję­tych umo­wą);
3. ziden­ty­fi­ko­wa­ne (czy­li opi­sa­ne w wystar­cza­ją­co zro­zu­mia­ły spo­sób, aby moż­na było spraw­dzić, czy speł­nia­ją kry­te­ria nie­jaw­no­ści i istot­no­ści). (źr. Rozporządzenie Unii Europejskiej nr 772/2004 w spra­wie sto­so­wa­nia art. 81 ust. 3 Traktatu do kate­go­rii poro­zu­mień o trans­fe­rze technologii).

bez­pie­czeń­stwo: stan nie­za­gro­że­nia (s.j.p.)

tajem­ni­ca: sekret; też: nie­ujaw­nia­nie cze­goś (s.j.p.)

patent: doku­ment przy­zna­ją­cy jakiejś oso­bie lub fir­mie wyłącz­ne pra­wo do czer­pa­nia korzy­ści z wyna­laz­ku; też: to pra­wo (s.j.p.)

infor­ma­cja: to, co powie­dzia­no lub napi­sa­no o kimś lub o czymś, tak­że zako­mu­ni­ko­wa­nie cze­goś (s.j.p.)

utwór: 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 (Ustawa)

Dla zapew­nie­nia i spraw­dze­nia jed­no­znacz­no­ści tego tek­stu zbu­duj­my model poję­cio­wy (tak­so­no­mia i syn­tak­ty­ka pojęć, przy­po­mi­nam, że nie korzy­sta­my w takich ana­li­zach a onto­lo­gii, poniż­szy dia­gram to nie ontologia):

Warto tu zwró­cić uwa­gę na to, że poję­cie opis paten­tu poja­wia się w tak­so­no­mii indy­wi­du­ali­zmu tre­ści jak i jej dostęp­no­ści. Innymi sło­wy opis paten­tu jest zarów­no utwo­rem jak i tre­ścią nie będą­cą tajem­ni­cą.
I teraz pyta­nie: co nale­ży chro­nić i dla­cze­go? To zależy…

Patent to mono­pol, jed­nak fak­ty poka­zu­ją, że mono­po­le trze­ba same­mu egze­kwo­wać, co nie zawsze jest eko­no­micz­nie uza­sad­nio­ne, przy zało­że­niu że kosz­ty ochro­ny paten­tu nie powin­ny prze­kro­czyć korzy­ści z jego posia­da­nia. I nie mam tu na myśli tyl­ko opłat dla Urzędu paten­to­we­go, a poten­cjal­ne sta­łe kosz­ty ochro­ny z tytu­łu wyta­cza­nych pozwów cywil­nych za łama­nie praw paten­to­wych. Rynek poka­zu­je, że nie raz ochro­nę paten­to­wą moż­na zastą­pić ochro­ną z tytu­łu praw autor­skich (treść opi­su jakie­goś roz­wią­za­nia to utwór, patrz dia­gram powy­żej) np. wzo­ry prze­my­sło­we, tym bar­dziej że są rze­czy któ­rych nie moż­na opa­ten­to­wać, ale moż­na opi­sać i chro­nić wła­śnie jako utwór (np. logi­kę opro­gra­mo­wa­nia).

Know-how

Know-how to kolej­ny cie­ka­wy obszar, bo wyma­ga­ją­cy bar­dzo czę­sto ochro­ny. Patent z zasa­dy jest tre­ścią jaw­ną, poda­wa­ną do publicz­nej wia­do­mo­ści. Jeżeli ktoś uzna, że jego know-how sta­no­wi o jego prze­wa­dze a nie chce czy­nić z nie­go paten­tu, to ma dwa wyj­ścia: (1) utrzy­my­wać know-how na pozio­mie trud­nym do naśla­do­wa­nia, to się nazy­wa utrzy­my­wa­nie barie­ry wej­ścia (patrz ana­li­za pię­ciu sił Portera), albo (2) utrzy­my­wać know-how w tajem­ni­cy przed kon­ku­ren­cją. To klu­czo­wy praw­dzi­wy powód pod­pi­sy­wa­nia umów o zacho­wa­niu pouf­no­ści (dru­gi to pra­wo regu­lu­ją­ce dostęp do infor­ma­cji w spół­kach giełdowych).

I teraz jesz­cze raz cyto­wa­na na począt­ku zasada:

Projekt sys­te­mu nie powi­nien wyma­gać jego taj­no­ści, a ewen­tu­al­ne jego ujaw­nie­nie nie powin­no przy­spa­rzać kłopotów.

I to jest ide­ał (ide­ali­za­cja) do pro­wa­dze­nia ana­liz. Punktem wyj­ścia w pro­jek­cie powin­na być ana­li­za spraw­dza­ją­ca czy fak­tycz­nie ujaw­nie­nie danej infor­ma­cji przy­no­si szko­dę a jeże­li tak, to dla­cze­go. Dalej: jeże­li know-how sta­no­wi sobą okre­ślo­ny mecha­nizm i jego ujaw­nie­nie przy­no­si szko­dę, to fak­tycz­nie nale­ży go – jego opis – chro­nić. Jak? Przede wszyst­kim taki, pre­cy­zyj­ny, opis musi w ogó­le powstać. Jeżeli z jakie­goś powo­du nie może być przed­mio­tem paten­tu, to pozo­sta­je pra­wo autor­skie. A sko­ro tak, to: (1) posia­da­czem pra­wa mająt­ko­we­go do opi­su know-how powi­nien być ten, kto chro­ni swo­je know-how, (2) jeże­li opro­gra­mo­wa­nie ma reali­zo­wać mecha­nizm sta­no­wią­cy know-how, to dostaw­ca (wyko­naw­ca) tego opro­gra­mo­wa­nia nie powi­nien mieć żad­nych praw do tego know-how, o ile tyl­ko fak­tycz­nie sta­no­wi ono o prze­wa­dze na rynku.

Ideał jest taki jak zasa­da powy­żej, wnio­sek zaś jest taki, że jeże­li o prze­wa­dze ryn­ko­wej sta­no­wi tajem­ni­ca, jej bez­pie­czeń­stwo sta­je się klu­czo­we. A jak chro­nić tajem­ni­cę czy­li infor­ma­cje? W ten sam spo­sób: sys­tem opi­su­ją­cy bez­pie­czeń­stwo infor­ma­cji opi­su­je się pro­ce­du­ra­mi i pro­ce­sa­mi :), a te wła­śnie (doku­men­ty opi­su­ją­ce pro­ce­sy), zgod­nie z zasa­dą opi­sa­ną na począt­ku, nie powin­ny wyma­gać ochrony…

Warto na koniec dodać, że na grun­cie usta­wy o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji know-how naby­wa­ne przez pra­cow­ni­ków IT pod­le­ga obo­wiąz­ko­wi ochro­ny tajem­ni­cy przed­się­bior­stwa, któ­ry od dnia 4 wrze­śnia 2018 r. został okre­ślo­ny jako bezterminowy…

Na zakończenie

Bardzo czę­sto jestem pyta­ny o róż­ni­cę pomię­dzy chro­nio­nym utwo­rem a chro­nio­nym know-how. Popatrzmy na poniż­szą map­kę, zna­ną z książ­ki (i gier) Wyspa Skarbów:

Otóż map­ka ta jest chro­nio­na pra­wem autor­skim jako obraz gra­ficz­ny. Jeżeli praw­dą zaś jest, że treść map­ki zawie­ra wie­dzę o tym jak dotrzeć do skar­bu, to wie­dza ta sta­no­wi know-how pira­tów i jest trzy­ma­na w tajem­ni­cy. Tak więc map­ka ta jest utwo­rem nio­są­cym wie­dzę o know-how. :). Wystarczająco pre­cy­zyj­ny pro­jekt archi­tek­tu­ry i logi­ki dzia­ła­nia opro­gra­mo­wa­nia jest tak­że utwo­rem, nio­są­cym wie­dzę o know-how.

A teraz popa­trz­cie Państwo na swo­je umo­wy z dostaw­ca­mi opro­gra­mo­wa­nia… i miej­cie ogra­ni­czo­ne zaufa­nie do praw­ni­ków firm dostaw­ców oprogramowania 🙂