CLA vs. DCO: Ktorú príspevkovú dohodu by mal váš open source projekt používať?

Váš vedľajší projekt práve prekročil 500 hviezdičiek a cudzí človek otvoril prvý vážny pull request: 2 000 riadkov, ktoré opravujú problém, ktorému ste sa mesiace vyhýbali. Chcete kliknúť na merge. Ale skôr, než tak urobíte, položte si nepríjemnú otázku: máte vôbec zákonné právo tento kód vydávať — a vydávať ho naďalej pod svojou licenciou, navždy, bez ohľadu na to, pre koho ten prispievateľ pracuje?

Ak váš repozitár nemá politiku prispievania, úprimná odpoveď je, že si nie ste istí. Prispievateľ stále vlastní autorské práva na každý riadok, ktorý napísal, a samotná licencia vášho projektu nie vždy vyrieši, kto komu čo udelil. Táto neistota zostáva neviditeľná až do dňa, keď na nej záleží: zmena licencie, akvizícia, firemný používateľ vykonávajúci licenčnú due diligence alebo zamestnávateľ prispievateľa, ktorý tvrdí, že práca bola celý čas jeho.

Tento problém riešia dva mechanizmy a takmer každý open source projekt si vyberá jeden z nich: Contributor License Agreement (CLA) a Developer Certificate of Origin (DCO). Oba existujú preto, aby ustanovili, že prispievateľ je oprávnený príspevok vytvoriť a že projekt má právo ho distribuovať. Zásadne sa však líšia vo váhe, záťaži a v tom, čo vám neskôr umožnia. Táto príručka vysvetľuje, ako každý z nich funguje, kedy si ktorý vybrať a ako svoju voľbu nastaviť za jedno popoludnie.

Prečo váš projekt vôbec potrebuje politiku prispievania​

Autorské právo vzniká automaticky. Vo chvíli, keď niekto napíše kód, ho vlastní — bez registrácie, bez potreby oznámenia o autorských právach. Keď ho odošle do vášho projektu, vaša open source licencia pokrýva mnohé, ale zanecháva medzery, ktoré uzatvára len politika prispievania:

• Prichádzajúci grant. Vaša odchádzajúca licencia (MIT, Apache-2.0, GPL) hovorí používateľom, čo smú s vaším kódom robiť. Politika prispievania výslovne stanovuje, že prichádzajúce príspevky prichádzajú za kompatibilných podmienok, takže môžete distribuovať spojené dielo bez ručného sledovania pôvodu jednotlivých súborov.
• Nároky zamestnávateľa. Väčšina pracovných zmlúv prevádza duševné vlastníctvo z vedľajších projektov na zamestnávateľa, prinajmenšom pri práci súvisiacej s pracovnou náplňou zamestnanca. Politika, ktorá žiada prispievateľov potvrdiť, že majú právo príspevok odoslať, prenáša túto zodpovednosť — aj papierovú stopu — na prispievateľa.
• Možnosť zmeny licencie. Ak niekedy budete chcieť zmeniť licenciu, pridať komerčnú edíciu alebo projekt darovať nadácii, potrebujete práva od každého prispievateľa. Získať toto povolenie spätne od desiatok minulých prispievateľov je niekde medzi bolestivé a nemožné. Politika zvolená v prvý deň rozhoduje o tom, či tieto dvere zostanú otvorené.
• Patentová ochrana. Kódové príspevky so sebou môžu niesť patentové práva. Niektoré politiky zahŕňajú výslovný patentový grant; iné nie, čo je dôležitejšie, než si väčšina správcov uvedomuje.

Nič z toho nevyžaduje advokátsku kanceláriu na trvalý úväzok. Vyžaduje to vybrať CLA alebo DCO, zapísať to do svojho repozitára a automaticky to vymáhať. Tu je to, čo každá voľba obnáša.

Čo je Contributor License Agreement (CLA)?​

Contributor License Agreement je podpísaný právny dokument medzi prispievateľom a projektom (alebo spoločnosťou či nadáciou, ktorá za ním stojí). Prispievateľ podpíše raz a tento podpis pokrýva všetky jeho budúce príspevky.

Na rozdiel od open source licencií nie sú CLA štandardizované. Každý projekt si píše vlastnú, ale väčšina sa delí na dva známe typy:

Individuálne vs. firemné CLA​

