Od cza­su do cza­su mie­wam dys­ku­sje na temat tego, kto i co powi­nien wytwo­rzyć w pro­jek­cie dostar­cza­nia opro­gra­mo­wa­nia. Pojawia się pro­blem: czym jest ów pro­jekt. Po dru­gie: kto jest auto­rem i cze­go. Po trze­cie: czym jest ta doku­men­ta­cja. Problem w tym, że w pro­jek­tach IT w wyni­ku ana­liz powsta­ją ​„jakieś wyma­ga­nia” i tak na praw­dę nie wia­do­mo czym one są… Dziwne? Czym jest pro­dukt, któ­re­go ​„cechą funk­cjo­nal­ną jest moż­li­wość wbi­ja­nia gwoź­dzi”? Otoczakiem, pneu­ma­tycz­nym mło­tem czy może pro­stym ręcz­nym młot­kiem? Co wygra prze­targ gdzie kry­te­rium będzie cena w 100%? Otoczak?

Po co two­rzy­my doku­men­ta­cję wymagań?

Mój kole­ga praw­nik ostat­nio, w pro­stych sło­wach, dał odpo­wiedź: ​„doku­men­ta­cja jest po to by w sądzie wia­do­mo było czy przed­miot umo­wy został wyko­na­ny zgod­nie z tre­ścią umo­wy”. Nie muszą chy­ba doda­wać, że doku­men­ta­cja tu, to opis przed­mio­tu umo­wy (albo jak kto woli, Opis Przedmiotu Zamówienia zwa­ny OPZ, czy­li opis dzie­ła jakie nale­ży dostar­czyć), załącz­nik do umo­wy na wyko­na­nie i dostar­cze­nie cze­goś (tu opro­gra­mo­wa­nia). Dlatego zawsze uwa­żam, że pro­jekt z zakre­su inży­nie­rii opro­gra­mo­wa­nia (i nie tyl­ko, chy­ba każ­dy tego typu) powi­nien mieć dwie części:

1. umo­wa na projektowanie
2. umo­wa na reali­za­cje projektu

Obie umo­wy bazu­ją na kodek­sie cywil­nym (umo­wa o dzie­ło) i na pra­wie autor­skim (pro­jekt to utwór i pro­gram to utwór). Opracowanie opi­su tego co ma powstać, powin­no być po stro­nie zama­wia­ją­ce­go opro­gra­mo­wa­nie (naj­czę­ściej zle­ca się to tak zwa­ne­mu ana­li­ty­ko­wi wyma­gań). Projekt (pra­wa do nie­go) pozo­sta­je wte­dy w rękach zama­wia­ją­ce­go, więc pozor­nie jego know-how nie zosta­nie prze­ję­te przez (poten­cjal­nie) nie­uczci­we­go wyko­naw­cę i dostaw­cę opro­gra­mo­wa­nia.

Z dru­giej stro­ny w kulu­arach kon­fe­ren­cji nie raz sły­szę, że nie­któ­re fir­my świa­do­mie szu­ka­ją dostaw­cy, któ­ry zna ich bran­że (czy­taj kon­ku­ren­cje) z nadzie­ją, że wraz z usłu­gą lub sys­te­mem ERP, przej­mą choć część know-how jed­ne­go ze swo­ich kon­ku­ren­tów (źr.Audyt orga­ni­za­cji czy ana­li­za?).

Niestety auto­rem opro­gra­mo­wa­nia jest wyko­naw­ca i ma pra­wo dys­po­no­wa­nia tym opro­gra­mo­wa­nie (to on udzie­la na opro­gra­mo­wa­nie licen­cji zama­wia­ją­ce­mu). Nie musi mieć praw, innych niż pra­wo korzy­sta­nia z egzem­pla­rza (załącz­nik do umo­wy na wyko­na­nie), do opi­su na pod­sta­wie, któ­re­go opro­gra­mo­wa­nie powsta­ło. Jest tu na szczę­ście pew­ne ​„ale”, wię­cej o tym w dal­szej części.

