Pokud jste někdy řešili IT dodávku, možná jste narazili na problémy se smlouvou (nebo o nich zatím nevíte). Pochopitelně nejlepší je smlouvu vyřešit s Vaším právníkem, ale klienti často neví, na co se jej vlastně mají zeptat. V tomto seriálu vás naučím, na co se ptát druhé strany a svého právníka, abyste obdrželi lepší výsledky.

Co je to vendor lock-in? A stačí vám získat zdrojové kódy k software tak, abyste se do vendor lock-inu nedostali? To se dozvíte v dnešním dílu smluv v IT.

Co je to vendor lock-in?

Vendor lock-in znamená závislost zákazníka (uzamčení, anglicky „lock-in“) na konkrétním dodavateli (anglicky „vendor“), která se projevuje tím, že zákazník nemůže jednoduše přejít k jinému dodavateli bez vynaložení nepřiměřených nákladů nebo úsilí. K závislosti zásadně dochází v důsledku jedné, nebo kombinace více z následujících skutečností:

a)     využití nekompatibilních technologií,

b)     využití proprietárního duševního vlastnictví,

c)     technologický dluh,

d)    nedostatek dokumentace.

V případě obchodních vztahů, jejichž předmětem je dodávka software nebo poskytování cloudových služeb, včetně Software as a Service, se vendor lock-in většinou projevuje tak, že zákazník je nucen využívat zastaralé, předražené nebo svými parametry nevyhovující služby dodavatele, protože si nemůže dovolit přejít k dodavateli jinému. Dodavatel této situace zpravidla využívá, a to nejméně tím, že o zákazníka a jeho potřeby nepečuje tak, jak by o ně pečoval při standardním tržním nastavení vzájemných vztahů. Dodavatel jednoduše ví, že ať se bude k zákazníkovi chovat jakkoliv, zákazník nepřestane využívat jeho služeb a bude mu dále platit.

V Česku se většina článků zabývá vendor lock-inem ve veřejných zakázkách. Tento problém se však dotýká také obchodních společností v sektoru soukromém. Typicky řeším případy, kdy klient na základě historických smluv zakoupil nějaké softwarové řešení, není spokojený se stávajícím dodavatelem, ale nemá technologie, licence ani dokumentaci k tomu, aby předal správu a další rozvoj řešení dodavateli jinému. Současně takový klient často nemá finanční nebo personální zdroje, aby si mohl dovolit nákup řešení nového.

Zachrání mě výhradní licence a zdrojové kódy? Ne.

Dostaňme z cesty jednu zažitou nepravdu: zdrojové kódy k software ani výhradní licence vás neochrání před vendor lock-inem.

Za prvé. Mít zdrojové kódy neznamená nic jiného, než mít možnost „zvednout kryt motoru“, v tomto případě software, a vidět na jeho jednotlivé součástky. Nehovoří ničeho o tom, jestli máte právo software měnit. Není pravda, že právo na zdrojové kódy k software automaticky znamená právo nabyvatele licence software měnit.

Za druhé. Výhradní licence neznamená nic jiného než závazek dodavatele neposkytnout stejná oprávnění k software dalším osobám. Nehovoří však ničeho o tom, o jakém rozsahu oprávnění se bavíme. Blíže jsem se věnoval vysvětlení výhradní licence ve 4. díle Smluv v IT zde.

V konečném důsledku tak může zákazník získat výhradní licenci k software a zdrojové kódy, aniž by měl právo software měnit, natož jej předat k dalšímu provozu a rozvoji jinému dodavateli. Navíc výhradní licence a zdrojové kódy už vůbec neřeší kompatibilitu použitých technologií, kvalitu zdrojových kódů a dokumentaci tak, aby někdo dokázal software dále provozovat a rozvíjet.

Naopak může existovat zákazník, který má nevýhradní licenci k proprietárnímu software bez zdrojových kódů, který však v situaci vendor lock-inu není. Třeba proto, že software a data v něm jsou kompatibilní s produkty jiných dodavatelů a toto je garantováno kvalitní smlouvou a dobrou reputací dodavatele.

Smlouva je má spása

Prevence vendor lock-inu začíná výběrem férového dodavatele s dobrou reputací. Dalším stavebním kamenem je kvalitní smlouva, to je smlouva, která obsahuje potřebné závazky dodavatele, aby se zákazník nedostal do situace vendor lock-inu. Posledním stavebním kamenem je kontrola ze strany zákazníka, že je smlouva dodržována, a to i z pohledu technického. Pokud má například dodavatel psát zdrojové kódy, komentáře a dokumentaci software tak, aby na vývoj a další rozvoj dokázal navázat někdo jiný, je potřeba to kontrolovat dříve než po dokončení a předání díla (pak už může být z pohledu vendor lock-inu příliš pozdě a vymáhání smluvních pokut z porušení smlouvy je slabá útěcha). K tomu je nutná dobrá technická znalost zákazníka, nebo důvěryhodný outsourcovaný technický dozor. Já se dnes budu věnovat té smlouvě—o zbývajících složkách mohou polemizovat povolanější, nebo to uděláme v jiném dílu Smluv v IT.

Co by měla řešit kvalitní smlouva

Jak jsem popisoval výše, ani proprietární software vás někdy nemusí dostat do vendor lock-inové situace. To závisí hlavě na využitých technologiích a jejich kompatibilitě s technologiemi jiných dodavatelů. Nelze tedy zcela paušálně stanovit, co má obsahovat každá softwarová smlouva.

