Wczoraj mia­ła miej­sce kon­fe­ren­cja Forum pra­wa nowych tech­no­lo­gii zor­ga­ni­zo­wa­na przez Centrum Promocji Informatyki. Jednak to nie mój refe­rat z tego semi­na­rium, a pew­na kon­klu­zja po burz­li­wej dys­ku­sji, będzie dziś tema­tem przewodnim.

To o czym był mój refe­rat, to ochro­na know-how zama­wia­ją­ce­go (opis spo­so­bu pra­cy orga­ni­za­cji) i ochro­na tego co zamó­wił i za co zapła­cił (opro­gra­mo­wa­nie jak utwór). Ale tu będzie o kodzie i pra­wach do nie­go… (kto nie był na kon­fe­ren­cji niech żałuje ;))

Przytoczmy na począ­tek defi­ni­cję ​„tego co chro­ni pra­wo autor­skie” czy­li czym jest ​„przed­miot pra­wa autorskiego”:

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) (źr. Ustawa z dnia 4 Lutego 1994 roku o pra­wie autor­skim i pra­wach pokrewnych).

2/3 kon­fe­ren­cji praw­ni­cy wyka­zy­wa­li, że jedy­ne co moż­na sku­tecz­nie chro­nić pra­wem (albo wyce­niać) to stan udo­ku­men­to­wa­ny. Czyli, jeże­li chce­my chro­nić wie­dzę o swo­jej wewnętrz­nej orga­ni­za­cji, tak zwa­ny know-how, oraz pomysł na to co powin­no ​„umieć” zama­wia­ne opro­gra­mo­wa­nie by nam poma­ga­ło, nale­ży posłu­żyć się pra­wem autor­skim, tajem­ni­cą przed­się­bior­stwa i mieć to w posta­ci udo­ku­men­to­wa­nej. Zapis, któ­ry od lat poma­ga mi i moim klien­tom chro­nić pro­jek­ty i know-how brzmi tak (moż­na go użyć w swo­ich dokumentach :)):

Treść doku­men­tu jest chro­nio­na na mocy USTAWY z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji oraz na mocy USTAWY z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych. Posiadanie egzem­pla­rza tego opra­co­wa­nia nie sta­no­wi naby­cia jakich­kol­wiek praw do jego treści.

(szcze­gó­ły ustaw i para­gra­fów były pre­zen­to­wa­ne na semi­na­rium, w razie potrze­by pole­cam wizy­tę w dobrej kan­ce­la­rii prawnej).

Ale po kolei czyli…

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

Opiszę to języ­kiem dla osób nie zna­ją­cych inży­nie­rii oprogramowania.

Pierwszą rze­czą jaką war­to chro­nić jest wypra­co­wa­na wewnętrz­na orga­ni­za­cja pra­cy, spo­sób pra­cy fir­my czy­li pro­ce­du­ry, regu­ły biz­ne­so­we, kom­pe­ten­cje pra­cow­ni­ków (i wie­le innych). Kompletny taki opis, raport z audy­tu orga­ni­za­cji, zawie­ra mode­le pro­ce­sów biz­ne­so­wych sko­ja­rzo­ne z pro­ce­du­ra­mi, zakre­sa­mi obo­wiąz­ków, regu­ła­mi biz­ne­so­wy­mi itp. Tak powsta­je udo­ku­men­to­wa­ne nasze ​„know-how”.

