Smlouvy pro digitální podnikání

Při čtení této příručky si možná často řeknete: „No jo, ti právníci jsou strašně paranoidní, pořád vidí jen ten nejhorší scénář a opakují, co můžou a nemůžou udělat u soudu. K tomu stejně skoro nikdy nedojde, tak proč se s tím vůbec zaobírat?“ Odpověď je jednoduchá. Dokud všechno běží jak na drátkách, vy pracujete, klient je spokojený a platí, tak právníka nepotřebujete. Nepotřebovali byste ani písemnou smlouvu.

Právníka potřebujete právě na to, aby vaši smlouvu připravil pro případ, že se něco pokazí. Proto ke smlouvám přistupujeme tak, že řešíme potenciální problémy.

Čím více jich podchytíme, tím silnější pozici budete mít, pokud něco nepůjde podle vašich představ. Jelikož ale nikdy dopředu nevíte, který projekt jako po drátkách půjde a kde se vyskytnou problémy, tak se vyplatí věnovat prevenci raději vždy. Pokud víte, že jednou budete po právníkovi chtít, aby vám připravil bezpečnou smlouvu, není důvod to nechávat na později. Jednou ji stejně zaplatíte, tak proč ji nemít hned na začátku a nemít bezpečně zasmluvněné všechny zakázky?

Stejná zakázka může s dobrou smlouvou dopadnou tak, že klient ji celou zaplatí, i když na ní pokazíte, co se dá. Se špatnou smlouvou můžete dopadnout tak, že od klienta neuvidíte ani korunu, ale navíc mu budete muset ještě dlouho platit náhradu škody.

Ani nejlepší smlouva na světě vám ale nezajistí peníze, tam kde nejsou. Když nevíte, jestli má váš klient na zaplacení, je rozumnější chtít peníze předem. Pokud tuto publikaci čtete ze strany odběratele, samozřejmě to platí zrcadlově. Ani nejlepší smlouva nedonutí vašeho dodavatele odvést dobrou práci, jestliže na to jednoduše nemá a stejně nemá ani žádné peníze, které byste vymáhali soudně.

A ještě jedna věc. Pokud zrovna neposkytujete služby pro spotřebitele, tak většinou platí, že si můžete dohodnout jiný postup, než jak se to řeší v zákoně. Stačí ho do smlouvy popsat.

Na následujících stranách vás provedeme základními částmi smlouvy. Prakticky, bez paragrafů.

Pojďme na to.

1 Název smlouvy

Většinou jej vidíte jako první, protože na vás svítí hned v úvodu a je napsaný největším písmem. Ale především by vám měl dát ve stručnosti vědět, o čem text smlouvy je. Protože smlouvy nejčastěji chystají právníci, setkáte se s názvy, které jsou upraveny přímo v zákoně, ale vám toho moc neřeknou (smlouva o dílo, licenční smlouva, příkazní smlouva).

Nic nebrání tomu, vymyslet si název vlastní. A pokud zákon vaši smlouvu nezná, vlastně ani nemáte jinou možnost. V IT je naprosto běžné uzavírat software development agreement, service level agreement nebo end user license agreement. Vhodnější je nazvat ji výstižně rovnou a na jednotlivé zákonné ustanovení odkazovat až dále v textu smlouvy. Pro vás bude smlouva uchopitelnější a kdokoliv další ji dostane do rukou, pochopí, co chtěl názvem básník říci.

2 Smluvní strany

Vy a váš klient. Identifikovat se ve smlouvě se většinou zdá jako bezproblémová věc. Uvedu své jméno, bydliště, datum narození a IČ. Společnost pak svůj název, sídlo, IČ. Díky. Čau. Takhle to má převážná většina podnikatelů.

O něco míň jich ale ví, že je potřeba uvádět i informaci o zápisu do obchodního nebo živnostenského rejstříku. Včetně detailů jako oddíl a vložka zápisu. Za nesplnění můžete dostat pokutu až 100 tis. Kč. Nikdy jsme se s touto sankcí osobně nesetkali. Ale teď už nemůžete říct, že jste o ní nevěděli.

A pokud máte za smluvního partnera společnost s ručením omezeným nebo akciovku, pohlídejte si, aby s vámi smlouvu uzavíral člověk, který na to má právo. U kontraktů vyšší hodnoty to bude nejčastěji přímo jednatel, člen představenstva nebo se setkáte s prokuristou. Limity oprávnění jsou někdy uvedeny online ve veřejně přístupném obchodním rejstříku v části Statutární orgán – Způsob jednání. Stejně jako požadavek, pokud má smlouvu uzavřít více jednatelů nebo členů představenstva.

Ve středních a větších IT korporacích je často jednatelem, tedy tím, kdo s vámi může uzavřít smlouvu, CEO. Ale není to pravidlo. IT řešení může objednávat CTO nebo CIO

společnosti.1 Pokud danou osobu vidíte jako člena užšího vedení i na webu společnosti, je to dostatečná indicie, že s vámi kontrakt pravděpodobně ze své pozice může uzavřít. Poslechněte selský rozum, pokud vám říká, že fakturantka bude stěží odpovědná za objednávku a implementaci cloudového účetnictví pro celou společnost. V případě pochybností chtějte doložit plnou moc.

Je velmi praktické mít pár lidí, kteří budou váš software v praxi používat, k ruce už v průběhu dodávky zakázky. Vymezte si je rovnou ve smlouvě jako osoby oprávněné pro komunikaci s dodavatelem. Vyhnete se odpovědnosti za přijímání pokynů od lidí, kteří k tomu nejsou oprávněni.

1 CEO je zkráceně Chief Executive Officer, tedy výkonný ředitel ve společnosti. CTO je zkratka pro technologického ředitele, setkat se můžete i se CIO, tedy šéfem pro IT.

3 Preambule

Typická smlouva je většinou spletí toho, co během spolupráce můžete, musíte, nemůžete nebo nesmíte. Proto bohužel vypadají často velmi podobně. Pokud ale spolupráce probíhá déle, spolupracujete paralelně s více partnery nebo se smlouva dostane do rukou někoho dalšího – investora nebo třeba soudce – hodí se znát i kontext, v jakém vznikala.

Nebojte se dát na úvod smlouvy příběh, který k jejímu uzavření vedl. Že se kupříkladu smlouva uzavírá v rámci B2B a je časově závislá na jiném projektu. Že poskytujete nebo máte zájem na poskytnutí služeb UX designéra pro váš nový e-shop s kávou, protože stojíte o zlepšení konverzí. Nebo dodáváte IT řešení jako subdodavatel v rámci vysoutěžené veřejné zakázky. Kontext usnadňuje interpretaci. A správná interpretace předchází nesmyslným sporům o to, na čem jste se se svým smluvním partnerem vlastně chtěli domluvit. Preambule není povinná, ale v praxi ji oceníte. Stejně jako kdokoliv třetí, kdo vaši smlouvu bude číst.

4 Definice

Definice jsou jako legenda mapy. Jsou to zkratky detailně popisující význam slov nejčastěji používaných v kontraktu. Buď jsou ve smlouvě koncentrovány na jednom místě nebo jsou rozmístěny různě v textu. Využijte toho, že jimi můžete vyjádřit i velmi komplikovaná slovní spojení, jejichž opakovanému čtení se chcete v zájmu zachování svého duševního zdraví vyhnout.

Skvělým příkladem je rozsah zpracovávaných osobních údajů (osobním údajům se detailně věnujeme v kapitole níže), který je nesčetněkrát skloňován ve zpracovatelské smlouvě. A není snazší zastřešit uživatelské jméno, heslo, jméno a příjmení, adresu, e-mail a údaje o přihlášení do aplikace zkratkou osobní údaje?

Definice však mohou nadělat pěknou paseku. Pokud používáte více dokumentů, které upravují váš vztah se zákazníkem (u instalovaného softwaru třeba informace z webového objednávkového procesu, všeobecné obchodní podmínky, zásady ochrany osobních údajů a licence, která je součástí instalačního souboru), je maximálně vhodné být konzistentní a užívat stejné zkratky, kde to jen půjde. Abyste předešli sporům o interpretaci podmínek spolupráce.

