Jak správně ošetřit autorská práva při vývoji softwaru na zakázku prostřednictvím externích vývojářů

Proč je u externího vývoje autorské právo kritické

U zakázkového softwaru je častý omyl, že „když jsme za vývoj zaplatili, patří nám“. V českém právu to tak automaticky nefunguje. Autorem je fyzická osoba, která dílo vytvořila, a bez správně nastavené smlouvy může mít objednatel jen omezené oprávnění software užívat. To je problém hlavně ve chvíli, kdy potřebujete předat projekt jinému týmu, rozšířit aplikaci nebo ji komerčně škálovat.

Riziko se zvyšuje u externích vývojářů, freelancerů i menších agentur, které používají vlastní šablony smluv. V praxi se často řeší situace, kdy firma má přístup do Git repozitáře, ale nemá ošetřené majetkové právo k výslednému dílu, nemá právo upravovat kód bez souhlasu autora nebo chybí ujednání o podlicenci. V případě sporu pak rozhoduje text smlouvy, ne e-mailová domluva.

Co musí být ve smlouvě, aby byl kód skutečně váš

Základ je jednoduchý: smlouva o dílo nebo rámcová smlouva musí výslovně řešit převod nebo poskytnutí licence k autorskému dílu. Nestačí obecná věta typu „dodavatel předá zdrojové kódy“. Doporučuje se vymezit alespoň pět oblastí: rozsah díla, způsob užití, územní a časový rozsah, oprávnění k úpravám a možnost postoupení práv dalším subjektům.

  • Výslovný převod majetkových práv nebo exkluzivní licence s právem úprav a integrace do dalších systémů.
  • Právo na odvozená díla, aby bylo možné software dál rozvíjet interně nebo jiným dodavatelem.
  • Právo poskytnout podlicenci například dceřiné společnosti, klientovi nebo provozovateli hostingu.
  • Ujednání o předání zdrojových kódů, dokumentace, build skriptů, přístupů a repozitářů.
  • Garance původnosti, že dodavatel nepoužil nelegální nebo neautorizovaný kód.

V českém prostředí je vhodné doplnit i ujednání o okamžiku nabytí práv. Prakticky to znamená, že práva přecházejí až úhradou celé ceny, nebo již okamžikem vytvoření díla podle přesně definovaného milníku. Důležité je, aby to nebylo nejasné. Když se práva vážou na předání finální verze, musí být jasné, co je „finální verze“ a jak se potvrzuje akceptace.

Jak ošetřit open-source, knihovny a cizí komponenty

Největší skryté riziko u zakázkového vývoje není jen autorství vývojáře, ale i použité externí komponenty. Moderní software často obsahuje open-source balíčky, fonty, obrazové podklady, UI knihovny nebo komerční API. Každá licence má jiná pravidla. Například permissivní licence typu MIT nebo Apache 2.0 bývají pro komerční projekt obvykle bezpečnější než copyleft licence typu GPL, která může při nevhodném použití vyžadovat zveřejnění odvozeného díla.

Proto si ve smlouvě vyžádejte seznam všech použitých knihoven a licencí. Ideální je příloha, kde bude uvedeno:

  • název komponenty a verze,
  • typ licence,
  • účel použití,
  • zda je možné komponentu upravovat,
  • zda existují omezení pro komerční využití.

Pro kontrolu lze využít nástroje jako FOSSA, WhiteSource nebo open-source skenery typu OWASP Dependency-Check či npm audit. U větších projektů je dobré nastavit pravidlo, že žádná nová knihovna nesmí být přidána bez schválení technickým leadem nebo product ownerem. Ušetří to budoucí právní i bezpečnostní problémy.

Praktický proces předání: nejen kód, ale i důkazy o právu

