Powyższy tytuł to ory­gi­nal­ny tytuł jed­ne­go z cyto­wa­nych poni­żej arty­ku­łów. Wybrałem go, bo obra­zu­je pewien pro­blem na ryn­ku IT (ale nie tyl­ko na tym ryn­ku). Ten pro­blem to wła­śnie tak zwa­ne ​„życze­nio­we myśle­nie”. Dotyczy ono zarów­no ocze­ki­wań jak i zobo­wią­zań, tak dostaw­ców jak i nabyw­ców opro­gra­mo­wa­nia. Celowo nie piszę usłu­go­daw­ców IT, bo zna­ko­mi­ta więk­szość tak zwa­nych ​„pro­jek­tów IT” ma za cel tyl­ko to, by nabyw­ca zyskał opro­gra­mo­wa­nie, któ­re­go uży­je jako narzę­dzia w pro­wa­dzo­nej przez sie­bie dzia­łal­no­ści. To czy kupi goto­we i wdro­ży, czy zle­ci jego stwo­rze­nie dla sie­bie, czy też wydzier­ża­wi, ma zna­cze­nie dru­go­rzęd­ne, róż­ni­ca jest tyl­ko w ryzy­ku takie­go projektu. 

teza, że dewe­lo­per to gru­pa eks­per­tów, ludzi dobrej woli, któ­rym wszyst­ko się uda­je bo obie­ca­li, to nie­ste­ty myśle­nie życzeniowe… 

Wprowadzenie

Wszelkie pro­jek­ty w obsza­rze inży­nie­rii są zwią­za­ne z pro­jek­to­wa­niem. Powstają pro­jek­ty roz­wią­zań, potem zaś owe roz­wią­za­nia. Interdysplinarność inży­nie­rii (mało co dzi­siaj skła­da sie tyl­ko z jed­ne­go mate­ria­łu i wyko­na­ne jest z uży­ciem jed­nej tyl­ko tech­no­lo­gii) powo­du­je, że mówi­my raczej o sys­te­mach (sys­tem, mecha­tro­ni­ka) niż o urzą­dze­niach czy przed­mio­tach jak kie­dyś. Jednak inży­nie­ria opro­gra­mo­wa­nia wyróż­nia się w pew­nym aspek­cie na tle innych: jej pro­duk­ty są nie­ma­te­rial­ne. W kon­se­kwen­cji są one dla więk­szo­ści ludzi, z poza tej bran­ży, nie­mie­rzal­ne i nie­zro­zu­mia­łe, a ich wytwa­rza­nie jest rela­tyw­nie łatwe, bo nie wyma­ga żad­nych mate­rial­nych (mie­rzal­nych dla innych ludzi) surow­ców. Zaryzykuje tezę, że kom­pu­ter i opro­gra­mo­wa­nie dla wie­lu ludzi to wręcz magia. Konsekwencją tego jest to, że wie­le umów zawie­ra­nych jest na dostar­cze­nie cze­goś, cze­go nikt nie rozu­mie, a już kupu­ją­cy na pew­no ;), z cze­go skrzęt­nie nie raz korzy­sta­ją dostaw­cy opro­gra­mo­wa­nia. Doskonale ilu­stru­je to zna­ne w bran­ży IT powiedzenie:

?Klient ma rację do momen­tu pod­pi­sa­nia umo­wy wdro­że­nio­wej. Po jej pod­pi­sa­niu ? racja jest wyłącz­nie po stro­nie dostawcy?

