Wprowadzenie

Bardzo czę­sto jestem pyta­ny o to jak się zabez­pie­czyć kupu­jąc lub zama­wia­jąc opro­gra­mo­wa­nie. Wielu praw­ni­ków zale­ca depo­zyt kodu źródłowego. 

Zdjęcie po pra­wej to przy­kła­do­wy frag­ment takie­go kodu. Kto zrozumiał? 

Często czy­tam:

„Depozyt kodu źró­dło­we­go (ang. sour­ce code escrow) jest jed­nym z naj­lep­szych środ­ków ochro­ny przed skut­ka­mi upa­dło­ści pro­du­cen­ta oprogramowania.”

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Niestety bywa to kosz­tow­ne i jest to bar­dzo złe roz­wią­za­nie, bo w zasa­dzie przed niczym nie zabez­pie­cza. Depozyt kodu źró­dło­we­go jest jed­ną naj­bar­dziej bez­war­to­ścio­wych metod ochro­ny. Dlaczego?

1. Są to tysią­ce lub set­ki tysię­cy linii kodu, nie raz bar­dzo niskiej jako­ści, napi­sa­ne­go nie­chluj­nie przez róż­nych ludzi (rota­cja prcow­ni­ków dewelopera).
2. Bywa że celo­wo utrzy­my­wa­na jest jego niska zro­zu­mia­łość (by utrud­nić innym jego zrozumienie).
3. Wiele apli­ka­cji nadal jest pisa­nych z uży­ciem rela­cyj­nych baz danych (set­ki połą­czo­nych tabel) i języ­ka SQL, więc wraz z tym kodem nale­ża­ło by mieć tak­że deta­licz­nie opi­sa­ną struk­tu­rę tych tabel i zapi­sa­ne (ich treść) wszyst­kie zapy­ta­nia SQL uży­te w tym kodzie, a tak­że deta­licz­ny opis śro­do­wi­ska tej bazy danych.

Zrozumienie mecha­ni­zmu dzia­ła­nia apli­ka­cji tyl­ko na bazie jej kodu źró­dło­we­go, struk­tu­ry tabel baz danych i zapy­tań SQL do tej bazy, gra­ni­czy z cudem i zaj­mu­je nie raz lata. To pomysł na pozio­mie tezy, że moż­na zro­zu­mieć jak dzia­ła samo­lot roz­bie­ra­jąc go na deta­le. W 2012 napi­sa­łem arty­kuł: Sprzedam Ci pra­wa do kodu czy­li wiel­ka ście­ma. Niedawno napi­sa­łem tekst: Mechanizm dzia­ła­nia vs model sys­te­mu vs dia­gram. Tu ich kon­ty­nu­acja w kon­tek­ście tego co nale­ży chro­nić mówiąc o kodzie źródłowym. 

Metoda

Standardowo sto­su­ję ide­ali­za­cję i mode­lo­wa­nie zarów­no w pra­cy nauko­wej ja i w pro­jek­tach komer­cyj­nych. Dlatego tu tak­że opi­szę model archi­tek­tu­ry sys­te­mu infor­ma­tycz­ne­go, jako ide­ali­za­cję takiej archi­tek­tu­ry, a potem posłu­gu­jąc sie nim, prze­te­stu­ję ideę depo­zy­tu kodu źródłowego.

Czym jest system i po co go mamy czyli co to jest komputer

Jest to klu­czo­we pyta­nie na jakie trze­ba sobie odpo­wie­dzieć. Popatrzmy:

Kluczowy fakt: my jako ludzie uży­wa­my kom­pu­te­ra a nie kodu źró­dło­we­go. To zna­czy, że sam kod źró­dło­wy to nie jest to, cze­go uży­wa­my. Kod źró­dło­wy to frag­ment ​„sys­te­mu”:

Patrząc na powyż­szy dia­gram łatwo zauwa­żyć, że sam kod źró­dło­wy, bez pozo­sta­łych ele­men­tów, jest w zasa­dzie bez­war­to­ścio­wy. Co z tego że mamy mitycz­ny kod źró­dło­wy, sko­ro może­my mieć poważ­ny pro­blem z pozy­ska­niem pozo­sta­łych ele­men­tów wyma­ga­nych do tego, by nasz Działający Komputer odtwo­rzyć? Czego tak na praw­dę uży­wa­my uży­wa­jąc kom­pu­te­ra? Używamy okre­ślo­ne­go mecha­ni­zmu prze­twa­rza­nia danych. Za Słownikiem Języka Polskiego: mecha­nizm to spo­sób, w jaki coś powsta­je, prze­bie­ga lub działa. 

Co więc tak na praw­dę nale­ży udo­ku­men­to­wać i chro­nić? Opis mecha­ni­zmu dzia­ła­nia nasze­go kom­pu­te­ra. Problem w tym, że mając wyłącz­nie kod źró­dło­wy jeste­śmy w trud­nej sytu­acji bo nadal zro­zu­mie­nie tego mecha­ni­zmu wyma­ga ​„inży­nie­rii wstecz­nej”, jedy­na róż­ni­ca to ta, że mate­ria­łem źró­dło­wych jest nie kod maszy­no­wy a kod w okre­ślo­nym języ­ku pro­gra­mo­wa­nia, co nie­ste­ty nie­wie­le popra­wia sytuację:

Kolejne klu­czo­we pyta­nie to: Co jest celem zaku­pu kom­pu­te­ra? Otóż celem jest ​„to do cze­go on nam słu­ży” a nie ​„on sam jako taki”.

Cała nasza dzia­łal­ność, do któ­rej uży­wa­my kom­pu­te­ra, to wpro­wa­dza­nie danych i uzy­ski­wa­ny efekt. Bardzo czę­sto kom­pu­ter to tak­że archi­wum histo­rii naszych ​„doko­nań” (przy oka­zji pro­sze zwró­cić uwa­gę na to, że obec­nie nie ma zna­cze­nia gdzie on fak­tycz­nie stoi bo liczy się komunikacja).

Co faktycznie należy chronić

Kolejne waż­ne pyta­nie: czy pro­duk­ty naszej pra­cy, nasz doro­bek, któ­ry powstał z uży­ciem tego kom­pu­te­ra, jest dla nas dostęp­ny bez Tego kom­pu­te­ra? Jeżeli nie, to brak tego kom­pu­te­ra nie tyl­ko powo­du­je, że nie mamy narzę­dzia pra­cy, to tak­że prze­pa­dek całe­go dorob­ku jaki powstał z jego pomo­cą. Jeżeli ten Komputer prze­cho­wu­je dane w posta­ci czy­tel­nej tyl­ko dla kodu Tego opro­gra­mo­wa­nia, to utra­ta Tego opro­gra­mo­wa­nia jest rów­no­znacz­na z utra­tą dotych­cza­so­we­go dorob­ku (np. naj­gor­szą for­mą archi­wi­zo­wa­nia danych jest rela­cyj­na baza danych i zapy­ta­nia SQL do niej, sytu­acja w jakiej jest więk­szość posia­da­czy sys­te­mów ERP). 

Komputer bez udo­ku­men­to­wa­ne­go mecha­ni­zmu dzia­ła­nia to dla nas wyłącz­nie ​„czar­na skrzyn­ka”. Wobec tego jak się zabez­pie­czyć, sko­ro depo­zyt kodu to zabez­pie­cze­nie fik­cyj­ne? Należy zabezpieczyć:

• nasz dotych­cza­so­wy doro­bek (sta­no­wią­ce naszą wła­sność archi­wum z doku­men­ta­mi w uni­wer­sal­nym for­ma­cie, łatwym do odczy­ta­nia, np. XML+PDF),
• mecha­nizm dzia­ła­nia (udo­ku­men­to­wa­ny np. w UML).

Poniżej ide­al­na bez­piecz­na archi­tek­tu­ra: mamy kom­pu­ter i mamy archi­wum oraz mamy ​„na boku” udo­ku­men­to­wa­ny mecha­nizm powsta­wa­nia (prze­twa­rza­nia) naszych danych. 