V některých případech bude nutné, aby si zákazník vyhradil právo software měnit (a s tím související zdrojové kódy a dokumentaci), v jiných případech bude stačit garance exportu dat ve formátech kompatibilních s řešeními konkurenčních dodavatelů. Můžu vám však nabídnout soubor otázek, na které s každým klientem při sestavování smlouvy hledáme odpověď. Pro každý obchodní vztah a smlouvu musíte najít takový soubor odpovědí, aby jejich výsledkem byla volnost zákazníka přejít k jinému dodavateli bez vynaložení nepřiměřených nákladů nebo úsilí. Tyto odpovědi je pak nutné vtělit do smlouvy ve formě odpovídajících závazků dodavatele.

Je nutné vyřešit následující otázky:

·      Je software kompatibilní s řešeními konkurenčních dodavatelů?

·      Pokud ano, je nutné, aby zákazník měl právo dále měnit a rozvíjet software, nebo mu bude stačit mít možnost exportovat data a vložit je do konkurenčního řešení, případě stavět na původním software prostřednictvím kvalitních API?

·      Jak je zajištěno, aby výše uvedený stav trval po celou dobu obchodního vztahu mezi zákazníkem a dodavatelem?

·      Pokud řešení kompatibilní není, jaká je jeho plánovaná životnost?

·      Pokud je plánovaná životnost dlouhá, zákazník by zřejmě měl mít možnost software dále měnit a rozvíjet, a to i prostřednictvím třetích osob:

o  Je zajištěno oprávnění zákazníka předat software k dalšímu provozu a rozvoji třetím osobám (novým dodavatelům)?

o  Je zajištěno oprávnění zákazníka software měnit a spojovat s jinými díly?

o  Je zajištěno, aby zákazník za účelem provádění změn a spojování s jinými díly získal zdrojové kódy?

o  Je licence poskytnuta na dostatečně dlouhou dobu (plánovanou dobu životnosti software)?

·      Pokud by zákazník nebo nový dodavatel měl být oprávněn v budoucnu provozovat a rozvíjet software, je zajištěno, aby stávající dodavatel využíval standardní technologie?

·      Pokud by zákazník nebo nový dodavatel měl být oprávněn v budoucnu provozovat a rozvíjet software, jakou dokumentaci a jiné materiály bude zákazník a nový dodavatel potřebovat? Řeší smlouva tvorbu a předávání takové dokumentace zákazníkovi?

·      Pro všechny případy je vhodné, aby smlouva řešila po skončení spolupráce povinnost původního dodavatele poskytnout součinnost nebo i školení zákazníkovi či jeho novému dodavateli, směřující k převzetí a dalšímu rozvoji software. Je toto ve smlouvě vyřešeno?

V závislosti na odpovědích na otázky je nutné připravit takovou smlouvu, aby s nimi byla v souladu. Nejčastěji ve smlouvách upřesňuji licenční práva zákazníka, závazky tvorby a předávání zdrojových kódů a dokumentace, zákaz využití uzavřených a nestandardních technologií a povinnost dodavatele participovat na předávání software jeho nástupci.

Kdybych se měl před závěrem pozastavit u zdrojových kódů a dokumentace, není kód jako kód a dokumentace jako dokumentace. Někdo má kódy a dokumentaci detailní, přehlednou a srozumitelnou, a někdo jiný zase nepořádnou. V IT se někdy používá termín „spaghetti code“, nebo „špagetový kód“. To popisuje situaci, kdy kód je tak nepřehledně strukturovaný, že je fakticky nesrozumitelný. Analogicky je možné toto aplikovat také na dokumentaci. Vyjednat si pro sebe takový kód a dokumentaci je pak spíše prohra, protože z pohledu prevence před vendor lock-inem skoro nic neřeší (neumožňuje na ně navázat), ale ještě za ně jako zákazník zpravidla musíte zaplatit. Pokud tedy na základě odpovědí na výše uvedené otázky vyhodnotíte, že pro sebe nebo zákazníka potřebujete kód a dokumentaci, doporučuji ve smlouvě vyřešit také jaké minimální standardy jejich tvorby má dodavatel dodržovat. A na to už zase navazuje, že to jako zákazník musíte následně průběžně kontrolovat.

Závěr

Prevence vendor lock-inu začíná výběrem férového dodavatele s dobrou reputací a končí průběžným dohledem zákazníka nad dodržováním podmínek smlouvy, včetně podmínek technických. Mezi těmito dvěma stavebními kameny navíc musí existovat kvalitní smlouva. Každá kvalitní smlouva by měla ošetřit právní a technologické aspekty softwarové dodávky, bránící vendor lock-inu. Neexistuje žádná univerzální kvalitní smlouva, ale v závislosti na okolnostech každého případu by smlouva měla vyřešit aspoň odpovědi na otázky, popsané výše v tomto článku. Jedná se zejména o (i) použití standardních technologií, (ii) dostatečně otevřenou licenci, (iii) kvalitní zdrojové kódy a dokumentaci pro nástupce dodavatele a (iv) školení a součinnost původního dodavatele při předávání software nástupci dodavatele.

Předchozí díly našeho seriálu o smlouvách v IT naleznete zde:

#1 Smlouvy v IT: O co ve smlouvě vlastně jde?

#2 Smlouvy v IT: Cenové modely

#3 Smlouvy v IT: Záruka za dílo

#4 Smlouvy v IT: Výhradní nebo nevýhradní licence

#5 Smlouvy v IT: Software as Service

(Photo by iMattSmart on UNSPLASH).

‍