(tu pole­cam poprzed­ni arty­kuł: Zamawiający jest zawsze win­ny swo­jej poraż­ki.

Dlaczego to robisz? Bo mogę.

Tak w skró­cie moż­na opi­sać i zamknąć temat dostaw­ców opro­gra­mo­wa­nia i pro­ble­mów z tym zwią­za­nych. Prawdę mówiąc ja nie spo­tka­łem się nigdy z sytu­acją, by sądo­wy spór o jakość dostar­czo­ne­go opro­gra­mo­wa­nia prze­grał (i zwró­cił pie­nia­dze) dostaw­ca reali­zu­ją­cy pro­jekt T&M (czy­li agile).

Pamiętacie baj­kę o żabie i skor­pio­nie? Za chwi­lę się oka­że jaki ma zwią­zek z IT. Nad brze­giem rze­ki spo­tka­ła się żaba i skor­pion. Oboje chcie­li prze­do­stać się na dru­gą stro­nę. Żaba oby­ta ze śro­do­wi­skiem wod­nym nie mia­ła żad­nych obaw. Gorzej ze skor­pio­nem, nie potra­fił prze­miesz­czać się w wodzie. Postanowił prze­ko­nać żabę, aby mu pomo­gła i prze­pły­nę­ła z nim na grze­bie­cie. Żaba w pierw­szym odru­chu odmó­wi­ła. Obawiała się, że skor­pion ją uką­si swo­im śmier­cio­no­śnym żądłem w cza­sie tej prze­pra­wy. ((1) ZASKAKUJĄCE ODKRYCIE: WISHFUL THINKING RZĄDZI W IT | LinkedIn)

Popatrzmy na to co opi­su­je autor­ka tek­stu. Cały arty­kuł jasno poka­zu­je, że (IT) ​„robią co chcą i to bez­kar­nie”. Dlaczego? Moim zda­niem z pro­ste­go powo­du: bo mogą. Dlaczego mogą? Bo im klient pozwala!

Negocjacje to cie­ka­wy etap pro­jek­tów IT: dwie stro­ny dys­ku­tu­ją o czymś o czym tak na praw­dę nie mają poję­cia, bo kupu­ją­cy nie rozu­mie czym jest pro­ces two­rze­nia opro­gra­mo­wa­nia a dostaw­ca opro­gra­mo­wa­nia, w dniu pod­pi­sa­nia umo­wy, nie wie co ma robić opro­gra­mo­wa­nie. Dlaczego? No bo nie ist­nie­je opis przed­mio­tu zamó­wie­nia. Umowy w rodza­ju ​„będzie­my się bar­dzo sta­ra­li i bie­rze­my XXX zł za godzi­nę pro­gra­mi­sty” nie zawie­ra­ją ani celu a nie opi­su tego co powsta­nie. Tezy jako­by celem pro­gra­mi­stów był suk­ces ich klien­ta mozna wło­żyć mię­dzy baj­ki, co wyka­za­ła autor­ka cyto­wa­ne­go tekstu.

Dostawca ma dobre refe­ren­cje i jest dłu­go na ryn­ku, więc to się musi udać. Nic bar­dziej myl­ne­go. Jeden z wie­lu fak­tów oba­la­ją­cych tę tezę opi­sa­łem w tek­ście Porażka za 2 mld zł. Lidl wyco­fu­je się z wdro­że­nia SAP. Więcej argu­men­tów w rapor­cie Chaos Report .

Płacę wiec dosta­nę to cze­go chcę. Owszem, ale pyta­nie brzmi czy to będzie ​„to cze­go potrze­bu­jesz”? To tak­że dokład­nie opi­sa­łem w nie­daw­nym tek­ście o winie zama­wia­ją­ce­go.

To moje opro­gra­mo­wa­nie i mogę z nim zro­bić co chcę. W przy­pad­ku tak zwa­nych war­to­ści nie­ma­te­rial­nych, prze­świad­cze­nie że coś ​„jest moje” może być bar­dzo trud­ne do wyka­za­nia, a nie raz jest po pro­stu ułu­dą. Więcej w dal­szej części. 

Autorka bar­dzo dobrze opi­sa­ła fak­ty, z jaki­mi się spo­ty­ka. Tu obo­je mamy prak­tycz­nie iden­tycz­ne doświad­cze­nie (a jak to mówią: gdy dwóch mówi to samo to już nie jest to samo). Pozostaje jed­nak kwe­stia praw autor­skich i tego co tak na praw­dę jest tu przed­mio­tem pra­wa autor­skie­go i co fak­tycz­nie jest dzie­łem w tych umowach. 

A kto tu coś w ogóle tworzy?

Tego typu tek­sty pra­wie zawsze zaczy­nam od usta­wo­wej defi­ni­cji poję­cia utwór :

Przedmiot pra­wa autorskiego

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).
2. W szcze­gól­no­ści przed­mio­tem pra­wa autor­skie­go są utwo­ry:
1) wyra­żo­ne sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi
(lite­rac­kie, publi­cy­stycz­ne, nauko­we, kar­to­gra­ficz­ne oraz pro­gra­my
kom­pu­te­ro­we);
2) pla­stycz­ne;
3) foto­gra­ficz­ne;
4) lut­ni­cze;
5) wzor­nic­twa prze­my­sło­we­go;
6) archi­tek­to­nicz­ne, archi­tek­to­nicz­no-urba­ni­stycz­ne i urbanistyczne;