Innymi sło­wy: nie tyl­ko mamy archi­wum doku­men­tów, ale mamy tak­że wie­dzę jak one powsta­wa­ły, i może­my tej wie­dzy użyć do zbu­do­wa­nia kolej­ne­go ​„dzia­ła­ją­ce­go kom­pu­te­ra”, bez wzglę­du na to w jakiej tech­no­lo­gii zro­bi­my to kolej­nym razem. Dodam tu, że ochro­na know-how to nic inne­go jak posia­da­nie ww. udo­ku­men­to­wa­ne­go mecha­ni­zmu. Kod źró­dło­wy nie daje takiej ochrony.

Czym jest wie­dza o produkcie? 

Opis pro­duk­tu powi­nien przed­sta­wiać (ujaw­niać) go na tyle jasno i wyczer­pu­ją­co, aby znaw­ca mógł go urze­czy­wist­nić. Za ​„znaw­cę z danej dzie­dzi­ny” uwa­ża się prze­cięt­ne­go prak­ty­ka dys­po­nu­ją­ce­go prze­cięt­ną, ogól­nie dostęp­ną wie­dzą z danej dzie­dzi­ny w odpo­wied­nim cza­sie, któ­ry dys­po­nu­je typo­wy­mi środ­ka­mi i moż­li­wo­ścia­mi pro­wa­dze­nia prac. Przyjmuje się, że spe­cja­li­sta taki ma dostęp do sta­nu tech­ni­ki; tzn. infor­ma­cji zawar­tych w pod­ręcz­ni­kach, mono­gra­fiach, książ­kach. Zna tak­że infor­ma­cje zawar­te w opi­sach paten­to­wych i publi­ka­cjach nauko­wych, jeże­li jest to roz­wią­za­nie, któ­re jest na tyle nowe, że sto­sow­ne opi­sy nie są zawar­te w książ­kach. Ponadto, potra­fi korzy­stać ze sta­nu tech­ni­ki w dzia­łal­no­ści zawo­do­wej do roz­wią­zy­wa­nia pro­ble­mów tech­nicz­nych. Produkt powi­nien nada­wać się do odtwo­rze­nia (na pod­sta­wie doku­men­ta­cji) bez dodat­ko­wej twór­czo­ści wyna­laz­czej. Pod poję­ciem tym nale­ży rozu­mieć dodat­ko­wą dzia­łal­ność umy­sło­wą, eks­pe­ry­men­tal­ną zwią­za­ną z nie­peł­ną infor­ma­cją tech­nicz­ną zawar­tą w opi­sie pro­duk­tu, a tak­że koniecz­ność dodat­ko­wych uzu­peł­nia­ją­cych badań nauko­wych, nie­zbęd­nych do wytwo­rze­nia pro­duk­tu według tego opi­su. (na pod­sta­wie Pyrża, 2006)

Na bazie popraw­nie wyko­na­nej doku­men­ta­cji tech­nicz­nej (opis mecha­ni­zmu dzia­ła­nia, opis pro­duk­tu) moż­na apli­ka­cję odtwo­rzyć wie­lo­krot­nie niż­szym nakła­dem środ­ków w porów­na­niu z ana­li­zą cudze­go kodu źró­dło­we­go, któ­re­go dal­szy roz­wój w posta­ci i tech­no­lo­gii w jakiej pier­wot­nie powstał, nie raz może nie mieć sen­su (postęp tech­no­lo­gii w IT jest dość szybki).

Ważna rzecz na koniec tej części:

1. jeże­li opro­gra­mo­wa­nie jest dedy­ko­wa­ne to wła­ści­cie­lem i posia­da­czem praw mająt­ko­wych do kodu i wszel­kiej jego doku­men­ta­cji powi­nien być jego użytkownik,
2. jeże­li opro­gra­mo­wa­nie jest licen­cjo­no­wa­ne to użyt­kow­nik powi­nien znać mecha­nizm jego działania,
3. jeże­li ktoś uży­wa opro­gra­mo­wa­nia, któ­re­go dzia­nia nie rozu­mie, to może to mieć sens tyl­ko w przy­pad­kach gdy użyt­kow­nik wyma­ga wyłącz­nie efek­tu i nie musi rozu­mieć tego jak powstał: np. opro­gra­mo­wa­nie OCR czy retusz zdjęć.

Co radzą prawnicy

Co to jest depo­zyt kodu źródłowego ?

