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
EET 2.0: na čem vůbec stojí slibovaných 14 miliard?
Schválení EET 2.0 Poslaneckou sněmovnou znovu rozvířilo ostrou debatu o skutečném fiskálním přínosu evidence tržeb a právní jistotě českých podnikatelů. Jaké jsou rozpočtové odhady Ministerstva financí i nezávislých ekonomů?
Outsourcing mzdové agendy: odpovědnost zůstává zaměstnavateli, smluvní ochrana ale může být silnější
Outsourcing mezd nepřenáší veřejnoprávní odpovědnost zaměstnavatele na dodavatele. To ale samo o sobě není argumentem proti outsourcingu. Rozhodující je, jak je nastavena smlouva, odpovědnost dodavatele, pojistné krytí a předávání podkladů. Právě zde může mít externí model oproti internímu zpracování významnou výhodu: prostor pro náhradu škody není omezen pracovněprávním limitem zaměstnance, ale je předmětem smluvního vyjednávání.
Technologická proměna člověka jako právní problém v práci a sociální péči
Exoskelet může ulehčit zádům pracovníka, chytrá protéza zpřesnit pohyb a domácí senzory umožnit člověku zůstat déle ve vlastním bytě. Technologie zde nevystupuje jako protivník. Často řeší skutečný problém: snižuje fyzickou zátěž, podporuje soběstačnost a nahrazuje kapacitu, kterou zaměstnavatel, rodina nebo sociální služba nemají.
Implementace směrnice o platformové práci: znaky závislé práce, právní domněnka a algoritmické řízení (2. část)
Předchozí díl nastínil úvod do problematiky platformové práce a otázku aplikace právní domněnky a automatické rekvalifikace. Další díl si klade za cíl na tohle téma navázat, a to analýzou redefinice závislé práce a jejich jednotlivých znaků.
Vadné vyúčtování služeb: co se změnilo a proč jsme kvůli tomu přestavěli kontroly
Mezi pronajímateli se drží poučka: když je vyúčtování vadné, nedoplatek není splatný. Od roku 2023 to ale neplatí bez výhrad a Nejvyšší soud to na konci roku 2024 potvrdil.