5 Předmět smlouvy

Předmět smlouvy by měl být maximálně stručný a věcný. To je přesně to místo ve smlouvě, kde by mělo být zachyceno zadání. Bez omáčky, ale komplexně, abyste byli po přečtení této části schopni zjistit, o čem celá smlouva je. Na omáčku máme celý zbytek smlouvy. Vyvíjíte webové stránky? Ve smlouvě by mělo být: „Dodavatel vyvine pro objednatele webové stránky.“ Registrujete doménu? Ve smlouvě bude:

„Dodavatel zajistí pro objednatele registraci domény.“ Nezapomeňte, že předmětem smlouvy je i platba, takže by zde mělo zaznít také: „Objednatel zaplatí odměnu.“ Opět bez omáčky – odměna má celý vlastní článek, kde ji dost pitváme.

Je třeba si vyjasnit, za co chcete být zaplaceni a tomu přizpůsobit i předmět smlouvy. Máte být placeni za výsledek, nebo za úsilí? Formulace: „Dodavatel vyvine pro objednatele webové stránky,“ znamená spíše, že dostanete zaplaceno za hotové stránky. Formulace: „Dodavatel poskytne služby vývoje webových stránek,“ naopak spíše naznačuje, že máte být placeni od hodiny, bez ohledu na to, jestli bude web někdy hotový. Není to jedno, právě naopak. Nacházíte se totiž na rozcestí smlouvy o dílo a smlouvy (nejčastěji) příkazní a musíte si vybrat, kterou cestou jít. Rozdíl je zásadní a odvíjí se od toho také další obsah smlouvy.

Celkem pravidelně je přesně tohle místo, kde smlouva začíná být špatně. Nejsou výjimkou smlouvy, kde je uvedeno, že budete odměněni za dílo, ale v části o odměně je výhradně hodinovka a měsíční fakturace. Co s tím? Dokud klient platí, nikoho to nepálí. Jakmile se ale dostanete do sporu a bude třeba jít k soudu, první, na co se soudce zeptá, je: „Jak přesně zněla dohoda o předmětu smlouvy?“ Vnitřní rozpor smlouvy může v krajním případě vést až k zamítnutí žaloby. Paradoxně je v tomto případě lepší písemnou smlouvu nemít vůbec než ji mít vnitřně rozpornou. Váš právník by vám nejraději utrhnul hlavu za obojí. V této chvíli totiž nebude schopen předvídat, jak soud dopadne a celé soudní řízení bude velký risk.

6 Trvání a ukončení smlouvy

Typicky se potkáte buď se smlouvou, podle které máte splnit zadaný úkol (vytvořit část kódu, uzpůsobit software, opravit bug), nebo se smlouvou, podle které máte pracovat kontinuálně na projektu, u kterého je konec v nedohlednu. Podle toho se bude odvíjet i trvání smlouvy. Respektive právně správně, trvání závazků, které pro vás ze smlouvy plynou.

V prvním případě pravděpodobně budete očekávat, že odvedete zadaný úkol, dostanete zaplaceno a budete se v klidu věnovat dalším projektům. Tak to v praxi většinou nebude. Kontrakt bude nejspíš obsahovat povinnosti, které se vás nepustí ještě hezkých pár let. Mlčenlivost, konkurenční doložky, řešení vad software, autorská práva ke kódu. A na ně navázané smluvní pokuty. Spočítejte si proto hned na začátku, jestli je vaše odměna adekvátní povinnostem, které podstupujete.

Zato ve druhém případě se vždy zaměřte na možnost opuštění smluvního vztahu vámi nebo smluvním partnerem. Zvláště u smlouvy na dobu neurčitou. Jako dodavatel chcete mít jistotu, že vás odběratel bezdůvodně neodstřihne od hladce běžícího projektu. U dobře nastavených podmínek dáte přednost automatickému prodloužení kontraktu před datem expirace než uzavření nového za nových podmínek. Na druhou stranu, chcete mít jistotu, že při neférovém jednání vašeho

zákazníka (neplacení, pasivita v komunikaci, neposkytnutí

podkladů pro práci) můžete s klidným srdcem odejít.

Pravidla pro opuštění smluvního vztahu řeší občanský zákoník poměrně logicky. Zákon se použije vždy, když si podmínky ukončení spolupráce nesjednáte sami ve smlouvě. Právní teorie poskytuje nespočet možností. V praxi oceníte znalost minimálně tří: 1) dohody, 2) výpovědi a 3) odstoupení od smlouvy.

Dohoda bolí nejméně. Dohodnete se, že spolupráce končí. Nebo řešitelný problém vyřešíte narovnáním a ve spolupráci budete pokračovat.

Výpověď je dobrou možností u déletrvajících spoluprací. Jejími atributy jsou výpovědní důvody (kdy můžu vypovědět) a výpovědní doba (za jak dlouho spolupráce skončí). Pokud zvolíte cestu výpovědi, spolupráce doběhne za sjednaných podmínek až do konce výpovědní doby.

Odstoupení od smlouvy je zpravidla silnější nástroj než výpověď. Skrze odstoupení se totiž ve většině případů vracíte v čase a smluvní vztah rušíte od počátku. Proto je potřeba je užívat s rozmyslem. Základem je mít dobře popsány důvody, kdy lze odstoupit. Většinou půjde o tak závažná porušení, o kterých kdybyste věděli na začátku, že nastanou, do spolupráce byste se vůbec nepouštěli. Opakované

nedodržení splatnosti faktury, přetahování sub-kontraktorů, úplná absence součinnosti.

Domluvili jste se s klientem na nasazení webu, ale neuhradil zálohu? Dobrý důvod odstoupit. U dlouhodobých kontraktů na dodávku služeb se však odstoupení chová jako výpověď. Např. u řádně proběhlé a zaplacené správy webových stránek není zpětně co rušit. Ale ve spolupráci nechcete pokračovat, protože klient neplatí, proto ohledně budoucí spolupráce odstoupíte. U dlouhodobých kontraktů není prakticky rozdíl mezi odstoupením a výpovědí.

Při výpovědi některé závazky (povinnost mlčenlivosti, zákaz konkurence) přetrvávají. Při odstoupení od jednorázových kontraktů se zpravidla podobných závazků zbavujete. Ale váš zákazník také.

Pokud jste pro klienta odvedli práci, která mu bude k užitku, ale chcete odstoupit, měli byste dostat zaplaceno za dohodnutých podmínek, protože ohledně takové části dodávky kontrakt nezaniká. Pokud jste naopak dostali zaplaceno, ale práci jste neodvedli, budete platby vracet.

Xxxxxxx na to, jestli se chcete při skončení spolupráce zatěžovat papírovou výpovědí nebo odstoupením. E-mailová komunikace je mnohdy efektivnější a důkazně dostačující.

7 Specifikace předmětu smlouvy

Čím více toho máte dělat, tím delší bude i článek o specifikaci předmětu smlouvy, který je dobré pro přehlednost rozdělit stejně, jako si dělíte samu práci. Stejně tak rozčleníme i tuto kapitolu. Některé smlouvy používají podle nás zastaralé členění 1) Práva a povinnosti jedné strany a 2) Práva a povinnosti druhé strany. Pak vznikají tendence do takových článků napsat v podstatě celou smlouvu, protože se tam tak nějak hodí. No, a do ostatních částí to pak pro jistotu jen zopakovat. Zbytečně moc. Xxxxxxxxx se chceme vyhnout.

Ve smlouvě by měla být jen smluvní specifikace, ne technická. Technickou si nechte na přílohu, protože přesné parametry se dost pravděpodobně budou s postupem času a práce měnit a doplňovat. Do smlouvy by mělo přijít to, co se pravděpodobně v průběhu práce měnit nebude. Mějte na paměti, že je vždy vhodnější měnit přílohu, než měnit smlouvu (tedy, pokud si to tak ve smlouvě nastavíte). Je velmi praktické, aby váš partner určil projektového manažera, který bude moci závazně upravovat zadání, ale většinou takový člověk nebude mít v hlavě současně také byznysové souvislosti, aby mohl např. domluvit zvýšení vaší ceny.