Depozyt kodu źró­dło­we­go (ang. sour­ce code escrow) jest jed­nym z naj­lep­szych środ­ków ochro­ny przed skut­ka­mi upa­dło­ści pro­du­cen­ta opro­gra­mo­wa­nia. W prak­ty­ce depo­zyt kodu źró­dło­we­go pole­ga na zło­że­niu przez Licencjodawcę / Deponenta (fir­mę pro­du­ku­ją­cą opro­gra­mo­wa­nie) kodów źró­dło­wych u depo­zy­ta­riu­sza (tzw agen­ta depo­zy­tu), przy rów­no­cze­snym upo­waż­nie­niu licen­cjo­bior­cy (kup­ca opro­gra­mo­wa­nia) do pobra­nia i dal­sze­go wyko­rzy­sta­nia kodów źró­dło­wych w okre­ślo­nych w umo­wie depo­zy­to­wej w przy­pad­kach, takich jak np. upa­dłość, wro­gie prze­ję­cie, likwi­da­cja pro­du­cen­ta opro­gra­mo­wa­nia, zaprze­sta­nie roz­wo­ju apli­ka­cji, zaprze­sta­nia świad­cze­nia usług ser­wi­so­wych i wspar­cia przez licencjodawcę.

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Podsumuję to tak:

1. jeże­li opro­gra­mo­wa­nie jest dedy­ko­wa­ne to wła­ści­cie­lem i posia­da­czem praw mająt­ko­wych do kodu i wszel­kiej jego doku­men­ta­cji powi­nien być jego użytkownik,
2. jeże­li opro­gra­mo­wa­nie jest licen­cjo­no­wa­ne, to użyt­kow­nik powi­nien znać mecha­nizm jego dzia­ła­nia, co pozwa­la w dowol­nym momen­cie kupić na ryn­ku ana­lo­gicz­ne, lub w skraj­nym przy­pad­ku zle­cić napisanie. 
3. jeże­li ktoś uży­wa opro­gra­mo­wa­nia, któ­re­go dzia­nia nie rozu­mie, to może to mieć sens tyl­ko w przy­pad­kach gdy użyt­kow­nik wyma­ga wyłącz­nie efek­tu i nie musi rozu­mieć tego jak powstał: np. opro­gra­mo­wa­nie OCR czy retusz zdjęć.

Podczas nego­cja­cji na temat kup­na opro­gra­mo­wa­nia w pew­nym momen­cie roz­waż­ny licen­cjo­bior­ca może zapy­tać: Co się sta­nie, jeśli dostaw­ca opro­gra­mo­wa­nia zakoń­czy swój biz­nes? Zazwyczaj nastę­pu­je żąda­nie dostę­pu do kodu źró­dło­we­go i wszel­kich innych kry­tycz­nych mate­ria­łów uży­wa­nych do utrzy­ma­nia oprogramowania.

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Co do zasa­dy: opro­gra­mo­wa­nie się licen­cjo­nu­je (brak jakich­kol­wiek praw do nie­go) lub zle­ca jego wyko­na­nie (wte­dy jest się jego wła­ści­cie­lem, tak­że kodu).

Umowa depo­zy­tu kodu źró­dło­we­go zna­na jest w Stanach Zjednoczonych od oko­ło 50 lat pod nazwą softwa­re escrow. Już wte­dy była wyko­rzy­sty­wa­na do zabez­pie­cze­nia opro­gra­mo­wa­nia two­rzo­ne­go przez wyspe­cja­li­zo­wa­ne fir­my z bran­ży IT. Na począt­ku XXI w. kon­struk­cja zaczę­ła upo­wszech­niać się w Europie, ale w Polsce dla wie­lu przed­się­bior­ców nadal sta­no­wi cał­ko­wi­cie obce zagad­nie­nie. Po co depo­no­wać kod źró­dło­wy i jak pra­wi­dło­wo skon­stru­ować taką umowę?

https://​rpms​.pl/​d​e​p​o​z​y​t​-​k​o​d​u​-​z​r​o​d​l​o​w​e​g​o​-​o​p​r​o​g​r​a​m​o​w​a​n​ia/

