Vlastnictví zdrojového kódu a licence: 7 otázek pro dodavatele

01Co přesně si firma kupuje

Faktura za vývoj může pokrývat různé věci: práci na nové funkci, oprávnění užívat hotový produkt, provoz služby nebo kombinaci všech tří. Vyžádejte si rozdělení nabídky. Které části vzniknou pro vás, které dodavatel používal už dříve a které poskytuje další společnost? Stejně pojmenovaná položka „software na míru“ nemusí u dvou nabídek znamenat stejná oprávnění.

Zdrojový kód je lidsky čitelný zápis programu. Pro praktické převzetí ale potřebujete také informace, jak z něj vytvořit běžící aplikaci. Samostatný archiv souborů bez konfigurace, závislostí a návodu může být obtížně použitelný. Rozhodujte podle schopnosti systém rozvíjet a provozovat, ne podle počtu souborů v příloze.

Představte si českou výrobní firmu s plánováním zakázek. Dnes aplikaci spravuje její autor, příští rok má údržbu převzít jiný tým. Firma potřebuje možnost opravit program, založit testovací prostředí, přenést data a zapojit nového dodavatele. Každý tento úkon propojuje smluvní oprávnění s konkrétním technickým podkladem.

• Oddělte nově vytvořený kód od knihoven a produktů třetích stran.
• Pojmenujte, kdo smí aplikaci používat, měnit a provozovat.
• Uveďte, co získáte během vývoje a co při ukončení spolupráce.
• Ověřte, kdo ovládá účty potřebné pro běžný provoz.

02V české smlouvě nestačí věta „kód je náš“

Český autorský zákon rozlišuje autorství, výkon majetkových práv a oprávnění dílo užívat. § 26 autorského zákona uvádí nepřevoditelnost majetkových autorských práv autora. Obchodní věta o „převodu všech autorských práv“ proto potřebuje přesnější právní obsah.

Podle § 58 zaměstnavatel při splnění zákonných podmínek vykonává majetková práva k zaměstnaneckému dílu, není-li sjednáno jinak. Odstavec 7 stanoví zvláštní režim pro programy vytvořené autorem na objednávku. Z toho nelze bez posouzení vztahů vyvodit, že zákazník vývojové společnosti automaticky získá všechna oprávnění ke všem částem systému.

Nechte prověřit řetězec oprávnění od skutečných autorů přes zaměstnance či subdodavatele až k vaší firmě. Vyjasněte licenci nebo postoupení výkonu práv tam, kde přichází v úvahu. Konkrétní řešení závisí na smlouvách a vzniku jednotlivých částí. Předání souborů samo tuto otázku nevyřeší.

Rozhovor s právníkem připravte pomocí provozních scénářů. Potřebujete rozvoj jinou firmou, použití v dceřiné společnosti, prodej produktu zákazníkům nebo migraci na vlastní server? Srozumitelné situace umožní určit rozsah oprávnění přesněji než neurčitý požadavek na „neomezené vlastnictví“. V zadání systému na míru mají být tyto potřeby už před porovnáním nabídek.

03Rozsah licence přeložte do běžné práce

Zeptejte se, zda je oprávnění výhradní nebo nevýhradní a ke kterým částem se vztahuje. Firma může potřebovat výhradní oprávnění k vlastnímu obchodnímu řešení, zatímco obecnou knihovnu používá dodavatel i jinde. Takové rozdělení musí být čitelné. Výhradnost celé aplikace neslibujte tam, kde obsahuje běžné licencované komponenty.

Projděte dobu a území užívání, způsob placení a závislost práv na úhradě. Určete, zda počet uživatelů, provozních prostředí či společností ovlivní cenu nebo povolené využití. Důležitá je i možnost úprav, zadání změn třetí osobě a oprávnění pokračovat po skončení servisní smlouvy. Rozsah licenčního oprávnění a povinnost poskytovat podporu jsou dvě odlišné dohody.

Vyřešte také změnu vlastníka firmy, reorganizaci a předání služby dalšímu provozovateli. Dnes se mohou zdát vzdálené, při transakci ale rozhodují o použitelnosti aplikace. Všechna očekávání neskládejte do jedné věty; oddělte oprávnění, dostupnost podkladů a součinnost dodavatele.

04Cizí knihovny mají vlastní podmínky

Moderní aplikace může obsahovat open source knihovny, placené moduly, písma nebo externí rozhraní. U každé významné části potřebujete název, verzi, licenci a způsob použití. Seznam závislostí pomáhá sledovat povinnosti i budoucí aktualizace. Pouhý seznam balíčků bez jejich licencí ještě není úplný licenční přehled.

MIT licence umožňuje široké využití včetně úprav a prodeje, požaduje však zachování stanoveného upozornění a licenčního textu. Apache License 2.0 upravuje také patentové oprávnění a při další distribuci stanoví podmínky včetně licenčních informací a označení změněných souborů. Ani takové licence neznamenají „bez podmínek“.