Kolejna rzecz to opra­co­wa­nie opi­su a cza­sem pro­jek­tu, opro­gra­mo­wa­nia, któ­re chce­my nabyć lub zamó­wić, a kon­kret­nie tego ​„co i jak ono powin­no umieć”. Opis taki nie powi­nien poprze­sta­wać tyl­ko na tym co-ma-sys­tem-robić (wyma­ga­nia w posta­ci przy­pad­ków uży­cia). Firmy róż­nią się tym jak-to-jest-robio­ne u nich, więc nie wystar­czy napi­sać, że ​„sys­tem ma wspie­rać przy­ję­cia na maga­zyn i sto­so­wać usta­lo­ne meto­dy zarzą­dza­nia kosz­ta­mi pro­duk­tów”. Powierzenie dostaw­cy zada­nia udo­ku­men­to­wa­nia (ana­li­za przed-wdro­że­nio­wa) np. ​„meto­dy zarzą­dza­nia pro­duk­ta­mi” na 99% zaowo­cu­je opi­sem tego co dostaw­ca może zaofe­ro­wać, a nie tego jak-pra­cu­je-zama­wia­ją­cy i co jest mu potrzeb­ne. Po dru­gie auto­rem ​„pomy­słu” będzie dostaw­ca (wyko­naw­ca) więc do nie­go będą nale­ża­ły pra­wa do wła­sno­ści inte­lek­tu­al­nej zawar­tej w opro­gra­mo­wa­niu – a tego wła­śnie nie chcemy.

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

Owszem, poni­żej meto­da opi­sa­na jako stan­dard (opis dostęp­ny za dar­mo bez żad­nych opłat) na stro­nach https://​www​.omg​.org/​mda:

Co może­my. Etap pierw­szy to udo­ku­men­to­wa­nie know-how fir­my czy­li model orga­ni­za­cji i spo­so­bu jej dzia­ła­nia (opi­sy­wa­ny na stro­nach tego blo­ga wie­lo­krot­nie). Jak już wspo­mnia­łem, ele­men­tem know-how są udo­ku­men­to­wa­ne mode­le pro­ce­sów biz­ne­so­wych, regu­ły biz­ne­so­we i struk­tu­ra orga­ni­za­cji. Ten opis, jako doku­ment, jest chro­nio­ny pra­wem autor­skim jako dzie­ło, treść zaś jest chro­nio­na pra­wem o prze­ciw­dzia­ła­niu nie­uczci­wej kon­ku­ren­cji jako know-how fir­my. Warunek: taki opis MUSI ist­nieć a pra­wa mająt­ko­we do nie­go powi­nien posia­dać opi­sa­ny w nim pod­miot. Autor, jeże­li nie był pra­cow­ni­kiem fir­my pod­czas two­rze­nia, powi­nien mieć dodat­ko­wo umo­wę o pouf­no­ści i po zakoń­cze­niu pra­cy prze­ka­zać pisem­nie pra­wa mająt­ko­we do dzie­ła swo­je­mu klien­to­wi.

Tak więc, jeże­li ktoś z zewnątrz robi taką ana­li­zę (np. pra­cow­nik dostaw­cy opro­gra­mo­wa­nia czy nie­za­leż­ny kon­sul­tant) i nie chce prze­ka­zać praw mająt­ko­wych do opra­co­wa­nia, orga­ni­za­cji ana­li­zo­wa­nej, to nale­ży się zacząć bać. Na powyż­szym dia­gra­mie ten etap nazy­wa Computing Independent Mode (model dzia­ła­nia orga­ni­za­cji na pozio­mie nie­za­leż­nym od uży­wa­nych sys­te­mów IT).

Chcemy mieć oprogramowanie wspomagające nasz biznes

Na bazie powyż­szej doku­men­ta­cji powsta­je opis, któ­re obsza­ry dzia­ła­nia fir­my chce­my wspie­rać opro­gra­mo­wa­niem i jak. To okre­śle­nie zakre­su pro­jek­tu. Następnie, w mode­lach pro­ce­sów wska­zu­je­my czyn­no­ści, któ­re mają być wspie­ra­ne nowym opro­gra­mo­wa­niem. To ocze­ki­wa­ne funk­cjo­nal­no­ści (usłu­gi apli­ka­cyj­ne) nowe­go opro­gra­mo­wa­nia (w nota­cji UML nazy­wa­ne przy­pad­ka­mi uży­cia). Dodajemy do nich ele­men­ty jako­ścio­we czy­li wyma­ga­nia poza-funk­cjo­nal­ne (ogra­ni­cze­nia np. nie­za­wod­ność, bez­pie­czeń­stwo itp.). To jed­nak za mało, to tyl­ko opis tego co-sys­tem-ma-robić (idea).