Pokud něco není specifikováno, bývá to pravidelně příslovečným stéblem, kterého se bude chytat klient tonoucí v platební neochotě. Nedávejte mu tu šanci. Ideálně sem

napište, že co není napsáno ve specifikaci vůbec, není součástí smlouvy. Tím pádem ani součástí nacenění. A to, co není specifikováno konkrétně, můžete sami vyřešit, jak uznáte za vhodné vy. Tím se vyhnete nekonečnému přepracovávání návrhů pro ustavičnou nelibost klienta.

7.1 Vývoj webových stránek

Smlouvě většinou předchází nějaké to posezení s klientem, náčrtky struktury apod. Nejlepší je takový náčrtek přicvaknout ke smlouvě. Pokud si posléze klient vzpomene, že by se mu to vlastně líbilo jinak, a vyžadoval by po vás přepracování (bez příplatků), můžete mu směle ukázat náčrtek a říct, že dohoda byla tahle, a pokud chce něco jinak, tak to nebude zadarmo. Pokud by s tím nesouhlasil, měli byste mít sjednánu možnost předat klientovi rozpracovanou práci za poměrnou část odměny a šmitec.

Znatelněji se nedostatek specifikace projeví, pokud máte programovat webovou aplikaci. Na začátku klient vše vidí jednoduše a stačí mu 10 základních funkcí. V půlce práce se ale často ukáže, že by tohle chtěl vlastně jinak, tamto vlastně nepotřebuje, a ještě je vlastně nejdůležitější, aby mohl v Google Analytics sledovat tohle. Že na začátku GA nechtěl, a tak jste udělali aplikaci schválně levněji na šabloně, která zrovna tohle sledovat neumí, a můžete to celé přepisovat.

„Cože? Že to bude stát o dvě stě tisíc víc? Za co jako?“ Takže opět zdůrazňujeme, že je třeba vyspecifikovat objednané funkce. Případné požadavky klienta na další funkce vyřešit jako novou objednávku, s novým naceněním a novým harmonogramem.

A nezapomeňte si domluvit, pro jaké webové prohlížeče máte webové stránky vyvíjet. Aby vás klient nepřekvapil reklamací, že mu to nejde zobrazit na jeho pravěkém Firefoxu verze 14.0.

7.2 Vývoj aplikace

Je to vlastně dost podobné vývoji webových stránek. Narozdíl od nich ale aplikace více pracuje se vstupy a dále s nimi operuje. Takže se spíše stane, že něco nebude fungovat tak, jak má, a chyba se neprojeví hned. Narozdíl od webových stránek je proto zvlášť důležité, abyste si domluvili, na jakém operačním systému (resp. prohlížeči v případě webových aplikací) a v jaké minimální verzi má pracovat, jestli má běžet online nebo si uživatelé budou aplikaci stahovat do svého zařízení, jak budou do aplikace přistupovat uživatelé (úroveň zabezpečení přihlášení), kolik uživatelů má aplikace zvládnout naráz (pokud běží online), co přesně má aplikace umět, v jakém formátu má zpracovávat data, kam je má ukládat a s jakými bezpečnostními opatřeními, kdo k nim má mít přístup a jakým způsobem, a jak ji máte před dokončením otestovat.

Testování je třeba věnovat se podrobněji. Je důležité ve smlouvě napsat, jestli a jak máte testovat aplikaci vy a v jakém rozsahu, nebo jestli ji má testovat klient. S testováním je úzce spojený proces předání. Dost klientů je zvyklých na přežitou, u aplikací navíc naprosto nevhodnou, formulaci bez vad a nedodělků. Proč nevhodnou? Protože otevírá dveře velkým obstrukcím. Dokonce i zákon už tuto formulaci opustil. Pokud ve smlouvě budete mít napsáno, že jste povinni předat dílo bez vad a nedodělků, znamená to, že jakákoliv sebemenší blbost způsobí, že nestihnete v termínu předat. A to s sebou může nést smluvní pokuty a podobné nepříjemnosti, se kterými vás může klient prudit. Zákon v dnešní době vyžaduje jako kritérium pro provedení díla u aplikací (tj. díla s nehmotným výsledkem činnosti), aby bylo umožněno klientovi s dílem nakládat a aby mu byla předvedena jeho způsobilost sloužit svému účelu (dle sjednané specifikace). Tedy, aplikace musí umět to, k čemu je určená. Pokud má umožnit nakupovat třeba vstupenky, je rozhodné, zda po použití aplikace dojde k prodeji vstupenky a proběhnou všechny podstatné kroky (vstupenka se zašle, kam má, platba se zprocesuje). Na hranici by bylo, pokud by aplikace třeba prodala jednu vstupenku dvakrát, dovolila prodat víc vstupenek, než je k dispozici, nebo zaslala vstupenku i uživateli, který nezaplatil. Naopak předání nevadí, pokud třeba uživatel není vždy přesměrován na další stránku automaticky a musí někam kliknout, pokud by někde neseděla grafika, nebo

pokud by nefungovala nějaká vedlejší funkcionalita. Takové chyby nebrání předání, ale jsou to vady, které musíte následně odstranit. Rozdíl je v tom, že jste předali v termínu.

Pokud se s klientem domluvíte, že má být aplikace otestovaná, stanovte si testovací parametry a do smlouvy napište, že se dílo považuje za dokončené ve chvíli, kdy testováním projde. Stanovte si takové parametry, na kterých klientovi skutečně záleží a jsou pro funkci důležité.

S vývojem aplikace se pojí i její grafický design. Jeho kvalitu nebo funkčnost stěží empiricky otestujete. Ohledně něj byste měli mít schválení nastavené jinak. Vývojáři na tyto podřadnosti často nemyslí, ale už jsme zažili situaci, kdy klientka webovou aplikaci za čtvrt milionu nezaplatila se slovy:

„Sice to funguje, líbí se mi to, ale nejsem to já, takže to nechci.“ Proto je vhodné mít designový koncept schválený předem, případně zpracovat designové návrhy jako zvláštní zakázku, kterou dostanete zaplacenou zvlášť a bez ohledu na to, zda se klientovi bude líbit.

7.3 Zajištění doménového jména a webhostingu

Tady se dostáváme do křížku s obchodními podmínkami registrátora a správce domény, popř. poskytovatele hostingu (pokud nemáte vlastní servery). Pokud klientovi nebudete poskytovat i správu a údržbu, dejte si pozor, aby minimálně v této části vaše povinnosti končily tím, že doménové jméno

s registrátorem vyřídíte, hosting objednáte a klientovi pošlete jen informaci, kam má kolik zaplatit. Pokud děláte klientovi i následnou správu, je třeba určit, jestli se mu máte starat také o obnovení registrace a prodlužování hostingu, jestli za to má platit přímo poskytovatelům, nebo mu budete náklady přefakturovávat vy. Podobně je to s náklady na reklamu při zajišťování reklamních kampaní. Přefakturace má jisté dopady v daních, tak na to taky pozor.

Pokud máte vlastní servery a hosting poskytujete přímo, měla by smlouva řešit také správu DNS, místo pro e-mailové schránky, SSL certifikáty, správu serverů (aktualizace, instalace) a jejich zálohování. Tyto věci určitě máte sepsané, protože jsou to věci, které zákazníky zajímají a podle nich si vybírají poskytovatele. Úroveň těchto doprovodných služeb by ale neměla chybět ani přímo ve smlouvě, klidně formou přílohy s parametry služby.

7.4 Servis a údržba software

U servisu je třeba přesně popsat, za co má klient platit a jaký

rozsah služeb mu máte poskytovat.

U cloud computingových kontraktů budete nejčastěji uzavírat

SLA,2 kde si vymezíte dostupnost služby formou KPIs

2 Jako SLA se označuje Service Level Agreement, což je smlouva, ve které se stanoví úroveň poskytovaných služeb. Jako parametry se často používají Key Performace Indicators (KPIs).