Teraz chy­ba jasno widać ​„Po co two­rzy się doku­men­ta­cję pro­jek­tu IT?” Czy doku­men­ta­cja taka (jaka, co zawie­ra) chro­ni przed prze­ję­ciem wie­dzy biz­ne­so­wej przez wyko­naw­cę opro­gra­mo­wa­nia? Po dru­gie sło­wo ​„doku­men­ta­cja”, bez okre­śle­nia co jest jej przed­mio­tem, nic nie zna­czy. Dlatego piszę tu o doku­men­ta­cji w rozu­mie­niu ​„opis tego co ma powstać”.

Byłem świad­kiem lub uczest­ni­kiem wie­lu dys­ku­sji o pra­wach do pro­duk­tu jakim jest opro­gra­mo­wa­nie. Dyskusje były burz­li­we, dostaw­cy opro­gra­mo­wa­nia bro­nią jak lwy tezy, że są jego posia­da­cza­mi w 100% bo wyma­ga­nia nie są dzie­łem ani pro­jek­tem. Otóż wyma­ga­nia są dzie­łem, tyle że lite­rac­kim, podob­nie zresz­tą jak i oprogramowanie.

Zgodnie więc z pra­wem, zarów­no sam pro­gram jak i doku­ment ana­li­zy, na bazie któ­re­go ono powsta­ło, to rów­no­praw­ne dzie­ła lite­rac­kie w rozu­mie­niu [[Ustawy o Prawie Autorskim i Prawach pokrew­nych]]. Są chro­nio­ne tyl­ko jako treść. Jednak ​„treść” w wypad­ku pro­gra­mu to nic inne­go jak pro­gram. W czym pro­blem? W tym, że autor opro­gra­mo­wa­nia sta­je się posia­da­czem i dys­po­nen­tem wie­dzy, jaką pozy­skał i zawarł w opro­gra­mo­wa­niu w trak­cie two­rze­nia tego opro­gra­mo­wa­nia. Dlaczego? Bo ta wie­dza była koniecz­na do powsta­nia opro­gra­mo­wa­nia a auto­rem opi­su wyma­gań, tre­ści ana­li­zy wyma­gań, pro­jek­tu, i w koń­cu opro­gra­mo­wa­nia, jest naj­czę­ściej wła­śnie wyko­naw­ca opro­gra­mo­wa­nia. Skoro jest auto­rem, jest tak­że posia­da­czem praw do nie­go (autor­skich i mająt­ko­wych). Wytworzony pro­gram zawie­ra logi­kę biz­ne­so­wą zama­wia­ją­ce­go i jej posia­da­czem oraz dys­po­nen­tem cało­ści jest wyko­naw­ca opro­gra­mo­wa­nia, jeże­li był tak­że wyko­naw­cą i auto­rem doku­men­tu opi­su­ją­ce­go wymagania.

Czy moż­na temu zaradzić?

Tak. Przedmiotem ochro­ny praw­nej może być algo­rytm, tu szcze­gó­ło­wy opis logi­ki biz­ne­so­wej imple­men­to­wa­nej w opro­gra­mo­wa­niu. Jeżeli taki opis powsta­nie, w wyczer­pu­ją­cy i jed­no­znacz­ny spo­sób opi­su­ją­cy nie tyl­ko co, ale tak­że jak pro­gram ma to robić, wyko­naw­ca two­rząc opro­gra­mo­wa­nie na bazie takie­go opi­su, two­rzy utwór zależ­ny i nie ma praw do dys­po­no­wa­nia opro­gra­mo­wa­niem, któ­re wytwo­rzył bez zgo­dy zama­wia­ją­ce­go (posia­da­cza praw mająt­ko­wych do opi­su tej logi­ki). Dlaczego? Bo to Zamawiający ma pra­wa autor­skie mająt­ko­we do opi­su logi­ki biz­ne­so­wej zaim­ple­men­to­wa­nej w pro­gra­mie. Twórca opro­gra­mo­wa­nia (pro­gra­mi­sta) wyko­nał imple­men­ta­cje ale w tym wypad­ku nie jest auto­rem ​„algo­ryt­mu” i nie może dys­po­no­wać swo­bod­nie wytwo­rzo­nym tak opro­gra­mo­wa­niem, o ile oczy­wi­ście zama­wia­ją­cy nie prze­ka­zał mu praw do same­go algorytmu.

