Podobno każ­dy lubi zupę pomi­do­ro­wą. Podobno każ­dy potra­fi odróż­nić dobrą pomi­do­rów­kę od innych zup. Podobno każ­dy od cza­su do cza­su ma ocho­tę na pomi­do­rów­kę. Bardzo wie­le osób potra­fi jakoś tam opi­sać jaka ta pomi­do­rów­ka powin­na być: lek­ko kwa­sko­wa­ta i pikant­na, kon­sy­sten­cja tłu­ste­go roso­łu, wyraź­ny smak pomi­do­rów, poda­na z ryżem, maka­ro­nem lub łazan­ka­mi, raczej gorą­ca. I teraz naj­waż­niej­sze: jakie zna­cze­nie dla samej pomi­do­rów­ki ma to czy: zamó­wi­my ją w restau­ra­cji, zamó­wi­my z dosta­wą do domu czy sami zro­bi­my? W kwe­stii samej pomi­do­rów­ki nie ma to żad­ne­go zna­cze­nia. Do roz­wa­że­nia jest tyl­ko to czy potra­fi­my ją sami ugo­to­wać, czy mamy na to czas, czy mamy budżet na gotow­ca z dosta­wą do domu czy może mamy czas i budżet na wizy­tę w dobrej restau­ra­cji. Jednak gene­ral­nie jest to cały czas ta sama pomi­do­rów­ka (na razie pomi­jam pecha ze złym kucha­rzem ale tu jeste­śmy trosz­kę bezbronni).

Wniosek jest jeden: na samym począt­ku i dłu­go jesz­cze, a cza­sem nigdy, nie ma żad­ne­go zna­cze­nia czy ta pomi­do­rów­ka będzie robio­na dla nas czy nala­na z wiel­kie­go gara: opi­su­jąc ją będzie to zawsze taki sam opis. Po pro­stu raz jest taniej a raz dro­żej, raz szyb­ciej a raz trze­ba pocze­kać. Wiemy dla­cze­go, i nie zale­ży to od opi­su pomi­do­rów­ki, bo zawsze jej smak jest taki sam.

Umowy

Od lat spo­ty­kam się w tej (IT) bran­ży z, cza­sa­mi bar­dzo kurio­zal­ny­mi, kon­struk­cja­mi praw­ny­mi ​„przed­mio­tu umo­wy” w umo­wach jakie ser­wu­ją moim klien­tom dostaw­cy opro­gra­mo­wa­nia. Postanowiłem jed­nak nie komen­to­wać tu tych umów, posta­no­wi­łem napi­sać ​„instruk­cję” wraz z uza­sad­nie­niem. Bo oka­zu­je się, że pra­wie nikt nie ma pro­ble­mu z pomi­do­rów­ką ale wie­lu ma pro­blem z opro­gra­mo­wa­niem, któ­re się w pew­nych kwe­stiach niczym od pomi­do­rów­ki nie różni.

Na począ­tek jed­nak sche­mat blo­ko­wy, na któ­rym zobra­zu­je­my nasz przed­miot dywagacji.

Opis dia­gra­mu

Aplikacja jest opi­sa­na w doku­men­cie Specyfikacja opro­gra­mo­wa­nia, jest reali­za­cją tej Specyfikacji. Dokument ten zawie­ra opis tego, czym jest Aplikacja, czy­li to jakie usłu­gi świad­czy ona użyt­kow­ni­kom i innym (zewnętrz­nym) apli­ka­cjom. Każdy byt zewnętrz­ny w sto­sun­ku do Aplikacji jest na tym dia­gra­mie akto­rem. Byt korzy­sta­ją­cy bez­po­śred­nio z usług Aplikacji, jest akto­rem TEJ Aplikacji. GUI ozna­cza, że Użytkownik to czło­wiek korzy­sta­ją­cy z niej za pośred­nic­twem ​„inter­fej­su użyt­kow­ni­ka”. API ozna­cza, że Aplikacja_3 korzy­sta z usług Aplikacji (jest zin­te­gro­wa­na) za pośred­nic­twem inter­fej­su pro­gra­mi­stycz­ne­go. Aplikacja jest uza­leż­nio­na od Interesariusza 2, podob­nie jak Aplikacja 1. Działanie Aplikacji (opro­gra­mo­wa­nia) jest uza­leż­nio­ne od dostę­pu do Aplikacji 1 i Aplikacji 2 (i nie świad­czy im żad­nych usług ze swo­jej stro­ny). Interesariusz 2 i Interesariusz 4 są ze sobą zwią­za­ni Umową. Specyfikacja opro­gra­mo­wa­nia, podob­nie jak Kod pro­gra­mu, ma trwa­ły zwią­zek z Umową.