Jiné licence mohou vyžadovat odlišné zacházení se zdrojovým kódem nebo jeho zpřístupněním. Neřiďte se pouze označením open source. Dodavatel má posoudit konkrétní text, verzi licence a způsob začlenění. U knihovny použité jen na serveru mohou být relevantní jiné okolnosti než u programu dodávaného zákazníkům.

Požadujte pravidlo pro přidávání nových komponent během údržby. Kdo posoudí jejich licenci, kdo zaznamená změnu a kdo schválí další poplatky? Přehled předaný při prvním spuštění přestane být spolehlivý, když další vývoj průběžně přidává závislosti bez záznamu.

05Předání musí umožnit sestavení a provoz

Dohodněte průběžný přístup do repozitáře, vhodná oprávnění a zálohy. Pokud je jediným správcem dodavatel, stanovte postup převzetí a případného výpadku jeho součinnosti. Ještě lepší kontrolu poskytne účet spravovaný vaší firmou s přístupem dodavatele. Tento provozní návrh nevyřeší licenci; oba kroky potřebujete zároveň.

Předávací balíček má odpovídat dohodnuté verzi aplikace. Patří do něj zdrojové soubory, přehled závislostí, návod sestavení, konfigurace prostředí bez tajných údajů, databázové změny a postup nasazení. Doplňte testy, dokumentaci rozhraní a popis zálohování. Vyžádejte si také seznam známých omezení, aby nový tým nemusel zjišťovat skryté předpoklady metodou pokusů.

Ověřte balíček praktickým převzetím. Pověřený tým podle návodu vytvoří testovací prostředí a provede dohodnuté základní úkony. Chybějící přístup či soubor zaznamenejte před podpisem předávacího protokolu. Výsledek není zkouškou práce původního autora; je důkazem, že předání splnilo potřebný účel.

Tajné klíče, hesla a produkční data nepřidávejte bezmyšlenkovitě do archivu kódu. Předejte je řízeným způsobem příslušným osobám a po změně správce podle potřeby obnovte přístupové údaje. Dokumentace má vysvětlovat, kde se konfigurace spravuje, ne rozmnožovat citlivá tajemství na neurčito.

06Účty a data rozhodují při změně dodavatele

Přechod může zastavit účet pro doménu, cloud, odesílání e-mailů, platební službu nebo obchod s aplikacemi. U každého zjistěte smluvního držitele, správce, platební kontakt a způsob předání. Osobní účet vývojáře není vhodným jediným bodem správy firemní služby. Zároveň nelze předpokládat, že všechny služby dovolují prostý převod účtu.

Export dat sjednejte zvlášť: co zahrne, v jakém formátu, s jakými vazbami a za jaké součinnosti. Záloha celé databáze může být použitelná pro obnovu stejné aplikace, zatímco migrace do jiného systému vyžaduje popis tabulek a pravidel. Vyzkoušejte export na testovacích datech a ověřte, zda lze správně spojit zakázku, přílohu a související záznam.

V servisní dohodě stanovte způsob ukončení: předání aktuální verze, vysvětlení provozu, přiměřenou součinnost a závěrečné vypořádání přístupů. Určete, co je již zahrnuto a co se účtuje. Dodatečná nabídka „předání dle potřeby“ bez rozsahu a podkladů dává firmě malou oporu pro plánování.

U úschovy zdrojového kódu, označované jako escrow, posuďte podmínky vydání a aktuálnost uloženého balíčku. Úschova staré verze bez potřebných komponent nemusí zajistit pokračování provozu. Tato možnost může doplnit správně připravenou smlouvu a předání, její účinnost závisí na konkrétních pravidlech a pravidelné kontrole.

07Jak připravit jednání a převzetí

Před obchodním jednáním napište krátký seznam situací, které musí firma zvládnout. Vývoj nového modulu, odchod dodavatele, přístup dceřiné společnosti a obnova po poruše mohou vyžadovat jiné podklady. Dodavateli pošlete stejný seznam, aby odpovědi a nabídky byly porovnatelné.

Na schůzce požádejte o příklad předání podobné technické sestavy bez cizích osobních údajů či důvěrného kódu. Uvidíte strukturu dokumentace a způsob odpovědí. Nehodnoťte pouze vstřícnost obchodníka: požadavky potřebují souhlas člověka, který skutečně řídí vývoj a provoz. Rozpory mezi nabídkou, servisní smlouvou a licenční přílohou vyřešte před podpisem. Pozdější vysvětlení v e-mailu nemusí vytvořit srozumitelnou shodu všech zúčastněných.

1. Sepište části systému, účty a potřebné provozní scénáře.
2. Prověřte s dodavatelem řetězec oprávnění a licence komponent.
3. Dohodněte průběžný přístup, předávací balíček a ukončení servisu.
4. Vyzkoušejte převzetí konkrétní verze podle dokumentace.

U důležité aplikace spojte právní a technickou kontrolu. Právník může vyhodnotit rozsah oprávnění, technik ověřit skutečnou použitelnost předání. Do výsledku zapište otevřené body a odpovědné osoby. Není potřeba předstírat, že složitou dodávku vyřeší univerzální odstavec ve smlouvě.

08Časté otázky ke kódu a licencím