a následky při nedostupnosti služby. V servisní smlouvě můžete ošetřit i odstraňování bugů, které se vyskytnou během provozu, řešení incidentů, tvorbu updatů, zálohování dat, ale třeba i správu účtu na Google Play nebo Apple Store, kde aplikaci za klienta prodáváte.

Při řešení incidentů si nezapomeňte sjednat reakční dobu. Nejlépe dvě – první jako čas k potvrzení přijetí hlášení o bugu a druhý jako čas, kdy na odstraňování začnete pracovat. Pokud si hodně věříte, tak klidně i termín, kdy bug odstraníte. Dává smysl reakční dobu odstupňovat podle závažnosti incidentu (ty, které nebrání provozu, ji mají delší). Posuzování závažnosti by mělo být ve vaší kompetenci a s jeho kvalifikací byste měli klienta seznámit bezprostředně po přijetí hlášení. Ať se vyhnete sporům z nedostatečné komunikace.

Dále je důležité stanovit, jestli si klient předplácí nějaké vaše hodiny nebo platí paušál bez ohledu na to, jestli a kolik toho uděláte. Ve druhém případě je třeba velmi pečlivě určit, co za úkony jsou kryty paušálem a co se platí zvlášť. Ať klient nemá dojem, že po vás může chtít, abyste mu neustále dodělávali nové funkce, když jste se jasně dohodli, že máte jen odstraňovat bugy. Stanovte si, co se stane s nevyčerpanými hodinami nebo naopak v případě, že se limit překročí. Můžete čas doúčtovávat nebo se stáhne z budgetu dalšího měsíce. Ve druhém případě je dobré si stanovit nějaké vyrovnávací období. Taky není špatné nastavit si automatické zvýšení

paušálu na další období, pokud se průměrný časový limit ukáže jako nedostatečný.

Nadhodili jsme prodej aplikace na platformách. To je trošku věda, protože Google i Apple mají aktuálně nastavené podmínky jinak, než by to podle platných daňových předpisů mělo fungovat. V praxi nezbude než rezignovat na právně správné řešení a přijaté tržby prostě jen tak, jak přišly, odeslat klientům.

8 Komunikace

Uvedení lidí z projektového týmu klienta včetně kontaktních údajů, kteří budou odpovědní za komunikaci s vámi, je úplné minimum pro vaše klidné spaní. U řešení servisních požadavků přemýšlejte i nad dny a hodinami, kdy chcete být k zastižení (např. pondělí až pátek s výjimkou dnů připadajících na státní svátky v ČR v době od 9:00 do 18:00), a komunikačními kanály, které chcete používat (ticketovací systémy, e-mail, telefonická komunikace). Jako obezřetní právníci se kloníme ke komunikaci, která je písemně zachycena. Telefonní rozhovory a videohovory nejsou většinou nahrávány, takže je pak nelze použít jako důkazní materiál.

9 Vícepráce

V IT se vícepráce objevují snad častěji než ve stavebnictví. Plyne to obvykle z nedostatku specifikace a nesprávných představ klienta, co všechno jeho drobný požadavek navíc obnáší.

Pro plynulost práce je ideální stanovit automatický režim s hodinovou sazbou. Bezpečnějším, ale klientsky velmi nepřívětivým, řešením je na každý požadavek klienta mimo specifikaci zareagovat individuálním naceněním požadavku. A nezačít s jeho plněním dříve, než dostanete od klienta výslovný souhlas s cenou.

Cokoliv bude klient nad rámec smlouvy požadovat si nechte poslat písemně. Ideálně s potvrzením, že klient bere na vědomí účtování práce na požadavku jako víceprací. Požadavky vzešlé z telefonického hovoru může klient lehce zapřít. Stejně tak požadavky vznesené ústně na kontrolní schůzce, pokud z ní není pořízen zápis, který klient podepíše.

Dejte si taky pozor, aby vám takovou práci zadal vždy ten, kdo je k tomu oprávněn podle smlouvy nebo ze zákona (detailně rozebíráme v kapitole Smluvní strany). Jinak budete těžko po klientovi vymáhat peníze za práci navíc.

10 Právo auditu

Jako developeři pracující pro menší studia audit většinou ve smlouvě vůbec řešit nebudete. U zakázek pro vládní orgány se s ním setkáte spíše a povětšinou o něm nebudete moci vyjednávat. Právo auditu umožňuje zákazníkovi nahlížet vám pod ruce – do účetnictví, provozu, posuzovat soulad s bezpečnostními požadavky zákazníka nebo zabezpečením osobních údajů. A mnohdy zákazník bude chtít, aby se právo auditu vztahovalo i na vaše subkontraktory.

11 Plynulost v poskytovaných službách

Nepředpokládáme, že se naše příručka dostane do rukou největším cloudovým poskytovatelům, pro které je výpadek služeb nebo nedosažení garantované dostupnosti po delší dobu noční můrou.

Některou z forem cloudu ale pro svou práci jistě používáte, ať už napřímo, nebo jej používá váš poskytovatel cloudového code editoru. Proto by vás měla zajímat možnost exportu uložených dat a jejich přenositelnost ke konkurenční službě, stejně jako jejich interoperabilita s dalšími systémy. Dále zálohování – automatická denní záloha vaší práce je téměř nutnost a cloudoví poskytovatelé ji často za příplatek zajišťují. Pokud služba zálohuje vložená data na paralelním serveru, bylo by fajn se ujistit, že pokud ji opustíte, záloha se k vám dostane. Nebo že ji máte možnost kdykoliv v průběhu stáhnout k sobě. Ze zkušeností víme, že zálohování dat poskytovatelem cloudu není samozřejmostí. Proto se už před zaplacením předplatného na první měsíc ptejte, co se stane s mými daty, když datacentrum vyhoří?

12 Odměna

Odměna je to, o co vám v konečném důsledku jde. Proto musí být ve smlouvě ošetřena co možná nejdůkladněji. Pokud tuto pasáž podceníte, tak mohou nastat třeba i takové situace, kdy je práce z vaší strany hotová, ale přesto byste nemuseli být úspěšní při vymáhání odměny přes soud. Kdy se to může stát? Třeba když je vznik nároku na odměnu navázaný na protokolární předání a vy jste jaksi žádný protokol nedělali. Že je to nespravedlnost? Ale jak potom chcete soudu dokázat, že máte předáno a nárok na odměnu vznikl? Těžko.

Jak jsme už nakousli v části o předmětu smlouvy, odměna může být buď sjednána za výsledek nebo za čas, což se odvíjí právě od typu uzavírané smlouvy. Můžete se setkat také s cenou podle rozpočtu – tady je důležité vědět, že není rozpočet jako rozpočet. Dá se totiž sjednat jako úplný (a tedy závazný a neměnný) i nezávazný (s možností doúčtovat nezahrnuté práce nebo zvýšit cenu v případě, že práce byly náročnější, než se čekalo). Pokud není nic bližšího stanoveno, jde o rozpočet zaručený a úplný. V případě nezávazného či neúplného rozpočtu pozor na limit zvýšení ceny o více než 10 %, to dává klientovi možnost od smlouvy odstoupit. Také je nutné, abyste ihned o plánovaném překročení rozpočtu informovali klienta. Pokud se totiž klient takové překvapení dozví až z faktury, nemáte na peníze navíc nárok.

Velmi doporučujeme nechat si platit předem, nebo alespoň průběžně s postupem prací. Velmi často se totiž stane, že se při odevzdání práce klientovi jaksi zrovna nedostává peněz a začne zkoušet různé obstrukce.

I pokud zvolíte průběžné platby, nemáte vyhráno. Dejme tomu, že na projektu máte pracovat 3 měsíce, od dubna do června, jste placení od hodiny a peníze máte dostávat vždy po měsíci práce na základě faktury se splatností 14 dnů. V dubnu se věnujete výhradně tomuto projektu a se třemi kolegy na něm strávíte každý 180 hodin práce. 5. května vystavíte fakturu na 540 hodin práce a dál na projektu s nasazením makáte. Splatnost uběhne 19. května a peníze nikde. Hned klientovi píšete mail, kde máte peníze. Klient obratem odpoví, že to zadával k platbě, ale že to teda prověří.