50 lat temu, mia­ło to sens bo cza­sy były takie, że opro­gra­mo­wa­nie to były rela­tyw­nie małe mono­li­ty, kodu było nie wie­le, a języ­ków pro­gra­mo­wa­nia kil­ka. Obecnie sto­pień zło­żo­no­ści opro­gra­mo­wa­nia oraz mno­gość tech­no­lo­gii powo­du­je, że kod z zasa­dy nie jest swo­ją dokumentacją. 

Kod źró­dło­wy to nic inne­go jak zbiór pole­ceń napi­sa­nych w okre­ślo­nym języ­ku pro­gra­mo­wa­nia, któ­re pozwa­la­ją zarzą­dzać zgro­ma­dzo­ny­mi i wpro­wa­dza­ny­mi dany­mi. Aby kod źró­dło­wy mógł dzia­łać, nie­zbęd­na jest jego kom­pi­la­cja, czy­li prze­kształ­ce­nie w kod wyni­ko­wy, któ­ry następ­nie może zostać zasto­so­wa­ny przez pro­ce­sor. Efekt takie­go dzia­ła­nia użyt­kow­nik widzi na moni­to­rze kom­pu­te­ra. Kod źró­dło­wy zazwy­czaj ma postać pli­ku tek­sto­we­go i jako taki może on zostać zapi­sa­ny na trwa­łym nośni­ku, np. pły­cie CD lub pamię­ci nie­ulot­nej typu FLASH.

https://​rpms​.pl/​d​e​p​o​z​y​t​-​k​o​d​u​-​z​r​o​d​l​o​w​e​g​o​-​o​p​r​o​g​r​a​m​o​w​a​n​ia/

I to jest praw­da, jed­nak pro­blem w tym, że kon­kret­ny kod, to jed­no z dzie­sią­tek moż­li­wych metod odwzo­ro­wa­nia mecha­ni­zmu prze­twa­rza­nia danych (co opi­sa­no wcze­śniej) i nie­ste­ty bar­dzo trud­ne do zro­zu­mie­nia przez oso­by inne niż autor twe­go kodu. 

Każdy dostaw­ca opro­gra­mo­wa­nia w nie­co inny spo­sób two­rzy doku­men­ta­cję software’u, dla­te­go war­to zadbać o to, aby w umo­wie były wymie­nio­ne wszyst­kie koniecz­ne ele­men­ty, któ­re znaj­dą się u depo­zy­ta­riu­sza. Co powin­no się wśród nich znaleźć?

- aktu­ali­zo­wa­na kar­ta wer­sji wraz ze wska­za­niem wszyst­kich wpro­wa­dzo­nych zmian,
- opis struk­tur kata­lo­gów kodów źró­dło­wych wraz ze wska­za­niem stan­dar­du nazew­nic­twa pli­ków źró­dło­wych i wyni­ko­wych,
dokład­ny opis pro­ce­du­ry kom­pi­la­cji,
- opis śro­do­wi­ska kom­pi­la­cyj­ne­go i zde­fi­nio­wa­ne biblio­te­ki pro­gra­mi­stycz­ne,
- doku­men­ta­cja tech­nicz­na baz danych wraz ze wska­za­niem nazw tabel i rela­cji mię­dzy nimi oraz poda­niem ewen­tu­al­nych atry­bu­tów,
- narzę­dzia do przy­go­to­wa­nia wer­sji insta­la­cyj­nej, czy­li takiej, któ­ra będzie się nada­wa­ła do wgra­nia na twar­dy dysk oraz do samej insta­la­cji.
W ten spo­sób licen­cjo­bior­ca ma gwa­ran­cję, że po zwol­nie­niu kodu będzie dys­po­no­wał wszyst­ki­mi narzę­dzia­mi, za pomo­cą któ­rych samo­dziel­nie obsłu­ży otrzy­ma­ny kod źródłowy.

https://​rpms​.pl/​d​e​p​o​z​y​t​-​k​o​d​u​-​z​r​o​d​l​o​w​e​g​o​-​o​p​r​o​g​r​a​m​o​w​a​n​ia/