Specyfikacja opro­gra­mo­wa­nia to doku­ment zawie­ra­ją­cy jed­no­znacz­ny opis zacho­wa­nia się Aplikacji i mecha­nizm jej dzia­ła­nia. W tym miej­scu infor­ma­cja dla praw­ni­ków: taki opis jest moż­li­wy do wyko­na­nia, podob­nie jak moż­li­wy jest do wyko­na­nia opis maszy­ny do szy­cia czy wago­nu kole­jo­we­go. Specyfikacja ta – jej treść – nie zale­ży w jakim­kol­wiek stop­niu od tego, kto jest jej wła­ści­cie­lem i użyt­kow­ni­kiem (od akto­rów na tym dia­gra­mie), nie zale­ży tak­że od tre­ści Umowy.

Kod pro­gra­mu to tekst nio­są­cy okre­ślo­ną treść, sta­no­wią­cy wraz z nośni­kiem, mate­rial­ny byt ana­lo­gicz­nie jak np. książ­ka czy obraz.

Na dia­gra­mie poka­za­no róż­ne, wyżej opi­sa­ne, związ­ki (nie nazwa­ne, ich nazwy zale­żą od kon­kret­nej sytu­acji) pomię­dzy ele­men­ta­mi dia­gra­mu. Pomogą nam one w dal­szej części.

Prawny status ​„oprogramowania”

W prze­strze­ni publicz­nej toczą się spo­ry co do tego ​„czym jest opro­gra­mo­wa­nie”, jed­nak moim zda­niem, więk­szość tych spo­rów ma swo­je źró­dła w nie­zro­zu­mie­niu spe­cy­fi­ki tech­no­lo­gii infor­ma­tycz­nych i same­go pra­wa, część jest skut­kiem celo­we­go lub nie, mata­cze­nia w samych umowach.

Ustawodawca, moim zda­niem bar­dzo słusz­nie, zakwa­li­fi­ko­wał opro­gra­mo­wa­nie do utwo­rów lite­rac­kich, gdyż w swej isto­cie jest ono zawsze zapi­sem ana­lo­gicz­nym do tek­stu. Osobną kwe­stią jest treść tkwią­ca w takim utwo­rze (o czym on jest), co podob­nie jak w przy­pad­ku lite­rac­kich tek­stów, może mieć ale nie musi, zna­cze­nie. Tekst Kodu pro­gra­mu zin­ter­pre­to­wa­na przez odpo­wied­nią maszy­nę, potocz­nie zwa­ną kom­pu­te­rem, decy­du­je o tym ​„czym dany kom­pu­ter jest”. Raz jest pro­gra­ma­to­rem pral­ki a raz edy­to­rem tek­stu czy grą inte­rak­tyw­ną. Oprogramowanie czę­sto cechu­je się okre­ślo­nym ​„mecha­ni­zmem dzia­ła­nia”. W lite­ra­tu­rze z obsza­ru tech­nik kom­pu­te­ro­wych i filo­zo­fii, bar­dzo czę­sto moż­na spo­tkać teo­rię mówią­cą, że ​„kom­pu­ter to uni­wer­sal­ny mecha­nizm”. Innymi sło­wy kom­pu­ter może być ​„czym­kol­wiek”, decy­du­je o tym ​„pro­gram kom­pu­te­ro­wy”. Podam przykład.

Zegar to przy­rząd wska­zu­ją­cy aktu­al­ną godzi­nę. Chyba każ­dy czy­ta­ją­cy ten tekst spo­tkał się w swo­im życiu z wie­lo­ma wer­sja­mi tego przy­rzą­du. To co obser­wu­je­my na swo­ich nad­garst­kach czy ścia­nach miesz­kań (i dwor­ców kole­jo­wych) to kon­kret­ne zega­ry (mecha­nicz­ne, cyfro­we, itp.). Mimo wie­lu ich odmian i kon­struk­cji, zawsze słu­żą do tego same­go celu: wska­zu­ją aktu­al­ną godzi­ną (pomi­ja tu te uszko­dzo­ne). Zawsze też mają ten sam mecha­nizm dzia­ła­nia. Poniżej mamy dia­gram opi­su­ją­cy mecha­nizm dzia­ła­nia zega­ra. 