Jak to zro­bić? Opracować wyma­ga­nia, ale nie w posta­ci typo­wej spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych, bo ta nie nie­sie w sobie żad­ne­go algo­ryt­mu. Modele przy­pad­ków uży­cia to tak­że tyl­ko funk­cjo­nal­no­ści sys­te­mu, zgod­nie z UML, przy­pad­ki uży­cia to opis tak zwa­nej ​„czar­nej skrzyn­ki”. Potrzebny jest tu opis tak zwa­nej ​„bia­łej skrzyn­ki”, czy­li doku­ment zawie­ra­ją­cy szcze­gó­ło­wy opis tego jak reali­zo­wa­ne są poszcze­gól­ne cechy (funk­cjo­nal­no­ści) sys­te­mu. Innymi sło­wy, opis doku­men­tu­ją­cy dane jakie mają być prze­twa­rza­ne i szcze­gó­ło­wy opis tego prze­twa­rza­nia. W zasa­dzie jest to pro­jekt tego opro­gra­mo­wa­nia (w meto­dy­ce MDA nazy­wa się to model sys­te­mu PIM czy­li [[Platform Independent Model]], powi­nien go poprze­dzać model CIM czy­li [[Computation Independent Model]]). Taka doku­men­ta­cja nie pozo­sta­wia wąt­pli­wo­ści, któ­ry doku­ment co zawie­ra. Model PIM to wła­śnie owa bia­ła skrzyn­ka. Model PSM to już dzie­ło wyko­naw­cy ale w tym przy­pad­ku jest to utwór zależ­ny (powsta­ło na bazie PIM) i wyko­naw­ca bez zgo­dy auto­ra mode­lu PIM nie może swo­bod­nie dys­po­no­wać opro­gra­mo­wa­niem jakie wytworzył.

Ale pły­ną wnio­ski z tych dys­ku­sji z fir­ma­mi programistycznymi:

• ana­li­za biz­ne­so­wa daje jako pro­dukt opis (model) fir­my, jest to nie­ja­ko pro­dukt audy­tu orga­ni­za­cji, stwier­dze­nie sta­nu fak­tycz­ne­go i nie ma tu mowy o pra­wach do cze­go­kol­wiek poza dzie­łem lite­rac­kim jakim jest treść, w tym model CIM, takiej ana­li­zy (umo­wa o dzie­ło), moż­na i nale­ży taki doku­ment jed­nak potrak­to­wać i chro­nić jed­no­cze­śnie jako tajem­ni­cę przed­się­bior­stwa na mocy USTAWY z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji oraz jako dzie­ło na mocy USTAWY z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych, dodat­ko­wo war­to sko­rzy­stać z art. 72 prim Kodeksu Cywilnego (Art.72 prim, par.1. Jeżeli w toku nego­cja­cji stro­na udo­stęp­ni­ła infor­ma­cje z zastrze­że­niem pouf­no­ści, dru­ga stro­na jest obo­wią­za­na do nie­ujaw­nia­nia i nie­prze­ka­zy­wa­nia ich innym oso­bom oraz do nie­wy­ko­rzy­sty­wa­nia tych infor­ma­cji dla wła­snych celów), jed­nak tu nadal chro­ni­my tyl­ko infor­ma­cje źró­dło­we, wystar­cza­ją­co dokład­nie opi­sa­ne sta­no­wią jed­nak utrud­nie­nie han­dlem efek­ta­mi ich wykorzystania.
• pro­jekt opro­gra­mo­wa­nia (model PIM, kom­plet­ny pro­jekt imple­men­ta­cji logi­ki biz­ne­so­wej np. w UML) to utwór (zawie­ra algo­ryt­my), któ­ry wyma­ga udzie­le­nia licen­cji wyko­naw­cy opro­gra­mo­wa­nia na uży­cie go do wytwo­rze­nia opro­gra­mo­wa­nia, któ­re sta­je się tym samym dzie­łem zależ­nym (pra­wo autor­skie) i dostaw­ca (pro­gra­mi­sta) nie może tym pro­gra­mem dalej han­dlo­wać bez zgo­dy zama­wia­ją­ce­go; waru­nek: pro­jek­tant nie może być pra­cow­ni­kiem pro­gra­mi­sty, pra­wa do pro­jek­tu muszą być po stro­nie zama­wia­ją­ce­go oprogramowanie,