25. května mu píšete znovu, klient nereaguje. Za květen jste odpracovali už 400 hodin a přicházejí obavy. Klientovi denně voláte a koncem května přestanete na projektu pracovat. Dva měsíce v háji, tři čtvrtiny projektu hotové a klient se rozmyslel, že vlastně z projektu nic nebude, ale jaksi vám to neřekl. O zaplacení provedené práce se pak budete dohadovat měsíce a soudit roky. Mezitím klient zkrachuje a nedostanete z něj už nikdy nic.

Stejné scénář, jiný závěr: Je konec května. Vy jste si řekli, že dál zadarmo pracovat nebudete a přestali na projektu dělat. Vystavili jste fakturu za květen na dalších 460 hodin

a uvažujete, co dál. Klient z ničeho nic 25. června obě faktury uhradí a ve vás hrkne. Za 5 dnů je termín pro předání, vy máte nasmlouvané jiné zakázky a tohle fakt dodělat nezvládnete. S oroseným čelem listujete smlouvou k části o smluvních pokutách. 0,5 % denně z ceny díla za každý den prodlení. To na první pohled nevypadá hrozivě. Spočítáte si, že s ohledem na ostatní zakázky to ale nestihnete dřív než v půlce srpna. To je 45 dnů prodlení, tedy pokuta 22,5 %. To je už najednou dost.

Proto doporučujeme tři věci: vzít si zálohu, do smlouvy napsat, že v případě prodlení s platbou přestáváte okamžitě pracovat a (minimálně) o dobu prodlení se prodlužují všechny budoucí termíny smlouvy a pro případ déle trvajícího neplacení možnost smlouvu vypovědět s tím, že dosud provedená práce bude vyúčtována v poměrné výši.

Silnějším řešením, které se u větších společností ukázalo jako nezbytné, je zrušit v případě prodlení klienta celý harmonogram a dát vám právo nový harmonogram určit jednostranně. A tak při prodlení 14 dnů můžete stanovit nový termín 15. listopadu. Proč se uchylovat k tak drastickým opatřením? Protože vám chybí 14 dnů práce, ale celý červenec máte naplánovanou dovolenou s rodinou, v srpnu jinou zakázku a od září do října další zakázku. Pak byste kvůli prodlení klienta buď museli zrušit dovolenou nebo zpozdit další dvě zakázky. Proč by měl nést následky klientova prodlení kdokoliv jiný než právě ten klient?

Pokud jde o hodně peněz a klient odmítá platit, než uvidí výsledek, dá se použít úschova (advokátní, notářská, bankovní). To vám zaručí, že peníze jsou pro vás připraveny a klient na ně nemůže, a klientovi zase zaručí, že se k penězům nedostanete dříve, než práci dokončíte.

Praktický problém je DPH. Pokud jste plátci DPH, určitě víte, že DPH musíte platit i z vystavených daňových dokladů, které vám zatím nikdo nezaplatil. To pro vaše cash flow není úplně nejlepší, a to ani když klienti platí včas, natož když nezaplatí vůbec. Pokud jste obchodní společnost, tak to dost podobně funguje i s daní z příjmů. Takže ano. Když vystavíte daňový doklad na 200 tisíc Kč + DPH a klient nezaplatí, vy nejen že nedostanete zaplaceno za odvedenou práci, ale navíc budete muset zhruba do měsíce odvést 42 tisíc Kč na DPH a po skončení roku na dani z příjmů ještě 38 tisíc. Jak z toho ven? Nevystavujte daňové doklady dřív, než ze zákona musíte. Jako podklad k platbě vystavujte zálohové faktury (také se jim říká proforma, tedy že jsou jen aby se neřeklo, aby se peníze nepřeváděly jen tak bez nějakého podkladu). O těch se účtuje až v okamžiku, kdy jsou zaplacené. Xxx musíte sice obratem daňový doklad vystavit, ale to už vám nevadí, protože peníze máte, i na ty daně. Je to sice dvakrát tolik administrativy, ale minimálně u větších zakázek se to vyplácí. Tento postup je určitě třeba do smlouvy napsat. Jinak totiž platí, že na odměnu vám vznikne nárok až při splnění smlouvy. Často si lidé myslí,

že rozhoduje splatnost, kterou napíší do faktury, ale není to tak. Rozhoduje to, co je ve smlouvě. S fakturou za dílo vystavenou dříve, než dílo dokončíte, u soudu neuspějete, pokud nebudete mít ve smlouvě sjednáno, že na tu fakturovanou částku máte nárok už teď.

K zálohovkám jedna technická poznámka: zálohovky se nedají použít v případě, kdy už nastal den uskutečnění zdanitelného plnění (DUZP). Kdy to je, záleží na druhu služby. A zákon je v tomto směru docela složitý. Pak máte povinnost vystavit daňový doklad do 15 dnů. Aniž by vás finančák zkontroloval, nemá ale moc reálnou šanci ověřit, kdy den uskutečnění skutečně nastal.

Další možností je stanovit si dílčí cíle a odměnu navázat na jejich dosažení. Dosažení dílčího cíle je většinou provázeno prezentací dokončení příslušného milníku klientovi, který práci potvrdí a odsouhlasí její aktuální stav. Má to přínos i pro vás, jelikož při správné textaci potvrzení máte v ruce jistotu, že ta část, kterou jste prezentovali, se klientovi líbí a nemůže ji v budoucnu rozporovat.

13 Když se něco pokazí

13.1 Odpovědnost za vady vs. záruka

Odpovědnost za vady a záruka nejsou totéž. Vlastně se dá říct, že záruka jako taková se dá použít jen u zboží a díla a znamená, že garantujete, že ono zboží nebo dílo bude po nějakou dobu fungovat, jak má. Pokud napíšete, že poskytujete záruku 2 roky na svou aplikaci, vyvolá to akorát spory o to, co jste tím vlastně mysleli. Klient bude jistě čekat víc, než tím myslel zhotovitel. Když vaše webová aplikace nepoběží na novém prohlížeči od Avastu, je to věc, co máte v rámci záruky řešit? Obecně pro IT nepovažujeme poskytování záruky za šťastné řešení a naprosto postačuje vyjasnit odpovědnost za vady. Pokud už na záruce trváte, pak je důležité přesně stanovit, co má být jejím obsahem.

V praxi budete častěji řešit zda to, na čem pro klienta pracujete, odpovídá tomu, co jste si domluvili. Pokud neodpovídá, pak má zákazník na něco právo. A jsme zpátky u předmětu smlouvy. Pokud je jejím obsahem obstarání nákupu SSL certifikátu, tak se řeší, zdali jste nákup obstarali. Jde v podstatě o příkazní smlouvu a v případě, že se výsledek nedostaví, tak se bude zkoumat, kdo za to může. Pokud by se SSLka prostě přestala prodávat, stejně by za tu snahu musel objednatel zaplatit.

Pokud máte poskytovat hosting s nějakými parametry, tak se řeší, zda jsou parametry splněny. Doporučujeme do smlouvy napsat, co a kdy po vás může zákazník vlastně chtít, když objednaným parametrům nedostojíte. Xxxxx se s ním akorát rozhádáte a buď mu zbytečně ustoupíte, abyste si ho udrželi, nebo budete tvrdí a on od vás nejspíš odejde. Hosting nabízí kdekdo.

Vývojáři to mají o něco složitější. Smlouvy bývají často zbastlené a není snadné identifikovat, o jakou smlouvu se jedná. U smlouvy o dílo může být dílo vadné a řešíte zákonem celkem precizně popsaná práva z vadného plnění. U smlouvy příkazní je ale vývojář placen za úsilí, i když se výsledek nedostaví. Spíše, než za nefunkční aplikaci přijde sankce za porušení např. povinnosti vývojáře jednat s odbornou péčí. A pouštět se do toho, co všechno do odborné péče spadá? O tom se nechcete hádat ani s klientem, ani se soudcem. To si radši hoďte mincí, protože šance na úspěch jsou dost podobné. Správná textace smlouvy je stěžejní.