Celowo nie opi­su­ję deta­licz­nie tego dia­gra­mu, zakła­dam, że jest ​„oczy­wi­sty” (poza pew­ny­mi deta­la­mi uży­tej nota­cji). Diagram ten nale­ża­ło­by uzu­peł­nić regu­ła­mi, np. tą że wska­za­nia minut zeru­ją się zawsze po 59 sekun­dzie. Zestaw takich reguł, uzu­peł­nio­ny opi­sem (jest jego ele­men­tem) to ​„mecha­ni­zmu dzia­ła­nia zegara”.

Jak nie­trud­no się prze­ko­nać, wyko­nań (imple­men­ta­cji) tego mecha­ni­zmu jest na świe­cie ogrom, część z nich to wła­śnie kom­pu­ter i ​„pro­gram reali­zu­ją­cy mecha­nizm zega­ra”. Wersji takie­go pro­gra­mu (tek­stu decy­du­ją­ce­go o tym jak zacho­wa się kom­pu­ter) tak­że może być ogrom. Tak więc pro­gram jako treść (utwór lite­rac­ki) speł­nia defi­ni­cję usta­wo­wą utwo­ru. W swej tre­ści może zawie­rać opis mecha­ni­zmu przed­sta­wio­ne­go na powyż­szym dia­gra­mie, zakła­dam, że nikt z czy­ta­ją­cych nie ma wąt­pli­wo­ści, że kon­kret­na treść pro­gra­mu i kon­kret­ny uży­ty kom­pu­ter, to inwen­cja twór­cza ​„auto­ra pro­gra­mu”, nie zmie­nia to fak­tu, że pro­gra­my te będą reali­zo­wa­ły mecha­nizm opi­sa­ny w powyż­szej Specyfikacji opro­gra­mo­wa­nia, Kod pro­gra­mu będzie tu dzie­łem zależ­nym (autor Kodu pro­gra­mu nie jest auto­rem Specyfikacji opro­gra­mo­wa­nia, opra­co­wał swój utwór jako reali­za­cję tej spe­cy­fi­ka­cji). Zarówno Kod pro­gra­mu jak i Specyfikacja są utwo­ra­mi (tak­że w rozu­mie­niu usta­wy). Poniżej uży­te poję­cia i zależ­no­ści mię­dzy nimi:

Z jakimi umowami mamy do czynienia?

Podmioty zobra­zo­wa­ne jako Interesariusz 2 i Interesariusz 4 zawie­ra­ją Umowę, przed­mio­tem umo­wy mogą być usłu­gi, war­to­ści nie­ma­te­rial­ne i produkty.

Najczęściej spo­ty­ka­ną sytu­acją jest tak zwa­ny ​„zakup opro­gra­mo­wa­nia”, a kon­kret­nie jest to jego licen­cjo­no­wa­nie i jed­no­ra­zo­wa opła­ta z tego tytu­łu. Interesariusz 4 jest posia­da­czem praw mająt­ko­wych do Aplikacji. Kupując np. grę kom­pu­te­ro­wą lub pro­gram do wysta­wia­nia fak­tur, fak­tycz­nie mamy nastę­pu­ją­cą sytu­ację: pod­miot kupu­ją­cy (Interesariusz 2) zawie­ra z posia­da­czem praw mająt­ko­wych (Interesariusz 4) Umowę licen­cyj­ną pozwa­la­ją­cą mu na korzy­sta­nie z Aplikacji. Użytkownik korzy­sta z Aplikacji (jest np. pra­cow­ni­kiem Interesariusza 2, lub Interesariusz 2 i Użytkownik to ta sama oso­ba fizyczna).

Umowa może zawie­rać zapi­sy o prze­nie­sie­niu praw mająt­ko­wych z Interesariusza 4 na Interesarusza 2. Integralną czę­ścią takiej Umowy, załącz­ni­kiem do niej, jest Kod pro­gra­mu (jego egzem­plarz na nośni­ku). Aplikacja może posia­dać swo­ją Specyfikację. Przeniesienie praw mająt­ko­wych do Kodu pro­gra­mu może (nie musi) wią­zać się z prze­nie­sie­niem praw mająt­ko­wych do jego Specyfikacji. Jej treść tak­że może być przed­mio­tem odręb­nej umo­wy. Decyduje o tym fakt, że Kod pro­gra­mu jest dzie­łem zależ­nym w sto­sun­ku do jego Specyfikacji.