• Individuálne CLA (ICLA): podpisuje ho osoba prispievajúca vo vlastnom mene. Zvyčajne udeľuje projektu širokú licenciu na autorské práva a často aj patentovú licenciu, pričom prispievateľ si ponecháva vlastné autorské práva.
• Firemné CLA (CCLA): podpisuje ho spoločnosť a oprávňuje svojich zamestnancov prispievať. Spoločnosť udeľuje rovnaké práva na prácu, ktorú jej ľudia odosielajú. Projekty, ktoré prijímajú firemné príspevky bez CCLA, sa spoliehajú na to, že manažér každého zamestnanca o tom vie — a súhlasí — čo je presne ten druh dôvery, ktorý sa počas due diligence vytratí.

Licenčný grant vs. prevod autorských práv​

Väčšina moderných CLA sú licenčné granty: prispievateľ si ponecháva vlastníctvo a projektu udeľuje trvalú, celosvetovú, bezlicenčnú licenciu — často takú širokú, že umožňuje zmenu licencie. Kanonickým príkladom je ICLA nadácie Apache Software Foundation.

Menšina projektov používa prevod autorských práv, pri ktorom prispievateľ odovzdáva vlastníctvo úplne (prístup Free Software Foundation). Prevod dáva projektu maximálnu slobodu vymáhať práva a meniť licenciu, ale vyžaduje od prispievateľov najviac a u komunitne vedených projektov vyšiel z módy.

Čo vás a vašich prispievateľov CLA stojí​

Kompromisom je záťaž. Prvýkrát prispievajúci musí opustiť pull request, prečítať právny dokument, podpísať ho (zvyčajne elektronicky) a čakať, kým stavová kontrola zozeleňuje, než správca vôbec začne kontrolovať jeho kód. Nástroje to urobili takmer bezbolestným — boty ako CLA Assistant okomentujú pull request s odkazom na podpis a podpis automaticky zaznamenajú — ale stále je to brána medzi „opravil som váš bug“ a „môžete môj fix zlúčiť“. Niektorí náhodní prispievatelia sa od nej odrazia.

Na oplátku projekt získa podpísaný, auditovateľný záznam: táto osoba, v tento deň, udelila tieto práva. Pre firemne podporované projekty, dvojlicenčné projekty a čokoľvek, čo môže byť raz nadobudnuté, má táto papierová stopa skutočnú hodnotu.

Čo je Developer Certificate of Origin (DCO)?​

Developer Certificate of Origin zaviedla Linux Foundation v roku 2004 pre jadro Linuxu, práve aby sa vyhla váhe CLA. Nie je to zmluva, ktorú prispievateľ podpíše a založí. Je to krátke osvedčenie — päť odsekov, verzia 1.1 — ktoré prispievateľ potvrdzuje pri každom commite pridaním riadku Signed-off-by do správy commitu:

Fix off-by-one error in retry backoff calculation
 
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
 
Signed-off-by: Alex Rivera <[email protected]>

Pridanie riadku je jeden prepínač: git commit -s ho automaticky pripojí pomocou vašej nastavenej identity v Git. Podpisom prispievateľ osvedčuje, že:

1. Príspevok vytvoril (úplne alebo čiastočne) a má právo ho odoslať pod open source licenciou projektu, alebo
2. Jeho príspevok vychádza z predchádzajúcej práce, ktorá je už pod vhodnou open source licenciou umožňujúcou toto odoslanie, alebo
3. Príspevok dostal od niekoho iného, kto osvedčil jedno z vyššie uvedeného, a sám ho neupravil, a
4. Rozumie príspevku a jeho záznamu — vrátane svojho podpisu — že sú verejné a uchovávané neobmedzene.

To je celý mechanizmus. Žiadny samostatný dokument, žiadne prepájanie účtov, žiadny onboarding pre každý projekt. Vymáhanie je stavová kontrola: aplikácia DCO alebo ekvivalentná kontrola overí, že každý commit v pull requeste nesie platný podpis, a správcovia zlúčia až vtedy, keď je zelená.

Zámerné obmedzenia DCO​

Všimnite si, čo DCO nerobí. Neudeľuje žiadnu licenciu nad rámec toho, čo už sprostredkúva odchádzajúca licencia projektu — spolieha sa na to, že príspevok prichádza za licenčných podmienok projektu. Neobsahuje žiadny patentový grant. A keďže sa nič nepodpisuje a nezakladá pre každého prispievateľa, neexistuje centrálny register toho, kto s čím súhlasil; samotná história Git je záznamom.