Generalnie war­to umie­ścić wszyst­kie te ele­men­ty w umo­wie na dostar­cze­nie opro­gra­mo­wa­nia. W przy­pad­ku umo­wy z ana­li­ty­kiem zale­cam pierw­szy punkt. Produkt ana­li­ty­ka (podob­nie jak dedy­ko­wa­ny pro­dukt biu­ra archi­tek­ta budow­la­ne­go) powi­nien w cało­ści przejść na wła­sność zama­wia­ją­ce­go, w koń­cu opi­su­je dokład­nie jego firmę.

Na zakoń­cze­nie

Jak ustrzec się przed wynie­sie­niem z fir­my tajem­ni­cy jej funk­cjo­no­wa­nia, two­rzo­nej lata­mi orga­ni­za­cji, pro­ce­dur i pro­ce­sów, reguł biz­ne­so­wych? Jak zatrzy­mać w fir­mie wie­dzę mino zama­wia­nia opro­gra­mo­wa­nia, któ­re siła rze­czy ja zawiera?

Problem nie jest pro­sty. Sami praw­ni­cy nie są mię­dzy sobą zgod­ni co do tego, gdzie leży gra­ni­ca pomię­dzy utwo­rem lite­rac­kim a szcze­gó­ło­wym opi­sem roz­wią­za­nia. Wydaje się, że klu­czem jest to spo­sób two­rze­nia opi­su tego co ma powstać. Standardem w IT jest opis wyma­gań, ten jed­nak z urzę­du czy­ni auto­ra opro­gra­mo­wa­nia tak­że posia­da­czem opi­su logi­ki w nim zawar­tej, bo on jest auto­rem jej opisu.

Wyjściem wyda­je się zawar­cie w umo­wie nie opi­su wyma­gań na opro­gra­mo­wa­nie a pro­jek­tu opro­gra­mo­wa­nia. Metodą zde­fi­nio­wa­nia gra­ni­cy, za któ­rą mamy nie utwór lite­rac­ki (spe­cy­fi­ka­cje wyma­gań) a pro­jekt wraz z algo­ryt­ma­mi, jest meto­dy­ka MDA. Wtedy fir­ma reali­zu­ją­ca zamó­wio­ne opro­gra­mo­wa­nie two­rzy utwór zależ­ny a zama­wia­ją­cy nie tra­ci pano­wa­nia nad tak powsta­łym pro­duk­tem. Jest to sytu­acja jaką zna­my w bran­ży budow­la­nej: deve­lo­per dosta­je pro­jekt archi­tek­to­nicz­ny, i sam fakt, że posta­wił na jego pod­sta­wie obiekt nie daje mu żad­nych praw do nie­go, gdyż wystar­cza­ją­co szcze­gó­ło­wy pro­jekt obiek­tu pozo­sta­je dzie­łem pro­jek­tan­ta a nie jego wyko­naw­cy. Wielu dostaw­ców opro­gra­mo­wa­nia, z oczy­wi­stych powo­dów, negu­je to, że ​„nie będą posia­da­czem wszel­kich praw do wytwo­rzo­ne­go przez sie­bie opro­gra­mo­wa­nia”, ale tu nie­ste­ty mogą nie mieć racji.