Specyfikacja opro­gra­mo­wa­nia może zawie­rać w swej tre­ści opis okre­ślo­ne­go mecha­ni­zmu, np. usta­la­nie sco­rin­gu kre­dy­to­bior­cy albo przy­zna­wa­nie okre­ślo­nych upu­stów okre­ślo­nym gru­pom klien­tów. Treść ta może więc sta­no­wić know-how, któ­re może być chro­nio­ne np. jako tajem­ni­ca firmy.

Teraz nie­co trud­niej. Na ryn­ku spo­ty­ka­my poję­cia ​„opro­gra­mo­wa­nie w chmu­rze”, SaaS (Software as a Service), out­so­ur­cing. Pojęcia te, w swych nazwach, nie mają żad­ne­go umo­co­wa­nia w pra­wie. Czym więc są? Osobiście jestem zwo­len­ni­kiem nie­uży­wa­nia ich ina­czej niż jako komen­ta­rza. Innymi sło­wy Umowa powin­na być skon­stru­owa­na z ter­mi­nów praw­nych (uży­tych i zde­fi­nio­wa­nych w Ustawach), ter­mi­ny stwo­rzo­ne na uży­tek komu­ni­ka­cji ryn­ko­wej (np. ​„clo­ud com­pu­ting”) powin­ny być w tych umo­wach każ­do­ra­zo­wo defi­nio­wa­ne z uży­ciem ter­mi­nów prawnych.

Jeżeli więc ktoś korzy­sta ​„w chmu­rze” z opro­gra­mo­wa­nia pozwa­la­ją­ce­go np. zarzą­dzać kon­tak­ta­mi z klien­ta­mi, to zna­czy, że za pośred­nic­twem sie­ci Internet Użytkownik ma dostęp do Aplikacji, korzy­sta z Usług apli­ka­cji. Robi to na pod­sta­wie Umowy jaką zawarł Interesariusz 2 z Interesariuszem 4 (tu tak­że Interesariusz 2 i Użytkowmik mogą być tą samą oso­bą fizycz­ną). Umowa okre­śla tu np. ilu Użytkowników może korzy­stać z Usług apli­ka­cji oraz to, czy użyt­kow­ni­kiem może być kto­kol­wiek czy kon­kret­ne oso­by z imie­nia i nazwiska.

Hosting. Jest to usłu­ga zali­cza­na do out­so­ur­cin­gu. W tym przy­pad­ku mamy sytu­ację taką:

1. Prawa do Aplikacji ma Interesariusz 2.
2. Aplikacja zain­sta­lo­wa­na jest na Komputerze będą­ce­go wła­sno­ścią Interesariusza 4.
3. Użytkownicy, np. pra­cow­ni­cy Interesariusza 2, zdal­nie za pośred­nic­twem sie­ci Internet, korzy­sta­ją z Usług aplikacji.
4. Umowa pre­cy­zu­je szcze­gó­ło­wo opła­ty i odpo­wie­dzial­ność obu interesariuszy.

Takich ​„kom­bi­na­cji” może być wie­le, jed­nak na koniec opi­szę to co nazy­wa­my prze­tar­ga­mi. Pojawia się w nich poję­cie Opis Przedmiotu Zamówienia, któ­re moim zda­niem spra­wa w tej bran­ży, spo­ro kło­po­tu tak­że prawnikom.

Typowym celem ogła­sza­ją­ce­go prze­targ (każ­de­go ​„kupu­ją­ce­go” opro­gra­mo­wa­nie) jest moż­li­wość korzy­sta­nia z Usług apli­ka­cji. W tym celu zawrze umo­wę (out­so­ur­cin­go­wą, licen­cyj­ną, itp.), któ­ra mu na to pozwo­li. I tu wra­ca­my do naszej pomi­do­rów­ki. Kluczem jest Specyfikacja, któ­ra zawie­ra opis tego jakie to usłu­gi i jaki jest mecha­nizm ich reali­za­cji. Dla kupu­ją­ce­go nie ma tu (na tym eta­pie) abso­lut­nie żad­ne­go zna­cze­nia, czy ta apli­ka­cja będzie spe­cjal­nie dla nie­go two­rzo­na czy nie. Specyfikacja MUSI powstać, bez cze­go nie da się stwier­dzić, czy dana Aplikacja jest tą, któ­rą zama­wia­my i któ­rej potrze­bu­je­my. Do tego korzy­sta­nie z zaku­pio­nej Aplikacji może wyma­gać pew­nych prac, takich jak jej zain­sta­lo­wa­nie, skon­fi­gu­ro­wa­nie, prze­szko­le­nie Użytkowników, umiesz­cze­nie w niej pew­nych danych (np. migra­cja danych z poprzed­nio uży­wa­nej apli­ka­cji), cza­sa­mi zin­te­gro­wa­nie z inny­mi, już wyko­rzy­sty­wa­ny­mi, apli­ka­cja­mi. Ogłaszający taki prze­targ zapła­ci za:

1. pra­wo korzy­sta­nia z Aplikacji (w usta­lo­nej fir­mie np. licencji),
2. wszel­kie koniecz­ne usłu­gi poprze­dza­ją­ce nor­mal­ne użyt­ko­wa­nie Aplikacji,
3. jeże­li na ryn­ku nie jest ofe­ro­wa­ne wyma­ga­ne opro­gra­mo­wa­nie, zosta­nie ono ​„napi­sa­ne” na pod­sta­wie Specyfikacji spe­cjal­nie dla Zamawiającego.

Jak widać, Specyfikacja jest tu bar­dzo istot­nym ele­men­tem, wręcz nie­zbęd­nym. To co nazy­wa­my Opisem Przedmiotu Zamówienia jest czymś wię­cej niż tyl­ko Specyfikacja opro­gra­mo­wa­nia. Dobrą prak­ty­ką jest roz­dzie­la­nie tych trzech powyż­szych ele­men­tów, ogrom­ną wygo­dą jest jeże­li są to odręb­ne umo­wy lub odręb­ne załącz­ni­ki Umowy głów­nej. Splatanie razem tych aspek­tów naj­czę­ściej pro­wa­dzi do nie­po­ro­zu­mień, pro­ble­mów z inter­pre­ta­cją umo­wy w cza­sie spo­rów. W skąd­inąd cie­ka­wym arty­ku­le pew­na kan­ce­la­ria wska­zu­je przy­czy­ny, a jako roz­wią­za­nie pro­ble­mu wska­zu­je jedy­nie pra­wo do wyco­fa­nia sie z umowy:

Nie ma recep­ty na popraw­ne opi­sa­nie przed­mio­tu świad­cze­nia. Jeśli mamy roz­bu­do­wa­ne, pre­cy­zyj­ne spe­cy­fi­ka­cje, to i tak musi­my w umo­wie opi­sać zarzą­dza­nie zmia­ną, ze szcze­gól­nym uwzględ­nie­niem roli ana­li­zy. W więk­szo­ści wypad­ków spe­cy­fi­ka­cje są na tyle ogól­ne, że dopie­ro ana­li­za (pro­jekt funk­cjo­nal­ny, kon­cep­cja itp.) opi­su­je praw­dzi­we ?co”. Już na począt­ku kon­trakt musi zadbać o inte­re­sy stron (zwłasz­cza zama­wia­ją­ce­go), jeże­li oka­że się, że ana­li­za ? choć prze­pro­wa­dzo­na popraw­nie ? pro­wa­dzi do wnio­sków nie­ak­cep­to­wal­nych (kosz­ty, zakres zmian, ter­mi­ny). Jednym ze spo­so­bów jest wpro­wa­dze­nie umow­ne­go pra­wa odstą­pie­nia od umo­wy. To mini­mum praw­ni­czej przy­zwo­ito­ści, pozwa­la­ją­ce małym kosz­tem wyco­fać się z umo­wy. (Źródło: Pięć typo­wych błę­dów w umo­wach wdro­że­nio­wych) 