Správně ošetřená práva nekončí podpisem smlouvy. Klíčový je i předávací proces. Pokud externí vývojář odejde a vy máte jen ZIP soubor, ale nevíte, kde jsou build skripty, deployment instrukce a přístupy k repozitáři, jste v rizikové situaci. Stejně tak pokud není doloženo, kdo napsal konkrétní části kódu a kdy vznikly.

Doporučený předávací balíček by měl obsahovat:

  • zdrojový kód v repozitáři pod vaší správou, ideálně GitHub, GitLab nebo Bitbucket,
  • README s popisem instalace, nasazení a závislostí,
  • seznam přístupů a jejich předání do firemního password manageru, například 1Password nebo Bitwarden,
  • technickou dokumentaci API, datových toků a environmentů,
  • prohlášení o původu kódu a použitých externích zdrojích.

V praxi se vyplatí zavést i interní kontrolní seznam při akceptaci. Například až po předání repozitáře, dokumentace, licenčního seznamu a potvrzení o převodu práv se uvolní poslední část platby. U projektů nad vyšší desítky tisíc korun je to běžný a rozumný postup, protože motivuje dodavatele dodat vše kompletně.

Na co si dát pozor u freelancerů, agentur a zaměstnanců na IČO

Ne všichni externí vývojáři jsou právně stejní. Freelancer pracující na živnost má jiný režim než agentura nebo subdodavatel. Pokud agentura využívá své lidi jako subdodavatele, musí mít sama vyřešené, že práva k dílu může předat dál. Jinak se může stát, že agentura dodá projekt, ale nemá od svých programátorů platně získaná oprávnění k převodu na klienta.

To je důvod, proč by smlouva měla obsahovat i záruku, že dodavatel je oprávněn s výsledkem nakládat a že má vypořádána práva všech osob, které se na díle podílely. U větších projektů je vhodné vyžadovat i potvrzení, že vývojáři podepsali interní převodní ujednání nebo licenční doložky. Pokud dodavatel pracuje s týmem, který není jeho zaměstnanecký, riziko se násobí.

Praktická zkušenost z trhu je jasná: čím menší a rychlejší vývoj bez formalit, tím větší šance, že se práva vyřeší až při problému. A tehdy je už pozdě. Nejlevnější je ošetřit vše před zahájením práce, ne až při předání nebo při sporu o údržbu.

Jak nastavit dlouhodobou kontrolu nad softwarem

Autorská práva nejsou jednorázová administrativní položka, ale součást správy softwaru. Doporučuje se mít ve firmě jednoduchý interní standard: každá zakázka má smlouvu s licenční přílohou, repozitář pod kontrolou klienta, seznam použitých komponent, dokumentaci a předávací protokol. V případě změny dodavatele pak stačí otevřít aktuální stav projektu a navázat bez právních nejasností.

U strategických projektů je vhodné doplnit i interní audit jednou za rok. Kontroluje se, zda všechny nové moduly vznikly pod správnou smlouvou, zda nebyly přidány problémové open-source balíčky a zda jsou práva stále převoditelná. V kombinaci s verzováním v Git repozitáři, evidencí commitů a jasným ticketingem v nástrojích jako Jira nebo Linear získáte nejen pořádek v projektu, ale i důkazní stopu pro případ sporu.

Pokud chcete mít jistotu, že software skutečně vlastníte a můžete ho bez omezení rozvíjet, berte autorská práva stejně vážně jako bezpečnost nebo výkon. Ve správně nastaveném projektu je to vidět už v prvním draftu smlouvy, v kontrolním seznamu předání i v tom, komu patří repozitář a dokumentace. Teprve potom je zakázkový vývoj skutečně pod vaší kontrolou.

Bc. Martina Vaňková | Redakce
Bc. Martina Vaňková | Redakce

Redaktorka magazínu i-Justice.cz s citem pro detail a aktuální dění. Věnuje se zpravodajství, kultuře a lifestylovým tématům. Ráda objevuje nová místa a inspirativní příběhy, které následně přenáší na stránky našeho magazínu.

https://www.i-justice.cz