Jednak zawsze, bo nie ma zło­tej regu­ły, wyma­ga to kon­sul­ta­cji i szcze­gó­ło­we­go okre­śle­nia zawar­to­ści doku­men­ta­cji, któ­ra ma stać się ​„opi­sem przed­mio­tu zamówienia”.

Jakie mogą być skut­ki takich zanie­dbań? Np. prze­tar­gi z wol­nej ręki (czy­li unie­moż­li­wia­nie kon­ku­ren­cji lub jak kto woli ven­dor-lock czy­li uza­leż­nia­nie klien­tów od sie­bie a czym trosz­kę tu (Urzędnikom i usta­wo­daw­cy zawdzię­cza­my utra­tę 100 mln euro), wię­cej tu: http://​pppit​.org​.pl/​?​a​=98). Polecam też lek­tu­rę opracowania:

brak prze­nie­sie­nia autor­skich praw mająt­ko­wych do opro­gra­mo­wa­nia i/lub brak zapew­nie­nia dostę­pu do kodu źró­dło­we­go roz­wią­za­nia infor­ma­tycz­ne­go i nale­ży­cie opra­co­wa­nej doku­men­ta­cji. (źr. Analiza ryn­ku zamó­wień publicz­nych na narzę­dzia infor­ma­tycz­ne w okre­sie od 1 stycz­nia do 30 czerw­ca 2011 r..)

Z innej stro­ny temat poru­szy­łem tak­że tu:

W kulu­arach kon­fe­ren­cji nie raz sły­szę, że nie­któ­re fir­my świa­do­mie szu­ka­ją dostaw­cy, któ­ry zna ich bran­że (czy­taj kon­ku­ren­cje) z nadzie­ją, że wraz z usłu­gą lub sys­te­mem ERP, przej­mą choć część know-how jed­ne­go ze swo­ich kon­ku­ren­tów (źr. Audyt orga­ni­za­cji czy ana­li­za?).

P.S.

Pewien lider na ryn­ku dostaw­ców sys­te­mów ERP, ma zapis w umo­wie mówią­cy, że przej­mu­je pra­wa autor­skie do cało­ści pomy­słów i kodu (funk­cjo­nal­no­ści) jaki powsta­nie pod­czas prac z klien­tem nad dosto­so­wa­niem dostar­cza­ne­go sys­te­mu ERP (czy­li tak zwa­na kasto­mi­za­cja). Czyli know-how zama­wia­ją­ce­go idzie do kon­ku­ren­cji – fir­ma ta chwa­li się na ryn­ku, że ma refe­ren­cyj­ne bran­żo­we rozwiązania ?

Byli bar­dzo zasko­cze­ni (i wście­kli) gdy dowie­dzie­li się, że zgod­nie z umo­wą ana­li­zę i pro­jekt imple­men­ta­cji (model PIM) nowych funk­cjo­nal­no­ści, któ­rych nie ma ich ERP robię ja. Ich tłu­ma­cze­nie, że tyl­ko oni maja wie­dzę by to robić bo to ich ERP było nie do obro­ny: poka­za­łem im opis ich wła­sne­go sys­te­mu, jego meto­dy­ki wdro­że­nia i infor­ma­cję, że jest wyko­na­ny zna­nym narzę­dziem obiek­to­wym i w zna­nej tech­no­lo­gii, i że pro­jekt jaki ode mnie dosta­ną będzie wystar­cza­ją­cy i pra­wi­dło­wy by go zaim­ple­men­to­wać w tym ERP. Niestety, tu nie prze­ję­li wie­dzy i pomy­słów zama­wia­ją­ce­go. Tak się da zro­bić, trze­ba nie dać się szan­ta­żo­wać swo­je­mu wła­sne­mu dostawcy. 

To dla­te­go dostaw­cy Ci (nie tyl­ko ERP i inne goto­we sys­te­my, tak­że fir­my two­rzą­ce opro­gra­mo­wa­nie dedy­ko­wa­ne) zro­bią wszyst­ko, by zasta­na u klien­ta ana­li­za poszła do kosza i naci­ska­ją na to, by ana­li­zę wyma­gań (przed­wdro­że­nio­wą) powta­rzać ręka­mi ich pra­cow­ni­ków. Nie praw­dą jest, że ana­li­zę wyma­gań może popraw­nie zro­bić wyłącz­nie dostaw­ca opro­gra­mo­wa­nia. Dostawca goto­we­go sys­te­mu ma wyko­nać ana­li­zą pokry­cia wyma­gań przez dostar­cza­ne przez sie­bie opro­gra­mo­wa­nie (opi­sa­na tu kie­dyś ana­li­za gap/fit). Deweloperzy dostaw­cy spo­koj­nie mogą wyko­nać imple­men­ta­cję wyma­ga­nych nowych funk­cjo­nal­no­ści na bazie popraw­ne­go pro­jek­tu. Problem mają w tym, że wte­dy nie mogą go przejąć.

Tu o róż­ni­cy pomię­dzy ana­li­zą biz­ne­so­wą a przed­wdroż­nio­wą: https://it-consulting.pl//index.php/2011/01/21/analiza-przedwdrozeniowa-%E2%80%93-czym-jest/

P.S. 2

Niezależnie od powyż­sze­go zale­cam kon­sul­ta­cje z praw­ni­kiem w celu usta­le­nia sta­nu praw­ne­go na dzień zawar­cia umowy.

Składam tak­że spe­cjal­ne podzię­ko­wa­nia Piotrowi Waglowskiemu, pro­wa­dzą­ce­mu świet­ny, praw­ni­czy blog VaGla​.pl Prawo i Internet za przej­rze­nie tego arty­ku­łu i cen­ne wskazówki.

P.S. 3, 29 Listopad 2011, zapa­da orze­cze­nie potwier­dza­ją­ce powyższe:

Court of Justice of the European Union, PRESS RELEASE No 129/11, Luxembourg, 29 November 2011, Press and Information Advocate General?s Opinion in Case C‑406/10, SAS Institute Inc. v World Programming Ltd

1. The sour­ce code, which under­lies a com­pu­ter pro­gram, is writ­ten by the pro­gram­mer. That code, com­po­sed of words, is intel­li­gi­ble to the human mind. However, it is not exe­cu­ta­ble by the com­pu­ter. To beco­me so, it needs to be com­pi­led so that it can be trans­la­ted into bina­ry-form com­pu­ter lan­gu­age, usu­al­ly the figu­res 0 and 1. This is known as the object code.
2. Council Directive of 14 May 1991 on the legal pro­tec­tion of com­pu­ter pro­grams (OJ 1991 L 122, p. 42).
3. Amongst other things, pre­pa­ra­to­ry design work, whe­re it leads to the cre­ation of a pro­gram, is also pro­tec­ted by copy­ri­ght appli­ca­ble to com­pu­ter pro­grams. That design work can inc­lu­de, for exam­ple, a struc­tu­re or orga­ni­sa­tio­nal chart deve­lo­ped by the pro­gram­mer which is lia­ble to be re-trans­cri­bed in sour­ce code and object code, thus ena­bling the machi­ne to exe­cu­te the com­pu­ter pro­gram. That orga­ni­sa­tio­nal chart deve­lo­ped by the pro­gram­mer could be com­pa­red to the sce­na­rio of a film (see the Opinion in Case C‑393/09).

Link: http://​curia​.euro​pa​.eu/​j​c​m​s​/​u​p​l​o​a​d​/​d​o​c​s​/​a​p​p​l​i​c​a​t​i​o​n​/​p​d​f​/​2​011 – 11/cp110129en.pdf