Kluczem jest sfor­mu­ło­wa­nie ​„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” a może być np. ​„wyra­żo­ne sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi”. Generalnie jaka­kol­wiek przy­dat­ność do cze­go­kol­wiek nie ma tu żad­ne­go zna­cze­nia. Ma zna­cze­nie uni­kal­ność i fakt utrwa­le­nia (usta­le­nie). Kolejna rzecz: kon­se­kwen­cją jest jed­nak to, że pra­ca ​„pod dyk­tan­do” nie jest dzia­łal­no­ścią twór­czą, gdyż ta z zasa­dy nie jest pra­cą samo­dziel­ną. Jeżeli dopusz­cza­my tu (albo jest to celem) pew­ną samo­dziel­ność, to powsta­je tak zwa­ne utwór zależ­ny (ta sama ustawa): 

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 pier­wot­ne­go.
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 opra­co­wa­nia.
3. Twórca utwo­ru pier­wot­ne­go może cof­nąć zezwo­le­nie, jeże­li w cią­gu pię­ciu lat od jego udzie­le­nia opra­co­wa­nie nie zosta­ło roz­po­wszech­nio­ne. Wypłacone twór­cy wyna­gro­dze­nie nie pod­le­ga zwro­to­wi.
4. Za opra­co­wa­nie nie uwa­ża się utwo­ru, któ­ry powstał w wyni­ku inspi­ra­cji cudzym utwo­rem.
5. Na egzem­pla­rzach opra­co­wa­nia nale­ży wymie­nić twór­cę i tytuł utwo­ru pierwotnego.

Kluczem są tu pkt. 2. i 5. mówią­ce, że autor dzie­ła pier­wot­ne­go zacho­wu­je peł­nie kon­tro­li nad dzie­łem zależ­nym. Tu pierw­sza waż­na kon­klu­zja, nie raz opi­sy­wa­na na moim blo­gu: jeże­li opro­gra­mo­wa­nie powsta­je na bazie ogól­ne­go opi­su funk­cjo­nal­no­ści, jest ono samo­dziel­nym utwo­rem inspi­ro­wa­nym. Jeżeli jed­nak opro­gra­mo­wa­nie powsta­nie ​„pod dyk­tan­do” pro­jek­tu tech­nicz­ne­go (jest on z zasa­dy samo­dziel­nym utwo­rem), wyra­żo­ne­go za pomo­cą wzo­rów mate­ma­tycz­nych, algo­ryt­mów i sche­ma­tów blo­ko­wych, to jest ono (to opro­gra­mo­wa­nie) dzie­łem zależ­nym, podob­nie jak tłu­ma­cze­nie książ­ki z inne­go języ­ka czy dom zbu­do­wa­ny na pod­sta­wie pro­jek­tu archi­tek­to­nicz­ne­go. Pewna burzę w sie­ci wywo­łał pra­wo­moc­ny wyrok z 2017 roku: 

Sąd Najwyższy uznał, że jed­no­ra­zo­we wyko­na­nie kon­cer­tu przez skrzy­pacz­kę, któ­ra nie była solist­ką, obję­te jest umo­wą zle­ce­nia, a nie umo­wą o dzie­ło. Nawet jeśli wyko­na­nie było arty­stycz­ne. Nakazał od takiej umo­wy odpro­wa­dzić skład­ki na ubez­pie­cze­nie spo­łecz­ne. Przedmiotem umo­wy było przy­go­to­wa­nie i wyko­na­nie cudze­go utwo­ru. Czytaj: WSA: twór­cy na eta­cie trze­ba wyod­ręb­nić autor­skie wyna­gro­dze­nie (źr.: Wykonanie kon­cer­tu nie zawsze jest dzie­łem).