13.2 Náhrada škody, smluvní pokuta

Klientovi můžete zničit data (třeba když shoří nezálohovaný disk nebo když ho někdo omylem přeformátuje). Nebo jako subdodavatel nestihnete něco v termínu dodat a klient díky tomu musí zaplatit smluvní pokutu. Při nepovedené aktualizaci eshopu může klient-e-shop přijít o část tržeb. Obecně platí, že

pokud způsobíte škodu, budete ji muset nahradit. A nebývá výjimkou, že hrozící škoda mnohonásobně převyšuje cenu, kterou vám za vaše služby klient zaplatí.

Co s tím? Zákon na vás sice trošku myslí a říká, že nepředvídatelná a nepřekonatelná překážka vzniklá nezávisle na vaší vůli vás povinnosti k náhradě škody zprostí (tzv. vyšší moc). Také nebudete odpovědní za obecně nepředvídatelné škody.

U toho si vždycky vzpomeneme na přednášku prof. Xxxxx z obchodního práva. Zpožděná dodávka krabičky špendlíků do jaderné elektrárny způsobila, že neměli čím přišpendlit rozpis směn, a tak se stalo, že do práce nedorazil vedoucí provozu. Sice zasouval a vysouval, ale někde úplně jinde a něco jiného, než uranové tyče. A jeden jaderný blok celých 12 hodin nefungoval. Mohl obchod se špendlíkama něco takového předvídat? Těžko.

Náhradě škody se ve smlouvě doporučujeme věnovat podrobněji a upravit si alespoň limitaci výše škody, která díky tomu nevyroste do astronomických výšin.

Vedle nebo namísto náhrady škody se sjednává smluvní pokuta, která nezávisí na tom, jestli nějaká škoda vůbec vznikla. Stačí, že nebyly dodrženy podmínky smlouvy.

Věty typu smluvní pokutou není dotčeno právo na náhradu škody chrání jen poškozeného. A pozor na smlouvy, které se

neřídí českým právem (typicky s velkým zahraničním partnerem). V některých právních řádech je totiž smluvní pokuta zakázaná.

Pokud je pro podobnou situaci váš krizový plán položím firmu a založím si novou, i to funguje, i když pouze u právnických osob, ale není to zrovna čestné řešení. Náklady na založení nového s.r.o. většinou nepřekročí 20 tisíc Kč, což je v porovnání s povinností platit náhradu škody v řádu milionů celkem velká motivace. Musíte ale přitom počítat s tím, že přijdete o veškerý majetek společnosti a také s tím, že bude ohrožena vaše reputace.

Opatrně ale, abyste nezanedbali povinnost péče řádného hospodáře a případné insolvenční řízení je pohádka sama pro sebe.

13.3 Pojištění

Vyžaduje po vás klient pojištění? Nebo jste to vy, kdo se raději pojistíte, kdyby něco? Tak či tak, na českém trhu aktuálně není žádná pojistka, která by skutečně kryla podnikatelská rizika, která při poskytování IT služeb nesete. A ani tak nejde zrovna

o levnou záležitost. Často najdete ve výlukách z pojištění škodu vzniklou prodlením, porušením práv duševního vlastnictví, v důsledku nefunkčního software, neautorizovaným přístupem apod. Což je přesně to, co v IT vývoji hrozí nejčastěji.

14 Informační bezpečnost

V průběhu spolupráce s klientem si budete předávat řadu hodnotných informací. I ve zcela základních vztazích se na jedné straně dozvíte o fungování klienta a na straně druhé klientovi poskytnete své know-how. Ochranu hodnotných informací každého z nás napadne řešit nějakou formou mlčenlivosti (třeba NDA3) nebo se spoléhat na zákonnou ochranu obchodního tajemství. Pravda je ale taková, že ve většině smluv se strany zavážou akorát k tomu, aby držely jazyk za zuby, nějaké té smluvní pokutě nebo náhradě škody, a tím to končí.

Začátek dobrý. Ale je třeba zhodnotit, jakou klientovi poskytujete službu a k čemu se ve smlouvě zavazujete. Právě na rozsahu jednotlivých povinností se může lámat chleba. A pokuty za porušení povinností ve vztahu k obchodnímu tajemství a dalším chráněným informacím často dosahují takové výše, že se na zakázce rázem dostanete do mínusu. Přestože jsou klauzule vágní, jedno mají společné. Klient se vás pokusí zavázat v maximálním možném rozsahu. Což nechcete.

Ze strany klienta můžete například očekávat, že pokud vám poskytuje přístup do vlastních systémů a přístupové údaje uniknou ven, první na ráně budete vy. Domluvte si proto detailní způsob předání. Co si budeme povídat, není úplně

3 NDA je označení pro dohodu o mlčenlivosti (Non-Disclosure Agreement).

nejšťastnější zasílat přístupy přes WhatsApp nebo mailem někomu z administrativy. Následná práce s informacemi je na tom podobně. Máte pracovat na zařízení klienta? Sjednejte si, jak má taková spolupráce vypadat (zálohy, aktualizace, vrácení, odpovědnost za ztrátu atd.). Jsou informace ve formě dat nahrány v některém z vašich systémů? Dohodněte se na tom, kdo z vašich kolegů, a za jakých podmínek, k nim může přistupovat.

Neméně důležitá otázka pak je, co vás takové porušení bude stát. Čím vágněji vzájemná práva a povinnosti ve smlouvě upravíte, tím spíše hrozí nějaký spor z důvodu, že se vaše vzájemné představy neprotnuly. Detailnější kontrakt vám naopak umožní nastavit sankce přiléhavěji, abyste se nemuseli bát, že vás sebemenší blbost položí. Ale s rozumem. Nezavazujte se k něčemu, co nemůžete splnit. Právě naopak, pokud něco prostě nedáte, bude lepší to do smlouvy promítnout předem.

Důsledky nedostatečné ochrany informací se ale projeví i jinde. Připravujete pro klienta e-shop? Nezapomeňte si sjednat konkrétní požadavky na webovky. Klienta by mohlo nemile překvapit, až se od GoPay dozví, že mu nezprovozní platební bránu, protože nepoužívá zabezpečený webový protokol. Vyvíjíte pro klienta online aplikaci? Dohodněte si předem způsoby ochrany přítomných informací (řízení přístupů, šifrování, logování atd.). A nezapomeňte ani na penetrační

testy. Ušetříte si tím spoustu problémů a nedorozumění v budoucnu (čas dodání, odměna, vícepráce a další).

Pokud se má poskytnutá služba točit z velké části kolem dat, nebo je pro vás práce s daty obživou, ať už je analyzujete nebo se jakkoli jinak pohybujete v rámci rostoucího Data-as-a-Service rybníčku, bude potřeba věnovat této problematice ještě o level větší pozornost (ale k tomu blíže v další kapitole).

15 Ochrana dat

Při poskytování služeb v IT tečou mezi vámi a vaším klientem data. A ta mají pro různé aktéry různou ekonomickou hodnotu. Jasně, hlavní hype se ještě stále točí kolem osobních údajů, ale aktivem jsou všechna data. A jak teda máte svá data chránit?

Zaprvé je vhodné ošetřit technickou stránku věci. Problém je, že ani sebelepší zabezpečení vás zcela neochrání před někým, kdo k ostrým datům pravidelně přistupuje – třeba vaším klientem. Tím samozřejmě nechceme říct, že informační bezpečnost není důležitá. Naopak, právě díky ní eliminujete většinu potenciálních rizik a zachováte svá (alespoň faktická) oprávnění k datasetům. Chytře vyřešená enkrypce např. zajistí, že se k nezašifrovaným datům orgány činné v trestním řízení nedostanou ani když přijdou za vaším cloud providerem. Je ale záhodno věnovat pozornost i právní stránce věci.