Jednoznaczne są dopie­ro opi­sy logi­ki biz­ne­so­wej, czy­li jak-sys­tem-ma-to-robić (w koń­cu sys­tem poza zapi­sy­wa­niem, prze­twa­rza nasze dane), opis tego, cze­go ocze­ku­je­my od tego opro­gra­mo­wa­nia (co ono powin­no umieć). To kolej­ny opis, udo­ku­men­to­wa­ne coś, co chce­my chro­nić. Zakładam, że spe­cy­fi­ka fir­my, wypra­co­wa­na logi­ka biz­ne­so­wa, to dobro war­te ochro­ny. Taki opis to war­stwa dru­ga od góry na powyż­szym dia­gra­mie (model opro­gra­mo­wa­nia PIM, Platform Independent Model). Do tego doku­men­tu tak­że nale­ży mieć pra­wa mająt­ko­we. Ten model to już szcze­gó­ło­wy pro­jekt, jedy­ne cze­go może nie zawie­rać to spe­cy­fi­ka uży­te­go języ­ka pro­gra­mo­wa­nia czy wyko­rzy­sta­ne ele­men­ty cudze­go opro­gra­mo­wa­nia (tak zwa­ne biblio­te­ki, fra­me­wor­ki, śro­do­wi­sko sys­te­mo­we pra­cy itp…). Także inne, nie będą­ce spe­cy­fi­ką fir­my (tym co chce­my chro­nić) stan­dar­do­we ele­men­ty takie jak logo­wa­nie do sys­te­mu czy np. spo­sób drukowania.

A teraz niech nam to dostarczą

No to szu­ka­my dostaw­cy (wyko­naw­cy) opro­gra­mo­wa­nia: robi­my listę poten­cjal­nych dostaw­ców, ktoś wygry­wa prze­targ, pod­pi­su­je­my umo­wę o pouf­no­ści, wyko­naw­ca dosta­je do wyko­rzy­sta­nia udo­ku­men­to­wa­ny know-how, pra­wo autor­skie chro­ni taki opis z zasa­dy. Wyłaniamy dostaw­cę, pro­jekt dobie­ga koń­ca. Dostawca nie ma moż­li­wo­ści praw­nej zaofe­ro­wa­nia tego opro­gra­mo­wa­nia (tego co obej­mu­je nasza spe­cy­fi­kę) niko­mu inne­mu. Wszystko co zro­bił na bazie naszej doku­men­ta­cji jest dzie­łem zależ­nym, bez naszej zgo­dy wyko­naw­ca nie ma pra­wa tym kodem dys­po­no­wać. Jesteśmy uratowaniu :)!

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

A jasne, może­my chcieć. ​„No to zapłać­cie za to pra­wo”. A prze­pra­szam za co teraz? Kod, któ­ry powstał to utwór zależ­ny, jest więc chro­nio­ny i już mamy na nie­go wyłącz­ność, nie musi­my eks­tra za to pła­cić. Ale nie chce­my tego sami pisać (kodo­wać) jesz­cze raz. No dobrze, patrzy­my na fak­tu­ry, a tam jest kil­ka­set godzin pro­gra­mi­stów. Czyli co? Już zapła­ci­li­śmy za ich pra­cę, za ten kod! Wystarczy!

Kiedy pojawia się problem?