Pełne uza­sad­nie­nie sądu zawie­ra tak­że opis mecha­ni­zmu kwa­li­fi­ka­cji tego co jest utwo­rem i jakim, któ­ry wyżej opisałem. 

Niestety dostaw­cy opro­gra­mo­wa­nia czę­sto wyko­rzy­stu­ją nie­wie­dzę swo­ich klien­tów (i ich praw­ni­ków tak­że). Standardem są tak­że zale­ce­nia jakie deve­lo­pe­rzy dają swo­im klien­tom: pro­szę nie zle­cać niko­mu ana­li­zy, my sami ją wyko­na­my za dar­mo. W kon­se­kwen­cji dostaw­ca opro­gra­mo­wa­nia, pod dyk­tan­do swo­je­go klien­ta (agi­le itp.) naj­pierw two­rzy dość ogól­ną listę wyma­gań (to ta dar­mo­wa ana­li­za), a potem two­rzy opro­gra­mo­wa­nie. Klient dostar­czył wszyst­kich nie­zbęd­nych infor­ma­cji o sobie i swo­ich potrze­bach, pokrył 100% wszyst­kich kosz­tów (i mar­żę) powsta­nia tego opro­gra­mo­wa­nia (słyn­ne i mitycz­ne zara­zem men­dej­sy) i na koniec sły­szy, że ma jesz­cze dodat­ko­wo zapła­cić za pra­wa mająt­ko­we do tego kodu, jeże­li chce nim dys­po­no­wać. Brzmi to dokład­nie tak samo, jak sta­ra aneg­do­ta o kon­sul­tan­cie, któ­ry na pyta­nie swo­je­go klien­ta: ​„Która jest godzi­na”, pro­si klien­ta o jego zega­rek, odpo­wia­da na pyta­nie Która godzi­na, i doda­je, że odda mu zega­rek ale wraz z płat­ną licen­cją na jego dal­sze uży­wa­nie. Więcej o tym napi­sa­łem mię­dzy inny­mi w 2012 roku w tek­ście Sprzedam Ci pra­wa do kodu czy­li wiel­ka ście­ma.

Drugim, jesz­cze bar­dziej nie­uczci­wym zapi­sem w umo­wach, jest ten mówią­cy, że ​„wszel­kie war­to­ści inte­lek­tu­al­ne, jakie powsta­ną w toku reali­za­cji pro­jek­tu, prze­cho­dzą na wła­sność dostawcy/wykonawcy opro­gra­mo­wa­nia”. W obu przy­pad­kach jest to ordy­nar­na kra­dzież know-how. 

Body leasing czyli co?

Wynajem pro­gra­mi­stów, czy ogól­nie ​„spe­cja­li­stów IT”, to kolej­ny pro­blem w obsza­rze praw autor­skich. Pojęcie pra­wa autor­skie­go i sfor­mu­ło­wa­nie tego co kon­kret­nie jest przed­mio­tem pra­cy (świad­czo­nej usłu­gi) szcze­gól­nie tu wyma­ga precyzji.

Programistę moż­na zatrud­nić (wyna­jąć) na umo­wę o dzie­ło, wte­dy w tej bran­ży naj­praw­do­po­dob­niej będzie ono (dzie­ło) utwo­rem w rozu­mie­niu Ustawy. Można tak­że na umo­wę zle­ce­nie, i wte­dy już nie koniecz­nie. Specyfikę róż­ni­cy mię­dzy reali­za­cją usłu­gi jako umo­wy sta­ran­ne­go dzia­ła­nia a umo­wy efek­tu, opi­sa­łem w tek­ście Kto winien poraż­ki pro­jek­tu?

Na czym pole­ga wyna­jem pro­gra­mi­sty? Poniższy dia­gram, poka­zu­je model takiej usługi:

Kluczem jest tu jest sfor­mu­ło­wa­nie przed­mio­tu umo­wy. Umowa na pośred­nic­two jest pro­sta: pośred­nik bie­rze pro­wi­zje za pośred­nic­two w zaan­ga­żo­wa­niu (wyna­jem) np. pro­gra­mi­sty. Współpraca ma miej­sce pomię­dzy Zleceniodawcą a Wynajmowanym do pra­cy pro­gra­mi­stą. To ich współ­pra­ca pro­wa­dzi do powsta­nia opro­gra­mo­wa­nia. Niewątpliwie powsta­nie tu utwór. Kto i jakie ma do nie­go pra­wa? I tu poja­wia sie słyn­ne ​„to zale­ży”. Od cze­go? W 100% od tre­ści komu­ni­ka­cji w toku współ­pra­cy, pomię­dzy Zleceniodawcą a Wynajętym programistą. 

Jeżeli pro­gra­mi­sta dosta­je szcze­gó­ło­we instruk­cje (pro­jekt) co ma ​„zako­do­wać”, wte­dy spra­wa jest pro­sta: roz­li­cze­nie jest godzi­no­we (zle­ce­nie czy­li umo­wa sta­ran­ne­go dzia­ła­nia) i jest on wyłącz­nie ​„dobrym rze­mieśl­ni­kiem” (pole­cam lite­ra­tu­rę na temat softwa­re cra­ft­sman­ship). Autorskie pra­wa mająt­ko­we i oso­bi­ste ma twór­ca pro­jek­tu czy­li szcze­gó­ło­wych instruk­cji dla pro­gra­mi­sty (podob­nie jak na budo­wie: pra­wa autor­skie mająt­ko­we i oso­bi­ste do pro­jek­tu budow­li zacho­wu­je archi­tekt a nie wyko­naw­ca inwe­sty­cji). Programista albo nie ma żad­nych praw do tego co ​„napi­sał pod dyk­tan­do”, albo jest twór­cą dzie­ła zależ­ne­go (co może tu mieć miejsce). 

Jeżeli pro­gra­mi­sta dosta­je ogól­ne infor­ma­cje i sam roz­wią­zu­je pro­ble­my, sta­je się tak­że pro­jek­tan­tem, jest on więc auto­rem utwo­ru pier­wot­ne­go, któ­ry stwo­rzył (tu ma miej­sce pier­wot­ne usta­le­nie utwo­ru). Tak więc koniecz­ne jest (o ile chce tego Zleceniodawca), prze­nie­sie­nie praw mająt­ko­wych do kodu wraz z pra­wem zle­ca­nia two­rze­nia dzieł zależ­nych (bez tego roz­wój opro­gra­mo­wa­nia może być nie­moż­li­wy, migra­cja do innej tech­no­lo­gii na pew­no nie będzie moż­li­wa, war­to tu jed­nak zwró­cić uwa­gę na to, że pra­wa do kodu mogą być bez­war­to­ścio­we, jeże­li jest on nie­udo­ku­men­to­wa­ny lub niskiej jakości). 

Tak więc sam fakt ​„wyna­ję­cia” pro­gra­mi­sty abso­lut­nie nie rodzi kon­se­kwen­cji w posta­ci powsta­nia obo­wiąz­ku zby­cia praw mająt­ko­wych do pro­duk­tu pra­cy tego programisty:

Jak wyja­śnił Sąd Apelacyjny w Krakowie w wyro­ku z dnia 22 lute­go 2017 r. (I ACa 1061/16) przed­mio­tem umo­wy body leasing w IT jest wyko­na­nie usług out­so­ur­cin­gu kadro­we­go pra­cow­ni­ków pole­ga­ją­cych na udo­stęp­nie­niu pra­cow­ni­ków będą­cych wykwa­li­fi­ko­wa­ny­mi infor­ma­ty­ka­mi ? pro­gra­mi­sta­mi w spo­sób i na warun­kach prze­wi­dzia­nych tą umo­wą.
W związ­ku z powyż­szym, w oce­nie Sądu, nie ma zatem żad­nych pod­staw do przy­ję­cia, że umo­wy taka jest umo­wą na wyko­na­nie dzie­ła w posta­ci wytwo­rze­nia okre­ślo­ne­go opro­gra­mo­wa­nia. Dalej Sąd wyja­śnił, że przed­się­bior­ca dele­gu­ją­cy pra­cow­ni­ków do inne­go przed­się­bior­cy w związ­ku z wyko­na­niem umo­wy leasin­gu pra­cow­ni­cze­go nie jest odpo­wie­dzial­ny za rezul­tat świad­czo­nych przez te oso­by usług, w szcze­gól­no­ści powsta­nie i funk­cjo­no­wa­nie pro­gra­mu komputerowego.