Nepříjemné je, že právní ochrana dat je, kulantně řečeno, jeden velký binec. Data nemůžete v pravém slova smyslu vlastnit, a pokud je chcete chránit, musíte se poohlédnout jinde.

Aniž byste si cokoliv sjednali ve smlouvě, data lze chránit pomocí obchodního tajemství, což ovšem dopadne jen na tu část dat, které tajemství obsahují. Data mohou být dále chráněna pomocí copyrightu, ale pakliže se nezabýváte např.

distribucí chráněných děl, tak vám tato varianta moc nepomůže. Další možností je chránit celý soubor dat, nebo jeho jednotlivé části, jako tzv. sui generis databázi. Výhodou oproti standardnímu copyrightu je, že k poskytnutí ochrany postačí podstatný kvalitativní nebo kvantitativní vklad při jejím pořizování, tedy ne nezbytně nutně finanční. Kreativní prvek potřeba není.

Pokud vás ale data živí, nebo pro vás prostě jen mají obrovskou cenu, tak na výběr taky úplně nemáte. Nejbezpečnější je pak zatnout zuby a pustit se do sepsání takového kontraktu, který upraví vaše vzájemná práva a povinnosti do nejmenšího detailu, tj. povolené/zakázané procesy nakládání s daty; účely nakládání s daty; povinnosti týkající se zabezpečení datasetů (jak technická, tak organizační opatření); specifikace práv z duševního vlastnictví (ať už databázová nebo jiná); kombinování dat; práva k odvozeným informacím/databázím; práva na zveřejnění derivovaných informací/databází apod.

16 Ochrana osobních údajů

Zaprvé je třeba říct, že ne každý IT kontrakt bude nutně zahrnovat práci s osobními údaji. Pokud nezahrnuje, nemusíte se problematikou zabývat, a klidně tuto část přeskočte. Ale pozor, u rámcových smluv může vaše povinnost pracovat s osobními údaji vyplavat na povrch až na základě některé z dílčích smluv, tedy v průběhu spolupráce.

Ochranu osobních údajů vnímá spousta společností jen jako další zbytečnou administrativu. A zčásti mají pravdu. Za osobní údaj je totiž možné považovat téměř cokoli, co identifikuje člověka. Nahlížejte na ně ale s rozumem. Nemusíte přijmout stejná opatření jako Google a nehrozí vám ani stejná pokuta. Ale řídit se při práci s nimi alespoň základními pravidly musíte. Ostatně, každý z nás si asi přeje, aby k našemu soukromí ostatní přistupovali s respektem.

Pracujete-li v průběhu spolupráce s osobními údaji, je potřeba tuto skutečnost promítnout do smlouvy. Nelekněte se, pokud budete najednou muset podepisovat více smluv. Pravidla pro práci s osobními údaji mohou být začleněna do původní smlouvy, vyčleněna do smlouvy vedlejší, nebo na ně může být odkázáno, pokud jsou třeba umístěny na webu.

Coby dodavatel se standardně budete nacházet v postavení zpracovatele. Při práci s osobními údaji jste tak vázáni jednotlivými pokyny zákazníka a ve vztahu k pravidlům pro

práci s osobními údaji budete mít omezenou vyjednávací pozici. Nezapomeňte si pak sjednat od koho a jakou formou budete pokyny přijímat.

Zpracování osobních údajů budete většinou provádět bezúplatně, resp. v rámci sjednané odměny, a je proto vhodné zohlednit tuto skutečnost při jejím nastavování. Řadě nedorozumění pak předejdete, pokud jasně definujete, jaká opatření (omezení uložení, geolokace serverů, omezení přístupových práv, pseudonymizace, šifrování a další) ve vztahu k ochraně osobních údajů lze z vaší strany očekávat, případně jaká nová opatření, a za kolik, jste ochotni zajistit. Výjimkou nebývá ani to, že vám zákazník zprostředkuje přístup do vlastních systémů, což celou situaci značně ulehčuje. Ani v tomto případě však není vhodné vzájemné povinnosti ponechat náhodě.

To samé platí i pro rozsah údajů. Pokud k nějakým údajům pro řádné poskytování služby přistupovat nemusíte a nepřistupujete, zbytečně je do smlouvy nezahrnujte. Úplně ideální je pak práce na vzorovém datasetu bez nutnosti zpřístupnění ostrých dat.

Neméně důležité je pak předem určit, které osoby nebo společnosti vám budou při práci s osobními údaji pomáhat. Může se totiž klidně stát, že zákazník odmítne zapojení některého z vašich stěžejních subkontraktorů, což vám znemožní efektivně a včas poskytnout službu. Dejte si proto

pozor na to, jakým způsobem a za jakých okolností (ne)budete odpovědní.

17 Copyright a patenty

Při programování sice pro zákazníka nevytváříte hmotný produkt, ale v žádném případě to neznamená, že je právně bezprizorní. Naopak, jedná se o předmět chráněný právem duševního vlastnictví.

Software je pod ochranou copyrightu, pokud je programátorovým vlastním duševním výtvorem. Tady spadají zpravidla veškeré počítačové programy (mobilní aplikace, webové stránky nebo operační systémy). Programátor je autorem, stejně jako je hudební skladatel autorem skladby. Proto neexistuje živnostenské oprávnění na činnost programování. Což má i daňové konsekvence. Pokud jste placeni za udělenou licenci k software a používáte výdajový paušál, měli byste uplatnit jenom 40% paušál. Zatímco pokud vás klient platí za práci a licenci poskytujete bezúplatně, výdajový paušál je 60 %. To je dobré mít na paměti. Pokud programujete na zakázku, je daňový režim přívětivější.

V takovém případě totiž ani licenci poskytnout nemůžete, protože výkon majetkových práv přechází rovnou na vašeho zákazníka a ten s nimi může nakládat téměř dle své libosti. Pokud ale právo výkonu nepřechází, je potřeba specifikovat nakládání s kódem právě v licenci. Kdo může kód upravovat nebo dokončit, jestli jej může objednatel použít v jiném software nebo kdykoliv prodat dál a udělit podlicenci. Nebo

jestli na něm můžete dál pracovat i mimo spolupráci

s klientem. A to je jen zlomek věcí, které by měla licence řešit.

Z praxe víme, že společnosti ani programátoři nemají příliš jasno v tom, kdo vykonává práva k software a kdo si za něj v důsledku může nechat zaplatit.

Copyright způsobuje, že je potřeba dívat se i na tzv. práva třetích osob. Pro zjednodušení není potřeba vždycky psát kód od nuly a často si vystačíte s modulem opatřeným některou z veřejných licencí (GNU GPL, BSD nebo MIT licence). Ty ale mohou zakazovat komerční užití, což v kombinaci s copyleftovou doložkou, která přikazuje použít stejné licenční podmínky při distribuci vámi vytvořeného kódu, může způsobit, že byste jej vůbec neměli použít v software placeném zákazníkem.

Ve smlouvách se můžete setkat i s nesmyslnými požadavky, že jste povinni zákazníkovi ohlásit veškerá díla, která mohou být chráněna jako duševní vlastnictví a případně jste povinni je na něj převést. Pod smluvní pokutou samozřejmě. Za prvé, software může být chráněn v některých zemích patentem (a patent je duševní vlastnictví) a i málokterý český, byť zkušený, patentový zástupce by si troufl posuzovat patentovatelnost software v jiné zemi, protože to překračuje jeho kompetence i odbornost. Stěží to zákazník může chtít po vás. Za druhé, autorské právo je nepřevoditelné a nikde se neregistruje, proto ani druhému požadavku nedostojíte,

protože je nesplnitelný. A smluvní pokuta je na světě. Podobným ujednáním je potřeba se vyhýbat. Na obranu zákazníků dlužno říci, že úmyslem většinou není zlikvidovat partnera smluvními pokutami, ale k nesmyslným ujednáním ve smlouvách vede spíše všeobecná neznalost duševního vlastnictví v IT těch, kdo smlouvy připravují.

18 Subdodavatelé