Zástancovia to považujú za prednosť: nízkа bariéra DCO je zámerom. Jadro Linuxu, GitLab (ktorý v roku 2017 prešel z CLA) a Chef (ktorý prešel v roku 2016) dospeli k záveru, že osvedčenie pri každom commite im dáva pôvod, ktorý potrebujú, bez zaťaženia každého prispievateľa. Technický výbor OpenStacku v roku 2025 rozhodol, že svoje CLA nahradí DCO pre všetky príspevky. Priemyselný trend je neprehliadnuteľný — ale trend nie je verdikt pre váš projekt, ako vysvetľujú nasledujúce časti.

CLA vs. DCO vedľa seba​

Kedy je CLA správnou voľbou​

Zvoľte CLA, keď budúcnosť projektu môže závisieť od práv, ktoré DCO nezachytáva:

• Plánujete dvojlicencovanie alebo zmenu licencie. Ak je komerčná edícia, zmena licencie alebo prechod z copyleft na permisívne licencovanie čo i len vzdialene pravdepodobný, CLA so širokým licenčným prevodom späť je jediným jednoduchým spôsobom, ako túto možnosť udržať otvorenú. Spätné rekonštruovanie súhlasu o roky neskôr je nočná mora.
• Za projektom stojí spoločnosť. Firemní sponzori, nadobúdatelia a podnikoví zákazníci vykonávajúci IP due diligence chcú register podpisov, nie archeológiu. Google, projekty Apache a Canonical používajú CLA práve z tohto dôvodu.
• Patenty sú vo vašej oblasti dôležité. Kodeky, bezdrôtové protokoly, architektúry ML modelov — v oblastiach s množstvom patentov výslovný patentový grant v CLA vykonáva skutočnú prácu, ktorú DCO potichu preskakuje.
• Nadácia ho vyžaduje. Niektoré nadácie nariaďujú svoje CLA ako podmienku hostingu alebo ukončenia inkubácie. Overte si to, než budete predpokladať, že DCO stačí.

Ak sa vydáte touto cestou, udržujte samotné CLA štandardné a nudné: začnite s Apache ICLA alebo šablónou Harmony namiesto písania od nuly, zverejnite individuálnu aj firemnú verziu a v prvý deň pripojte bota na podpisovanie, aby záťaž bola jedným kliknutím, nie obehom PDF.

Kedy vyhráva DCO​

Zvoľte DCO, keď sú príspevky životnou silou projektu a záťaž je nepriateľom:

• Komunitné projekty s mnohými príležitostnými prispievateľmi. Opravy dokumentácie, korekcie preklepov, malé záplaty chýb — príspevky, ktoré sa najpravdepodobnejšie odrazia od podpisovej brány, sú zároveň tie, s ktorými si DCO elegantne poradí.
• Permisívna licencia, žiadne plány na zmenu licencie. Ak projekt navždy zostane MIT alebo Apache-2.0 a v plánoch nie je komerčná edícia, extra práva z CLA vám prinesú málo.
• Samostatní správcovia a malé tímy. DCO nepotrebuje žiadnu infraštruktúru na podpisy, žiadny právny subjekt na uchovávanie dohôd a žiadny proces na spolupodpisovanie firemných formulárov. Je to správa, ktorú zvládnete zo súboru CONTRIBUTING.md a stavovej kontroly.
• Postoj maximálnej kompatibility. Niektorí prispievatelia — najmä tí zamestnaní veľkými spoločnosťami s prísnymi IP politikami — môžu podpísať DCO, ale nemôžu podpísať externé CLA bez právneho preskúmania. DCO udržiava tieto dvere otvorené.

Nech si vyberiete čokoľvek, zapíšte to rozhodnutie. CONTRIBUTING.md, ktorý uvádza politiku, zobrazuje presný postup podpisu a odkazuje na úplné znenie, odstraňuje najčastejší zdroj zmätku: prispievatelia hádajú požiadavky z neúspešnej stavovej kontroly.

5 chýb, ktoré podkopávajú obe voľby​