Recepty na opi­sa­nie opi­sa­nie nie ma (a na co jest?), ale są zasa­dy, o któ­rych tu piszę. Kilka uwag do powyż­sze­go. Rozbudowana spe­cy­fi­ka­cja to gwa­ran­to­wa­ne pro­ble­my zwią­za­ne z zarzą­dza­niem zmia­ną i tu nale­ży sie zgo­dzić zaś zbyt ogól­ny opis jest jesz­cze gor­szy, bo po pro­stu nie wia­do­mo co jest przed­mio­tem zawie­ra­nej umo­wy. Kluczem jest to: ​„W więk­szo­ści wypad­ków spe­cy­fi­ka­cje są na tyle ogól­ne, że dopie­ro ana­li­za (pro­jekt funk­cjo­nal­ny, kon­cep­cja itp.) opi­su­je praw­dzi­we ?co””. W takim przy­pad­ku nie­ste­ty dostaw­ca po pro­stu dostar­czy to co chce, bo sko­ro jest wyko­naw­cą i auto­rem ana­li­zy wyma­gań to zna­czy jest że jest auto­rem opi­su przed­mio­tu umo­wy. Biorąc pod uwa­gę fakt, że w takich sytu­acjach z zasa­dy dostaw­ca tech­no­lo­gii ma prze­wa­gę mery­to­rycz­ną nad swo­im klien­tem (bo ten z jakie­goś powo­du nie zro­bił opi­su sam), zama­wia­ją­cy w zasa­dzie nie panu­je na tym co dosta­nie. Słowo ​„ana­li­za” nie defi­niu­je tego co jest pro­duk­tem ana­li­zy, ten powi­nien zostać zde­fi­nio­wa­ny. Doświadczenie auto­ra cyto­wa­ne­go arty­ku­łu, mogę potwier­dzić, on sam zaś przy­zna­je, że ​„popraw­ne­go” opi­sa­nia przed­mio­tu zamó­wie­nia praw­ni­cy nie są w sta­nie doko­nać co jest praw­dą. W czę­ści ​„Prawa autor­skie i kod źró­dło­wy” w zasa­dzie Pan Marcin Maruta nie napi­sał nic o pra­wach autor­skich do kodu opro­gra­mo­wa­nia a szkoda.

Najważniejszym celem porząd­ko­wa­nia pojęć w umo­wach, są kwe­stie praw stron i ochro­ny know-how. 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).

Na zakończenie

Oczywiście nie wyczer­pa­łem tu wszyst­kich kom­bi­na­cji bytów praw­nych w zawie­ra­nych umo­wach. Należy pamię­tać o umo­wach z dostaw­ca­mi apli­ka­cji inte­gro­wa­nych, kom­po­nen­tów itp.. Celem moim było zwró­ce­nie uwa­gi na naj­czę­ściej spo­ty­ka­ne pro­ble­my, ich źró­dła i wska­za­nie jak się przed nimi zabezpieczyć.

Chętnie odpo­wiem na pyta­nia i podej­mę pole­mi­kę. Mam świa­do­mość, że opi­sa­ne tu zagad­nie­nia bywa­ją przed­mio­tem wie­lu spo­rów, sam je nie­jed­no­krot­nie toczę i z dostaw­ca­mi opro­gra­mo­wa­nia i z ich praw­ni­ka­mi. Uważam tak­że, że obec­ne pra­wo pozwa­la na bar­dzo dobrą ochro­nę stron takich umów, wyma­ga to jed­nak ogrom­nej pre­cy­zji w kon­stru­owa­niu tre­ści umów i two­rze­niu doku­men­tów opi­su­ją­cych ich przed­miot co abso­lut­nie nie wymu­sza tak zwa­nych ​„metod wodo­spa­do­wych” w projektach.

Od lat sto­su­ję w swo­ich ana­li­zach i pro­jek­tach mię­dzy inny­mi, dia­gra­my takie jak powyż­szej. Pomagają one usta­lić pre­cy­zyj­nie wszel­kie aspek­ty i praw­ne i pro­jek­to­we w umo­wach, do cze­go gorą­co zachę­cam. Niestety wie­lu praw­ni­ków przyj­mu­je za cel swo­jej pra­cy ​„obu­do­wa­nie” para­gra­fa­mi tego cze­go żąda­ją od nich w umo­wach, ich klien­ci. Owszem fir­my pła­cą praw­ni­kom za to, że Ci chro­nią ich inte­res, ale wie­le z tych umów to nie­ste­ty mani­pu­la­cje i korzy­sta­nie z nie­wie­dzy part­ne­ra, nie raz z jego gor­szej zna­jo­mo­ści (nie­zro­zu­mie­nia) prawa. 

Polecam też świet­ny tekst napi­sa­ny okiem praw­ni­ka (autor mec. Renata Warchol-Lewicka):

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ć? (Source: TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK | Renata Warchol-Lewicka | Pulse | LinkedIn)