Niestety nie ma żad­nej gwa­ran­cji, gdyż narzę­dzia kom­pi­la­cji, w tym ich wer­sje, mogą być nie­do­stęp­ne na ryn­ku, i nadal pozo­sta­je kwe­stia tego, że nabyw­ca ​„nie wie jak to dzia­ła” bo dla nie­go kod źró­dło­wy jest nie­zro­zu­mia­ły, a zle­ce­nie inne­mu dewe­lo­pe­ro­wi two­rzy kon­flikt inte­re­su i bar­dzo duże koszty. 

Podsumowanie

Więc jak? Użytkownik oprogramowania:

1. albo licen­cjo­nu­je od dostaw­cy opro­gra­mo­wa­nie stan­dar­do­we i nie kasto­mi­zu­je go, tu wyma­ga­nie kodu źró­dło­we­go jest kurio­zal­ne, a sytu­ację ​„awa­ryj­ną” leczy zakup ana­lo­gicz­ne­go, stan­dar­do­we­go opro­gra­mo­wa­nia od inne­go pro­du­cen­ta (Finanse i księ­go­wość, itp.).
2. albo posia­da pra­wa mająt­ko­we do doku­men­ta­cji i opro­gra­mo­wa­nia wyko­na­ne­go spe­cjal­nie dla nie­go, i fir­ma – dewe­lo­per – któ­ra to wyko­na­ła nie ma nic do gadania.

Każda inna for­ma to szu­ka­nie kło­po­tów. Więcej o kasto­mi­za­cji i dla­cze­go jest ona poważ­nym błę­dem: Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i reko­men­da­cje. Samodzielne, ponow­ne, po kil­ku latach, uru­cho­mie­nie ​„sta­re­go” kodu źró­dło­we­go gra­ni­czy z cudem.

Nie jest też moż­li­we by jakaś jed­na apli­ka­cja obsłu­ży­ła cała fir­mę. Nie ma cze­goś takie­go jak ​„jed­na wspól­na baza danych” jako ​„jed­no źró­dło praw­dy”, bo dane są zawsze kon­tek­sto­we. Dlatego sys­tem IT to raczej kil­ka tema­tycz­nych źró­deł praw­dy (dzie­dzi­no­we opro­gra­mo­wa­nie zin­te­gro­wa­ne w jeden sys­tem), a nie jed­no cen­tral­ne. Wielkie wdro­że­nia kasto­mi­zo­wa­nych (nie­udo­ku­men­to­wa­ne kasto­mi­za­cje) mono­li­tów ERP koń­czą sią zawsze porażką.

Jak udo­ku­men­to­wać opro­gra­mo­wa­nie: Analiza Biznesowa i Opis Techniczny Oprogramowania – moja rola w pro­jek­cie.

P.S.

Przykład. W powyż­szy spo­sób opra­co­wa­łem i udo­ku­men­to­wa­łem logi­kę dzia­ła­nia sys­te­mu Generator Ofert dla Kancelarii Senatu. Jest to opro­gra­mo­wa­nie obsłu­gu­ją­ce dofi­nan­so­wa­nie pro­jek­tów dla polo­nii na całym świe­cie: od nabo­ru wnio­sków, przez ich pro­ce­so­wa­nie, zatwier­dza­nie, pod­pi­sy­wa­nie umów aż do roz­li­cze­nia. Aplikacja dwa razy zmie­nia­ła fir­mę, któ­ra obsłu­gi­wa­ła jej utrzy­ma­nie i roz­wój, póź­niej zosta­ła prze­pi­sa­na w nowej tech­no­lo­gii w toku przej­ścia z chmu­ry na hosting dedy­ko­wa­ny. Dzięki temu, że zasto­so­wa­no doku­men­to­wy model danych, migra­cja do nowej wer­sji odby­ła prak­tycz­nie bez kosztowo.

Czarny humor na zakończenie

Poniższy mem jest dość popu­lar­ny w sieci:

Jego para­fra­za:

Koder: Tylko kod źró­dło­wy jest doku­men­ta­cją oprogramowania.

Użytkownik: To opro­gra­mo­wa­nie nie dzia­ła popraw­nie, gdzie jest opis popraw­ne­go (ocze­ki­wa­ne­go) dzia­ła­nia tego programu?

Koder: Opisem jest ten kod źródłowy….

(autor mema nie znany)

Źródła