1. Hovoriť oboje. Najčastejšia chyba v praxi je CONTRIBUTING.md, ktorý v jednom odseku vyžaduje podpisy DCO a v inom podpisy CLA — zvyčajne po nedokončenej migrácii. Prispievatelia sa riadia jednou inštrukciou, druhá kontrola zlyhá a správcovia aj tak zlúčia, čo ruší zmysel oboch. Vyberte si jeden mechanizmus, vymáhajte ho a vymažte každú stopu po tom druhom.

2. Žiadne automatické vymáhanie. Politika uvedená len v próze je návrhom. Pripojte kontrolu do pracovného postupu pull requestov ako povinnú stavovú kontrolu — aplikáciu DCO pre podpisy, CLA Assistant alebo EasyCLA pre podpisy dohôd — aby sa nedohodnutý príspevok nemohol zlúčiť náhodou alebo z únavy správcu.

3. Ignorovanie firemných prispievateľov. Ak vaše projekty firmy používajú a záplatujú, zamestnanci budú odosielať kód v pracovnom čase. Pri politike CLA to znamená získať podpísané CCLA včas, kým je vzťah vrelý. Pri politike DCO to znamená zabezpečiť, aby požiadavka na podpis bola dostatočne viditeľná, aby sa prvý príspevok nikoho nestal IP incidentom.

4. Predpoklad, že pracovné zmluvy umožňujú prispievanie. Odvrátená strana tej istej mince: ak prispievate do iných projektov, najprv si skontrolujte vlastnú pracovnú zmluvu. Mnohé prevádzajú duševné vlastníctvo z vedľajších projektov súvisiacich s prácou na zamestnávateľa automaticky. Osvedčenie DCO („mám právo to odoslať“) je pravdivé len vtedy, ak to tak hovorí tá dokumentácia.

5. Žiadna politika pre kód vytvorený s pomocou AI. Strojovo generované príspevky vyvolávajú otázky pôvodu, ktoré text DCO z éry roku 2004 ani väčšina šablón CLA nepredvídali. Rozhodnite o svojom postoji — povolené s kontrolou, zverejnené alebo zakázané — a uveďte ho v CONTRIBUTING.md spolu s politikou CLA/DCO, skôr než dorazí váš prvý pull request generovaný AI, nie až po ňom.

Nezabudnite na finančnú stránku svojho projektu​

Tu je časť, ktorú správcovia odkladajú až do sezóny daňových priznaní: vo chvíli, keď váš projekt zarobí prvý dolár — výplaty z GitHub Sponsors, dary cez Open Collective, konzultačná zákazka, ktorá prišla vďaka vášmu README — má financie a financie potrebujú účtovníctvo.

Tá istá disciplína, ktorá robí pôvod príspevkov auditovateľným, robí peniaze projektu zvládnuteľnými. Sledujte príjmy zo sponzorstva oddelene od svojho platu, aby ste vedeli, čo je zdaniteľný príjem zo samostatnej zárobkovej činnosti. Zaznamenávajte výdavky projektu — obnovy domén, minúty CI, popoludnie, ktoré advokát strávil kontrolou vášho CLA — na vlastných účtoch, aby sa odpočty nerozpustili vo výpisoch z osobnej karty. Ak projekt vyrastie do LLC alebo sa pripojí k fiškálnemu hostiteľovi, čisté historické záznamy urobia prechod nudným namiesto forenzného.

Účtovníctvo v čistom texte sa do tohto pracovného postupu nezvyčajne dobre hodí: váš hlavný denník žije v správe verzií vedľa vášho kódu, každý záznam má históriu a nič sa neskrýva v proprietárnom formáte. Naša dokumentácia vás prevedie spustením prvého hlavného denníka za pár minút.

Udržujte účtovníctvo svojho projektu také čisté ako jeho históriu Git​

Výber medzi CLA a DCO zaberie popoludnie; rozmotávanie pôvodu alebo financií projektu o roky neskôr zaberie týždne. Urobte rozhodnutie o prispievaní teraz, zautomatizujte jeho vymáhanie a venujte peniazom projektu rovnakú starostlivosť, akú venujete jeho commitom. Beancount.io poskytuje účtovníctvo v čistom texte, ktoré vám dáva úplnú transparentnosť a kontrolu nad vašimi finančnými údajmi — žiadne čierne skrinky, žiadne uzamknutie u dodávateľa. Začnite zadarmo a zistite, prečo vývojári a finanční profesionáli prechádzajú na účtovníctvo v čistom texte.