(źr. https://​pra​wo​dla​biz​ne​su​.eu/​i​t​/​b​o​d​y​-​l​e​a​s​i​n​g​-​w​-​it/)

Moim zda­niem naj­lep­szym roz­wią­za­niem pro­ble­mu praw autor­skich, jest dodat­ko­wa (opcjo­nal­na) odręb­na umo­wa pomię­dzy Zleceniodawcą a Programistą, na prze­nie­sie­nie praw mająt­ko­wych, w ramach wyna­gro­dze­nia jakie ten otrzy­mu­je. Wariant, w któ­rym w prze­ka­za­niu praw mająt­ko­wych mię­dzy Zleceniodawcą a Programistą pośred­ni­czył­by Pośrednik, jest bar­dzo skom­pli­ko­wa­ny i z tego powo­du chy­ba najgorszy.

W przy­pad­ku takiej umo­wy (prze­nie­sie­nie praw mająt­ko­wych do kodu) poja­wia się jed­nak dodat­ko­wy pro­blem autor­skich praw oso­bi­stych: są one nie­zby­wal­ne. Bardzo rze­czo­wo opi­su­je to autor­ka tego tekstu:

Tego typu klau­zu­le sto­su­je­my bar­dzo czę­sto w przy­pad­ku prze­no­sze­nia praw do utwo­rów two­rzo­nych na zamó­wie­nie, lub prze­zna­czo­nych do przy­pi­sa­nia innej oso­bie już na eta­pie jego two­rze­nia. Klauzula pouf­no­ści W przy­pad­ku usta­le­nia przez stro­ny, że twór­ca zobo­wią­zu­je się do nie­wy­ko­ny­wa­nia autor­skich praw oso­bi­stych jed­no­cze­śnie zawie­ra się posta­no­wie­nia doty­czą­ce pouf­no­ści. Mogą mieć one cha­rak­ter dodat­ko­wej umo­wy, lub sta­no­wić część umo­wy o prze­nie­sie­nie praw autor­skich. Takie umo­wy czę­sto okre­śla się skró­to­wo NDA lub CDA od angiel­skich nazw umów o zacho­wa­nie pouf­no­ści. Obowiązek zacho­wa­nia tajem­ni­cy rów­nież naj­czę­ściej zabez­pie­cza się wyso­ką karą umow­ną. W efek­cie twór­ca otrzy­mu­je wyna­gro­dze­nie, ale zobo­wią­zu­je się to nie­wy­ko­ny­wa­nia autor­skich praw oso­bi­stych oraz jed­no­cze­śnie zacho­wa­nia peł­nej tajem­ni­cy. Dotyczy ona zarów­no tego co stwo­rzył jak i dla kogo, kto nabył pra­wa mająt­ko­we itd. Nie może więc pochwa­lić się swo­im dorob­kiem przed przy­szły­mi klien­ta­mi, nie rośnie też jego reno­ma. (źr. Zobowiązanie do nie­wy­ko­ny­wa­nia praw autor­skich – Legalni Twórcy).

Pozostaje tu jedy­nie moral­na oce­na takich klauzul/umów (zrze­ka­nie się wyko­ny­wa­nia autor­skich praw oso­bi­stych). I mamy tu dwa aspek­ty: wymu­sza­nie takich zapi­sów na auto­rach gdy zle­ce­nio­daw­ca ma prze­wa­gę nego­cja­cyj­ną (masz tę robo­tę albo nie masz), oraz świa­do­ma zgo­da na pod­szy­wa­nie się innych ludzi pod wła­sną pra­cę, czy­li świa­do­me okła­my­wa­nie innych co do tego kto tak na praw­de ​„to wymy­ślił”. I ten wątek, ety­ki, pozo­sta­wię czy­tel­ni­kom, bo jest to indy­wi­du­al­na spra­wa każ­de­go z nas. W moim ​„Regulaminie świad­cze­nia usług” prze­czy­ta­cie, że ​„nie zrze­kam się wyko­ny­wa­nia autor­skich praw oso­bi­stych”. O umo­wach o pouf­no­ści wię­cej pisa­łem w tek­ście Czy umo­wy o pouf­no­ści mają sens.

Kwestie umów o zaka­zie kon­ku­ren­cji są tu tak­że wąt­pli­we, gdyż umo­wa taka wyma­ga wska­za­nie rodza­ju ​„zaka­za­nych” prac na rzecz dane­go pod­mio­tu, bo nie mozna komuś zaka­zać ​„jakiej­kol­wiek pra­cy” na rzecz kogoś. Zakaz kon­ku­ren­cji na wyso­kich sta­no­wi­skach mene­dżer­skich jest dość powszech­ny i doty­czy umów o pra­cę lub kon­trak­tów mene­dżer­skich. Jego sku­tecz­ne egze­kwo­wa­nie jest jed­nak bar­dzo wąt­pli­we (podob­nie jak umo­wy NDA), gdyż nie da się sku­tecz­nie zaka­zać ludziom jakich­kol­wiek kon­tak­tów (oczy­wi­ście pozo­sta­je jak zawsze kwe­stia uczci­wo­ści, ale tej nie da sie egze­kwo­wać umową).

Na zakończenie

Wielu praw­ni­ków, nie zna i nie rozu­mie bran­ży inży­nier­skiej (pro­jek­to­wa­nie itp.) mimo, że wie­le lat poma­ga w tego typu umo­wach. Większość zna­nych mi praw­ni­ków z zasa­dy uzna­je pisa­nie opro­gra­mo­wa­nia za twór­czość, co nie zawsze jest praw­dą. Jestem pro­jek­tan­tem opro­gra­mo­wa­nia, w 100% przy­pad­ków pro­gra­mi­ści w moich pro­jek­tach albo po pro­stu piszą imple­men­ta­cję (to pra­ca rze­mieśl­ni­cza pod dyk­tan­do, pro­gra­mi­sta nie ma tu żad­nej swo­bo­dy, a więc nie powsta­je żad­ne JEGO dzie­ło o indy­wi­du­al­nym cha­rak­te­rze). Jeżeli pro­gra­mi­sta fak­tycz­nie autor­sko roz­wią­zu­je jakieś pro­ble­my tech­no­lo­gicz­ne, wte­dy two­rzy tak zwa­ny utwór zależ­ny (podob­nie jak tłu­macz tłu­ma­czą­cy cudzą książkę).

Nie pla­no­wa­łem tu wykła­du z ety­ki biz­ne­su, jed­nak uwa­żam, że ety­ka jest waż­na. Zainteresowanym niu­an­sa­mi umów sta­ran­ne­go dzia­ła­nia i o dzie­ło pole­cam opra­co­wa­nie: Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu .

Na koniec w kwe­stii zło­żo­no­ści i życze­nio­we­go myśle­nia pole­cam tak­że opra­co­wa­nie: BOILING FROGS? Technology orga­ni­sa­tions need to chan­ge radi­cal­ly to survi­ve incre­asing tech­ni­cal and busi­ness disrup­tion. .

Etyka jest czymś co wymy­ka się pra­wu: jest jedy­nie dobra wolą. Oczywistym jest, że jest ona waż­na, tak­że w biz­ne­sie, jed­nak to tyl­ko dobra wola. Budowanie mode­lu biz­ne­so­we­go na dobrej woli jest nie­wąt­pli­wie szczyt­ne, ale życie uczy że tak­że bar­dzo ryzy­kow­ne. Możliwe jest wyro­bie­nie sobie dobrej mar­ki i zaufa­nia na ryn­ku, ale trwa to dłu­go. Taką mar­kę może sobie np. wyro­bić pośred­nik, ale ocze­ki­wa­nie, że rze­sze przy­pad­ko­wych klien­tów pośred­ni­ka zawsze zacho­wa­ją ety­kę jest nie­ste­ty wyso­ce naiwne. 

Tak więc teza, że dewe­lo­per to gru­pa ludzi dobrej woli, któ­rym wszyst­ko się uda­je w myśl zasa­dy chcieć to móc, to nie­ste­ty fak­tycz­nie myśle­nie życze­nio­we. Wiara w ety­kę wszyst­kich na ryn­ku, także. 

Źródła