Velkou část služby poskytujete přes někoho nebo alespoň s něčí pomocí. Na jednom projektu se tak podílí hned několik na sobě nezávislých (sub)dodavatelů, a vztahy mezi nimi je potřeba nějak korigovat. To, že s těmito subdodavateli pracujete roky, na tom nic nemění. Jsou to pořád externí osoby.

Čím víc pomocníků máte, tím větší máte (z)odpovědnost, a proto si musíte pečlivě vybírat. Základem je vždy vycházet ze smlouvy, na jejímž základě poskytujete služby. V ideálním případě jste se domluvili na konkrétních subkontraktorech, nebo alespoň na způsobu jejich výběru a schvalování klientem. U toho se ale nezastavujte.

Zavázal vás klient k mlčenlivosti? Potřebuje data zachovat v rámci EU? Pak musíte upravit i dohodu se subdodavateli. Nezapomínejte ani na úpravu copyrightu. Nesprávné užití veřejných licencí vašimi subkontraktory může celou vaši práci znehodnotit.

Pamatujte na to, že odpovědnost vůči klientovi máte primárně vy. Zákon sice obsahuje podpůrná pravidla, která zakládají přímou odpovědnost subkontraktorů, nicméně v době, kdy už vašemu zákazníkovi vznikla škoda, je většinou pozdě. Ustanovení o smluvní pokutě a náhradě škody už se aktivovaly a vaše renomé utrpělo ránu.

Pokuste se nastavit vzájemné vztahy preventivně tak, aby se vašim pomocníkům nevyplatilo dělat jakékoli obstrukce. Abyste mohli spolupráci ukončit a najít si náhradu na náklady původního. Jestli nakonec risknete, že se nezodpovědný subdodavatel zmátoří a svůj díl práce řádně dodá, nebo naopak to, že sice najdete nového, ale možná nestihnete termín, už bude na vás a vašem podnikatelském úsudku. Ale nejdříve musíte do smlouvy patřičná zadní vrátka dostat.

Xxxxx zároveň v úvahu, že vy sami pravděpodobně často vystupujete v pozici subkontraktorů. Zkuste se tedy nad shora uvedenými problémy zamýšlet i z této strany a operovat s nimi i tam, kde jste vy tím posledním článkem řetězce.

19 Mezinárodní okénko

Pokud smlouvu sjednáváte se zahraničním partnerem, vyvstává otázka tzv. rozhodného práva a sudiště. Xxxx otázka, jakým právním řádem se bude smlouva řídit a který soud bude případné spory řešit. Věc, na kterou se musí právník dívat jako první.

Částečně tušíte, jak funguje české právo, ale pravděpodobně si moc neumíte představit, co za pasti si na vás může přichystat právo jiných států. V příručce už zaznělo, že některé státy třeba zakazují smluvní pokuty. Třeba Velká Británie.

A co teprve smlouvy s Čínou, Ruskem, arabskými zeměmi? Pokud chcete po českém advokátovi, aby vám zkontroloval smlouvu, která se řídí cizím právem, měl by odmítnout. Nebo vás minimálně upozornit, že jeho kontrola vám dává podobnou úroveň jistoty, jako byste vy kontrolovali zdroják v jazyce, který neumíte. Navíc žádná pojistka právníka v tu chvíli nekryje, protože dělá něco, na co odborně nestačí.

Se sudištěm to je taky veliká zábava, zvlášť v situacích, kdy je příslušný soud v jiné zemi, než jaké je sjednáno rozhodné právo. Vyvíjíte aplikaci pro klienta z USA a klient vás žaluje o slevu. Ve smlouvě máte sjednáno, že příslušný je soud v Louisianě. Znáte tam nějakého právníka, který za vás k tomu soudu půjde? A kolik asi může takový právník stát? I nad tím je třeba se zamyslet.

Když už jsme u sudiště, často smlouvy obsahují tzv. rozhodčí doložky, které přesměrují spor ze soudu do arbitráže. A rozhodčí soud není obecný soud. A neřídí se stejnými pravidly jako soud. Na druhou stranu, pro IT spory existují instituce (třeba ADR oddělení WIPO), které díky své specializaci zvládne mezinárodní spor vyřešit rychleji, lépe a mnohdy i levněji. Jednoduchá rada zní, na rozhodčí soud kývněte jen v situaci, kdy jej znáte a víte, jak u něj řízení probíhá.

20 Elektronické podepisování

Smlouva ≠ papír.

Pokud byste si měli z naší příručky zapamatovat jedinou, zato důležitou věc, ať je to tahle jednoduchá poučka. Smlouva nemusí být nutně papírová. Respektive, velmi malé procento z těch, které každý z nás uzavíráme, na papíře musí být.

Přijde vám poptávka do messengeru, odsouhlasíte si cenu a termín a začínáte pracovat? Nebo si ji potvrdíte telefonicky? Velmi pravděpodobně máte uzavřenou platnou smlouvu. Asi vás napadne, k čemu vám pak jsou všechny rady o odměně, mlčenlivosti nebo duševním vlastnictví, které jsme popisovali na předchozích stránkách. K tomu, aby smlouva maximálně hrála ve váš prospěch.

Mít podmínky spolupráce černé na bílém je k nezaplacení. Ale neznamená to tisknout je do dvou kopií a nahánět smluvního partnera pro vlastnoruční podpis, pokud to zákon nevyžaduje. Jakože u IT kontraktů vyžaduje v některých případech písemnost (např. u výhradní licence k software), ale nikoliv papírovou formu. A elektronická je pořád písemná.

Jenom je potřeba splnit dva požadavky – zachytit obsah (tedy mít podmínky spolupráce černé na bílém) a určit smluvní strany.

Obsah zachytíte tím, že text smlouvy vložíte přímo do těla e-mailu, přiložíte v .pdf nebo jej uploadnete na webovou stránku a zašlete link a od smluvního partnera si vyžádáte e-mailovou odpověď, že s textací souhlasí. Nebo odklikne aktivní políčko v těle e-mailu. Jasně, rozporovat se dá cokoliv – že jste textaci na webové stránce v průběhu změnili nebo že jste přiložili jinou přílohu. Proto si archivujte nejenom odpověď nebo kliknutí na aktivní pole včetně IP adresy a časového razítka smluvního partnera, ale i vaši odchozí zprávu včetně hlavičky e-mailu. V soudních sporech se nám takový důkazní materiál několikrát vyplatil.

Zároveň byste měli vědět, s kým jednáte. Nepodepsaná odpověď z infomailu, ačkoliv akceptující znění podmínek bez výhrad, není to, čeho byste měli chtít dosáhnout. Odpověď z e-mailové adresy konkrétní osoby navíc s připojeným přednastaveným podpisem je o dost lepší. V ideálním případě chtějte přiložit scan podpisu do .pdf s potvrzením o akceptaci do e-mailu.

Na úrovni celé EU totiž platí pravidlo, že data, která jsou připojena k jiným datům v elektronické podobě, jsou s nimi logicky spojena a daná osoba je používá k podepsání, jsou jedním z typů elektronického podpisu. A fakt, že jsou elektronická, by jim nemělo upírat právní účinky oproti papírovým smlouvám.

Výše popsaný postup by měl být nejnižším standardem, který budete v praxi používat. Pak už můžete jít jenom výš používáním zaručeného nebo kvalifikovaného elektronického podpisu. Nebo užíváním online služeb, které by měly poskytnout garanci o identitě elektronicky se podepisující osoby.

Závěrem

Právě jsme vám vyzradili to nejpodstatnější, co víme

o uzavírání smluv pro digitální podnikání.

Vše ostatní se zvládnete dočíst v zákonech nebo odborných článcích. Snažili jsme se ale přenést interní know-how,

o kterém se nepíše.

Budeme rádi, když nám napíšete na xxxx@xxxxxxxxx.xx, jak se nám to povedlo. Nebo pokud by vás něco dalšího zajímalo, rádi poradíme.

Díky za váš čas

Xxxx, Xxxxxx a Xxxxx

SimpleLaw

Document Metadata

Table of Contents

Smlouvy pro digitální podnikání

Document Metadata