Právní aspekty ověření zdrojových kódů softwaru
Ověření zdrojových kódů softwaru bývá požadavkem objednatele softwaru v návaznosti na uložení kódů do úschovy.
Escrow neboli úschova zdrojových kódů slouží objednateli k uspokojení jeho zájmu na zachování kontinuity vývoje a servisu softwaru pro případ, že dodavatel nebude schopen z jakýchkoliv důvodů toto zajistit. Současně tak dodavatel vyhoví složením zdrojových kódů do úschovy třetí osoby (schovatele) i vlastnímu zájmu na ochranu zdrojových kódů před zneužitím. Ověření se pak děje ve vztahu ke zdrojovým kódům softwaru, který je dodán objednateli a zdrojovým kódům, které jsou složeny do úschovy. Ne vždy totiž panuje stoprocentní důvěra mezi dodavatelem a objednatelem ohledně toho, co je do úschovy ve skutečnosti předáváno, resp. objednatel nedisponuje obvykle odborníky, kteří by byli schopni toto ověřit.
Co je předmětem ověření?
Předmětem ověření není jen shoda zdrojových kódů ukládaných do úschovy a kódů softwaru implementovaného u objednatele. Lze doporučit, aby smlouva o ověření zdrojových kódů definovala činnost ověřovatele podstatně šířeji, a jeho úkolem by mělo být zejména:
a) Ověření integrity
Ověření integrity spočívá v porovnání dodaných zdrojových kódů s deklarovaným obsahem, a to:
- zda uschovávané zdrojové kódy odpovídají deklarovanému rozsahu a struktuře,
- u zdrojových kódů v komprimované podobě, zda se dají dekomprimovat do deklarované struktury,
- pokud jsou zdrojové kódy šifrovány, zda je přiložen klíč a postup, kterým lze data rozšifrovat.
b) Ověření kompilace
Ověřením kompilovatelnosti se zjišťuje, zda lze z dodaných dat pomocí deklarovaných nástrojů úspěšně sestavit binární podobu zdrojových kódů. V rámci této činnosti se zjišťuje:
- zda jsou zdokumentovány kroky nutné ke kompilaci,
- zda jsou dostupné potřebné nástroje (kompilátory a knihovny) ke kompilaci,
- úspěšnost překladu (kompilace) zdrojových kódů do strojového kódu cílové architektury (objektového kódu), a to pomocí dodaného nebo specifikovaného (pokud je jinak dostupný) překladače a dodaných kompilačních skriptů,
- úspěšnost spojení (linkování) objektového kódu s kódem knihoven (standardních nebo dodaných dodavatelem) do spustitelného kódu software pro cílovou platformu.
- zda spustitelný kód odpovídá deklarované verzi.
c) Ověření funkcionality
Jde o posouzení funkcionality (tj. pouze a výhradně souboru funkcí SW), obsažené v předaných zdrojových kódech SW, vzhledem k funkcionalitě deklarované v dokumentaci dodané dodavatelem, tj. zda se ve zdrojovém kódu nacházejí deklarované funkce. Ověřovatel ovšem nezkoumá funkčnost softwaru, tzn. správnost fungování.
d) Ověření čitelnosti
Cílem této činnosti ověřovatele je posoudit čitelnost zdrojových kódů SW pro programátora, který se na vývoji posuzovaného SW nepodílel. Provádí se posouzení z hlediska výpovědní hodnoty komentářů, smysluplnosti názvů entit (tj. identifikátorů, konstant, funkcí) a z hlediska čitelnosti formátování zdrojového kódu.
e) Ověření kvality zdrojového kódu
V rámci posouzení kvality zdrojového kódu, se pomocí heuristických analýz ověřuje, zda zdrojový kód dostatečně splňuje kritéria kvality a bezpečnosti a zda nevykazuje některá rizika. Tento krok lze provést pouze v případě, že k danému zdrojovému kódu existují potřebné heuristické nástroje.
f) Ověření funkčnosti
Jde o ověření správnosti fungování softwaru pomocí automatických testů, což předpokládá časově a finančně nejnáročnější úroveň ověřování. Nezbytné je, aby byly úspěšně realizovány všechny předchozí úrovně ověřování. Tato úroveň ověření je determinována dostatečnou definicí zdrojových a cílových dat testů a současně zdrojový kód musí být napsán tak, aby byl testovatelný. V rámci ověřování funkčnosti ověřovatel pracuje se simulačními daty a kontextem (např. omezujícími podmínkami) a vytváří potřebnou množinu tzv. unit testů.
Kdo je ověřovatelem?
Ověřovatelem by měla být osoba či firma, která má dostatečné zkušenosti s tvorbou zdrojového kódu, s jeho nakládáním, čitelností, a to bez ohledu na to, kdo je jeho původcem a v jakém jazyce je napsán. Současně by tato osoba měla být dostatečně pojištěna pro případ odpovědnosti za škodu a její činnosti by měl být jednoznačně smluvně podchyceny, tak aby výsledek v podobě posouzení poskytl jednoznačnou odpověď objednateli a jistotu, že zdrojový kód uložený následně u schovatele mu zabezpečí kontinuální servis a vývoj softwaru.
Jaký je postup?
Ověřovatel by neměl být oprávněn předmět ověření přenechat ani jinak zpřístupnit jakékoliv osobě, vč. objednatele. Zdrojový kód by měl být předán jemu na datovém nosiči či jinak zpřístupněn pouze za účelem ověření. Pokud posudek bude pozitivní, tj. potvrdí vzhledem k předmětu posouzení, že předaný zdrojový kód softwaru odpovídá tomu, co je deklarováno dodavatelem a co bylo dodáno objednateli, pak bude zdrojový kód předán přímo osobě schovatele v rámci smlouvy o escrow. V případě záporného písemného posouzení ověřovatele, kdy předmět ověření nesplňuje kterýkoliv z ověřovaných a posuzovaných parametrů, pak by zdrojové kódy měly být vráceny dodavateli.
Závěr
Ověření zdrojových kódů má rozhodně opodstatnění v rámci jejich úschovy, kdy objednatel není schopen si sám ověřit, že do úschovy jsou dodavatelem předávány zdrojové kódy odpovídající tomu, co bylo implementováno a deklarováno, a které jsou způsobilé dalšího vývoje a servisu. Předpokladem je uzavření odpovídající smlouvy s osobou, která má dostatečné zkušenosti a odbornost.
Další články
Švarcsystém pod drobnohledem inspekce práce
Co odhalily kontroly inspekce práce v letech 2024–2025? Pokuty v milionech, neohlášené kontroly a sektory, kde inspektoři hledají nejčastěji.
Autonomní zbraňové systémy: Kdo odpovídá za chybu?
Autonomní zbraňový systém může po aktivaci sám vyhledat objekt odpovídající předem nastavenému cílovému profilu a použít proti němu sílu. Člověk přitom nemusí předem znát konkrétní cíl, přesné místo ani okamžik zásahu. Právě tím se takový systém liší od běžného dálkově ovládaného dronu, u něhož konkrétní cíl zpravidla vybírá operátor. Právní otázka tedy nezní, zda o likvidaci cíle „rozhodl“ stroj, ale kdo rozhodl o vývoji, nastavení a nasazení systému, jaké měl informace a zda mohl jeho působení ovlivnit.
Od odpovědi k odpovědné právní práci. Proč se v české advokacii mění standard využití AI
Umělá inteligence už v právu neslouží jen k rychlému vyhledání odpovědi. Skutečnou hodnotu začne mít teprve tehdy, když pracuje nad ověřenými právními zdroji, respektuje mlčenlivost a umožňuje kontrolu nad daty i výstupy. Právě tímto směrem se dnes posouvají i specializované právní platformy včetně nových řešení v ekosystému CODEXIS.
Rovné a transparentní odměňování aneb očekávané právní novinky i nevyužité možnosti
Myslíte si, že je nová evropská směrnice o rovném a transparentním odměňování hudbou vzdálené budoucnosti? Nenechte se zmást odkladem české účinnosti na rok 2027. Zavedení povinného písemného systému odměňování, zákaz dotazů na předchozí plat uchazečů nebo povinný reporting rozdílů mezi muži a ženami totiž nejsou projekty na pár týdnů.
Procesní nařízení k GDPR: jak se mění přeshraniční dozor?
Na konci roku 2025 Evropská unie přijala dlouho očekávané procesní nařízení, které má zpřesnit a urychlit prosazování nařízení Evropského parlamentu a Rady (EU) 2016/679 (dále jen „GDPR“) v přeshraničních případech.