W więk­szo­ści przy­pad­ków z jaki­mi się nie­ste­ty spo­ty­kam to pro­jek­ty, w któ­rych nie powsta­ła opi­sa­na tu doku­men­ta­cja. Jaki mamy efekt? No jest kod, wszel­kie pra­wa do nie­go i jego logi­ki ma wyko­naw­ca (jest auto­rem cało­ści). Specyfikacja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych pod­le­ga wyłącz­nie ochro­nie jako dzie­ło lite­rac­kie, jed­nak nie­ste­ty to-co-pro­gram-ma-robić to tyl­ko idea, a ta nie pod­le­ga ochro­nie (stwier­dze­nie fak­tu, że wysta­wia­my fak­tu­ry, jako treść, nie sta­no­wi żad­ne­go zdat­ne­go do ochro­ny tajem­ni­cą fir­my know-how). Tak więc wszel­kie pra­wa do kodu ma w takim wypad­ku pro­gra­mi­sta bo sam od zera to napi­sał (kod).

Pada pro­po­zy­cja: za dodat­ko­we pie­nią­dze sprze­da­my pra­wa mająt­ko­we do kodu, będzie­cie się Państwo czu­li bez­piecz­nie. I teraz pyta­nie: jaką war­tość ma nie­udo­ku­men­to­wa­ny kod opro­gra­mo­wa­nia? Tysiące linii kodu pro­gra­mu, nie raz kil­ka milio­nów, pisa­ny bez pro­jek­tu w wie­lu ite­ra­cjach. Mamy któ­rąś tam jego wer­sję, w koń­cu powsta­wał w bólach, wie­lo­krot­nie mody­fi­ko­wa­ny, bez pro­jek­tu. Nakład pra­cy wie­lo­krot­nie prze­wyż­sza­ją­cy jego powtór­ne prze­pi­sa­nie. Kto i jakim kosz­tem będzie ten kod ana­li­zo­wał by go zro­zu­mieć i roz­wi­jać? Ten kod, bez jego auto­ra, jest z regu­ły BEZWARTOŚCIOWY a My, bez tej opła­ty, nie mamy żad­nych praw do tego za co zapła­ci­li­śmy (poza licen­cją czy­li pra­wem do korzy­sta­nia). Pat.

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

A jak to wyglą­da w przy­pad­ku zaku­pu goto­we­go ERP i jego ​„kasto­mi­za­cji”? Jest to cudzy pro­dukt, zapew­ne może­my dostać pra­wa do kodu ​„na wła­sny uży­tek” w co jed­nak wąt­pię, raczej dosta­nie­my licen­cje na uży­wa­nie. A nasze know-how? Jeżeli nasze dedy­ko­wa­ne wyma­ga­nia zosta­ły ​„zre­ali­zo­wa­ne” w posta­ci kasto­mi­za­cji kodu tego pro­duk­tu, to i tak nadal jest on wła­sno­ścią dostaw­cy (pro­du­cen­ta) i nic nam do nie­go. Niektóre fir­my idą dalej, ​„pod­ty­ka­ją” swo­im klien­tom aneks do umo­wy, z zapi­sem, że kod powsta­ły pod­czas wdro­że­nia (w tym kasto­mi­za­cja), zawie­ra­ją­cy pomy­sły na nowe funk­cjo­nal­no­ści w cało­ści prze­cho­dzi na wła­sność dostaw­cy opro­gra­mo­wa­nia ERP. Jeżeli zgo­dzi­cie się na to, nie zdziw­cie się gdy dowie­cie się np. z gaze­ty, że jakaś fir­ma kupi­ła od Waszego ​„part­ne­ra” moduł z logi­ką biz­ne­so­wą ​„wasze­go pomysłu”…

U nie­któ­rych praw­ni­ków moż­na się spo­tkać z tezą:

Zgodnie usta­wą o pra­wie autor­skim i pra­wach pokrew­nych pro­gra­my kom­pu­te­ro­we pod­le­ga­ją ochro­nie jak utwo­ry lite­rac­kie, o ile prze­pi­sy roz­dzia­łu VII usta­wy nie sta­no­wią ina­czej. Taki zapis sta­tu­uje więc ogól­ną zasa­dę włą­cze­nia pro­gra­mów kom­pu­te­ro­wych pod reżim ochro­ny praw­no­au­tor­skiej, zrów­nu­jąc je w tym aspek­cie z utwo­ra­mi literackimi.

Ochrona przy­zna­na pro­gra­mo­wi kom­pu­te­ro­we­mu obej­mu­je wszyst­kie for­my jego wyra­że­nia. Natomiast idee i zasa­dy będą­ce pod­sta­wą jakie­go­kol­wiek ele­men­tu pro­gra­mu kom­pu­te­ro­we­go, w tym pod­sta­wą łączy, nie pod­le­ga­ją ochro­nie (w pra­wie autor­skim idee ? wsze­la­kie ? nie są chro­nio­ne). O ile ele­men­ty tek­sto­we pro­gra­mu (w zna­cze­niu kon­kret­ne­go przed­sta­wie­nia cią­gu instruk­cji) pod­le­ga­ją ochro­nie, o tyle w przy­pad­ku ele­men­tów poza­tek­sto­wych (algo­rytm – struk­tu­ra pro­gra­mu języ­ka pro­gra­mo­wa­nia) trze­ba się raczej liczyć z ich wyłą­cze­niem spod ochro­ny pra­wa autor­skie­go. (Kod źró­dło­wy – aspek­ty prawne).

To podej­ście jest nie­kom­plet­ne, gdyż pomi­ja aspekt (ewen­tu­al­ny etap) pro­jek­to­wa­nia jako eta­pu two­rze­nia opro­gra­mo­wa­nia. Zresztą nie tyl­ko opro­gra­mo­wa­nia ale tak­że spe­cy­fi­ki orga­ni­za­cji, któ­ra może zostać ​„zawar­ta” w opro­gra­mo­wa­niu w posta­ci spe­cy­ficz­nej, uni­kal­nej logi­ki działania. 

Skoro ​„Ochrona przy­zna­na pro­gra­mo­wi kom­pu­te­ro­we­mu obej­mu­je wszyst­kie for­my jego wyra­że­nia” to zna­czy, że każ­dy jed­no­znacz­ny jego pro­jekt tak­że. Ustawa nie sta­no­wi, że jedy­nie for­ma tek­sto­wa pro­gra­mu pod­le­ga ochro­nie, ochro­nie pod­le­ga każ­da for­ma wyra­że­nia dzie­ła. Prawo autor­skie chro­ni w jed­na­ko­wym stop­niu tekst, zdję­cia czy pra­ce gra­ficz­ne, sche­mat blo­ko­wy (szcze­gó­ło­wy algo­rytm) tak­że pod­le­ga ochro­nie, bo speł­nia kry­te­rium uni­kal­no­ści. Skoro mamy tech­no­lo­gię (meto­dy), pozwa­la­ją­cą napi­sać kod pro­gra­mu na bazie jego sche­ma­tu blo­ko­we­go (a nawet cza­sem auto­ma­tycz­nie wyge­ne­ro­wać) to taki dokład­ny sche­mat blo­ko­wy tak­że pod­le­ga ochro­nie z tytu­łu pra­wa autor­skie­go jako dzie­ło. To już nie jest idea a program.

Jeżeli dodat­ko­wo ten algo­rytm opi­su­je spe­cy­fi­kę pra­cy danej fir­my to pod­le­ga tak­że ochro­nie jako tajem­ni­ca przed­się­bior­stwa. Jest więc nie­ja­ko podwój­nie chro­nio­ny. Oczywiście, co pod­kre­ślam po raz kolej­ny, sche­mat blo­ko­wy o jakim mowa musi być jed­no­znacz­ny, nie może to być tyl­ko zapis ​„pomy­słu”. Z per­spek­ty­wy dia­gra­mów BPMN i UML (gra­ficz­ne języ­ki) mamy więc:

1. BPMN: model pro­ce­su na wyso­kim pozio­mie abs­trak­cji (np. dwa blocz­ki: pro­ces sprze­da­ży połą­czo­ny z pro­ce­sem obsłu­gi rekla­ma­cji) to idea,
2. BPMN: dokład­ny sce­na­riusz (pro­ce­du­ra) obsłu­gi sprze­da­ży spe­cy­ficz­ny dla kon­kret­nej fir­my, obra­zu­ją­cy spe­cy­fi­kę kom­pe­ten­cji jej pra­cow­ni­ków i funk­cjo­no­wa­nia, to pod­le­ga­ją­cy ochro­nie opis know-how fir­my, dia­gram to opi­su­ją­cy wraz z opi­sem i komen­ta­rza­mi to utwór chro­nio­ny pra­wem autor­skim. Stanowi zapis know-how. 
3. UML: dia­gram przy­pad­ków uży­cia: to idea pomy­słu (podob­nie jak tek­sto­wa spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych), to wyłącz­nie dzie­ło lite­rac­kie, pro­gram jaki powsta­nie na tej pod­sta­wie nie jest wią­za­ny z taką spe­cy­fi­ka­cją jako utwór zależ­ny, jest dzie­łem programisty.
4. UML: dia­gram klas – model poję­cio­wy, to jedy­nie idea,
5. UML: dia­gram klas jako pro­jekt logi­ki i struk­tu­ry pro­gra­mu (zawie­ra atry­bu­ty i ope­ra­cje, tam gdzie to koniecz­ne, tak­że algo­ryt­my metod) oraz uzu­peł­nia­ją­ce go dia­gra­my maszy­ny sta­no­wej i sekwen­cji (obra­zu­ją szcze­gó­ło­wo jak opro­gra­mo­wa­nie ma dzia­łać) to już zapis ana­lo­gicz­ny do kodu pro­gra­mu, jest chro­nio­ny jako dzie­ło lite­rac­kie, ale kod jaki powsta­nie na tej posta­wie jest prak­tycz­nie w 100% jego odzwier­cie­dle­niem (wier­ne odzwier­cie­dle­nie sche­ma­tu blo­ko­we­go). Podlega ochro­nie jako dzie­ło lite­rac­kie oraz tak­że jako know-how. Program jaki powsta­nie na pod­sta­wie tak opra­co­wa­ne­go opi­su ma sta­tus tłu­ma­cze­nia (utwór zależny). 

Więc kod napi­sa­ny ​„pod dyk­tan­to” pro­jek­tan­ta nie jest nie­za­leż­nym dzie­łem pro­gra­mi­sty, nie ma on (pro­gra­mi­sta) pra­wa do swo­bod­ne­go dys­po­no­wa­nia takim kodem, podob­nie jak tłu­macz tek­stu nie naby­wa auto­ma­tycz­nie ani praw do dys­po­no­wa­nia tłu­ma­cze­niem, któ­re opra­co­wał, ani, w szcze­gól­no­ści, do tek­stu źró­dło­we­go, któ­ry przetłumaczył.

Zaprezentowana opi­nia praw­na, moim zda­niem pomi­ja więc waż­ny fakt, że poza języ­ka­mi pro­gra­mo­wa­nia ​„tek­sto­wy­mi”: taki­mi jak Java, Pascal czy .NET ist­nie­ją tak­że języ­ki gra­ficz­ne takie jak np. UML. Opinia powyż­sze (przy­to­czo­ny cytat) jest praw­dzi­wa pod warun­kiem, że mowa o powyż­szych dia­gra­mach na pozio­mie ogól­nym, idei. Jednak pro­jek­ty ozna­czo­ne kolo­rem czer­wo­nym to przy­pad­ki pod­le­ga­ją­ce już peł­nej ochronie.