Ваш сайд-проєкт щойно перетнув позначку в 500 зірок, і незнайомець відкрив перший серйозний pull request: 2 000 рядків, які вирішують проблему, яку ви оминали місяцями. Ви хочете натиснути merge. Але перш ніж це зробити, поставте собі незручне питання: чи маєте ви насправді законне право випускати цей код — і продовжувати випускати його під своєю ліцензією, назавжди, незалежно від того, на кого працює цей контриб'ютор?
Якщо у вашому репозиторії немає політики внеску, чесна відповідь — ви не впевнені. Контриб'ютор усе ще володіє авторським правом на кожен написаний ним рядок, і сама лише ліцензія вашого проєкту не завжди вирішує, хто кому що надав. Ця невизначеність залишається невидимою до того дня, коли вона стане важливою: зміна ліцензії, поглинання, корпоративний користувач, який проводить юридичну перевірку ліцензій, або роботодавець контриб'ютора, який заявляє, що ця робота завжди належала йому.
Цю проблему вирішують два механізми, і майже кожен проєкт з відкритим кодом обирає один із них: Угода з контриб'юторами (Contributor License Agreement, CLA) та Сертифікат походження розробника (Developer Certificate of Origin, DCO). Обидва покликані встановити, що контриб'ютор має право зробити внесок і що проєкт має право його розповсюджувати. Вони кардинально різняться за вагою, тертям і тим, що дозволяють вам робити згодом. Цей посібник пояснює, як працює кожен із них, коли обирати який і як налаштувати свій вибір за один вечір.
Чому вашому проєкту взагалі потрібна політика внеску
Авторське право виникає автоматично. У ту мить, коли хтось пише код, він йому належить — без реєстрації, без повідомлення про авторське право. Коли він надсилає його до вашого проєкту, ваша ліцензія з відкритим кодом покриває багато, але залишає прогалини, які закриває лише політика внеску:
- Вхідний дозвіл. Ваша вихідна ліцензія (MIT, Apache-2.0, GPL) говорить користувачам, що вони можуть робити з вашим кодом. Політика внеску чітко встановлює, що вхідні внески надходять на сумісних умовах, тож ви можете розповсюджувати об'єднану роботу, не відстежуючи походження кожного файлу вручну.
- Претензії роботодавців. Більшість трудових договорів передають IP сайд-проєктів роботодавцю, принаймні щодо роботи, пов'язаної з посадою працівника. Політика, яка просить контриб'юторів підтвердити, що вони мають право подавати матеріал, покладає цю відповідальність — і паперовий слід — на контриб'ютора.
- Можливість зміни ліцензії. Якщо ви колись захочете змінити ліцензію, додати комерційну редакцію або передати проєкт фонду, вам знадобляться права від кожного контриб'ютора. Збирати цей дозвіл заднім числом від десятків минулих контриб'юторів — десь між болісно та неможливо. Політика, обрана в перший день, вирішує, чи залишаться ці двері відчиненими.
- Патентний захист. Внески в код можуть нести із собою патентні права. Деякі політики включають явний патентний дозвіл; інші — ні, а це важливіше, ніж більшість мейнтейнерів усвідомлює.
Ніщо з цього не вимагає юридичної фірми на постійному утриманні. Це вимагає обрати CLA чи DCO, записати це у своєму репозиторії та забезпечити автоматичне дотримання. Ось що тягне за собою кожен вибір.
Що таке Угода з контриб'юторами (CLA)?
Угода з контриб'юторами — це підписаний юридичний документ між контриб'ютором і проєктом (або компанією чи фондом, що стоїть за ним). Контриб'ютор підписує його один раз, і цей підпис покриває всі його майбутні внески.
На відміну від ліцензій з відкритим кодом, CLA не стандартизовані. Кожен проєкт пише власну, але більшість зводиться до двох знайомих форм:
Індивідуальна та корпоративна CLA
- Індивідуальна CLA (ICLA): підписується особою, яка робить внесок від власного імені. Зазвичай вона надає проєкту широку ліцензію на авторське право й часто патентну ліцензію, тоді як контриб'ютор зберігає власне авторське право.
- Корпоративна CLA (CCLA): підписується компанією, яка уповноважує своїх працівників робити внески. Компанія надає ті самі права на роботу, яку подають її люди. Проєкти, які приймають корпоративні внески без CCLA, покладаються на те, що керівник кожного працівника знає — і схвалює — а це саме той різновид довіри, який випаровується під час юридичної перевірки.
Ліцензійний дозвіл чи передача авторського права
Більшість сучасних CLA — це ліцензійні дозволи: контриб'ютор зберігає власність і надає проєкту безстрокову, всесвітню, безоплатну ліцензію — часто достатньо широку, щоб дозволити зміну ліцензії. ICLA Фонду Apache Software Foundation — канонічний приклад.
Меншість проєктів використовують передачу авторського права, коли контриб'ютор передає власність цілком (підхід Фонду вільного програмного забезпечення). Передача дає проєкту максимальну свободу захищати права та змінювати ліцензію, але вимагає найбільшого від контриб'юторів і вийшла з моди в проєктах, керованих спільнотою.
Чого CLA коштує вам і вашим контриб'юторам
Компроміс — це тертя. Контриб'ютор, який робить внесок уперше, має залишити pull request, прочитати юридичний документ, підписати його (зазвичай електронно) й дочекатися, поки статус-чек стане зеленим, перш ніж мейнтейнер візьметься до перегляду його коду. Інструменти зробили це майже безболісним — боти на кшталт CLA Assistant коментують pull request із посиланням для підпису й автоматично записують підпис — але це все одно бар'єр між «я виправив ваш баг» і «ви можете злити моє виправлення». Деякі випадкові контриб'ютори відсіюються на ньому.
Натомість проєкт отримує підписаний, придатний для аудиту запис: ця особа, цією датою, надала ці права. Для проєктів із корпоративною підтримкою, проєктів із подвійним ліцензуванням і всього, що колись може бути поглинуте, цей паперовий слід вартий реальних грошей.
Що таке Сертифікат походження розробника (DCO)?
Сертифікат походження розробника був запроваджений Фондом Linux у 2004 році для ядра Linux, саме щоб уникнути ваги CLA. Це не контракт, який контриб'ютор підписує й підшиває до справи. Це коротке засвідчення — п'ять параграфів, версія 1.1 — яке контриб'ютор підтверджує з кожним комітом, додаючи рядок Signed-off-by до повідомлення коміту:
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]>Додати цей рядок — це один прапорець: git commit -s додає його автоматично, використовуючи вашу налаштовану ідентичність Git. Підписуючи, контриб'ютор засвідчує, що:
- Він створив цей внесок (повністю або частково) і має право подати його під ліцензією з відкритим кодом цього проєкту, або
- Його внесок заснований на попередній роботі, яка вже перебуває під відповідною ліцензією з відкритим кодом, що дозволяє таке подання, або
- Він отримав цей внесок від когось іншого, хто засвідчив одне з наведеного вище, і він його не змінював, та
- Він розуміє, що цей внесок і його запис — включно з його підписом — є публічними й зберігаються безстроково.
Ось і весь механізм. Жодного окремого документа, жодного зв'язування акаунтів, жодного онбордингу для кожного проєкту. Дотримання забезпечується статус-чеком: застосунок DCO або еквівалентна перевірка впевнюється, що кожен коміт у pull request має дійсний підпис, і мейнтейнери зливають лише коли він зелений.
Навмисні обмеження DCO
Зверніть увагу, чого DCO не робить. Він не надає жодної ліцензії понад те, що вже передає вихідна ліцензія проєкту — він покладається на те, що внесок надходить на умовах ліцензії проєкту. Він не містить патентного дозволу. А оскільки нічого не підписується й не підшивається для кожного контриб'ютора, немає центрального реєстру того, хто на що погодився; сама історія Git і є записом.
Прихильники вважають це перевагою: низький бар'єр DCO — це і є його суть. Ядро Linux, GitLab (який перейшов із CLA у 2017 році) і Chef (який перейшов у 2016 році) усі дійшли висновку, що підтвердження для кожного коміту дає їм потрібне походження без обтяження кожного контриб'ютора. Технічний комітет OpenStack у 2025 році ухвалив рішення замінити свою CLA на DCO для всіх внесків. Галузева тенденція безпомилкова — але тенденція не є вироком для вашого проєкту, як пояснюють наступні розділи.
CLA vs. DCO поруч
| Вимір | CLA | DCO |
|---|---|---|
| Правовий механізм | Підписана угода, подана один раз на контриб'ютора | Підтвердження для кожного коміту в повідомленні коміту |
| Що робить контриб'ютор | Підписує документ (зазвичай через посилання від бота) | Додає Signed-off-by за допомогою git commit -s |
| Поводження з авторським правом | Явний ліцензійний дозвіл (або передача) проєкту | Внесок надходить під ліцензією проєкту; окремого дозволу немає |
| Патентний дозвіл | Зазвичай включений | Відсутній |
| Свобода зміни ліцензії | Широкі дозволи часто її дозволяють | Жодних додаткових прав; зміна ліцензії потребує згоди кожного контриб'ютора |
| Тертя для контриб'ютора | Вищі: прочитати, підписати, дочекатися перевірки | Мінімальні: один прапорець Git |
| Інструменти контролю | CLA Assistant, EasyCLA, кастомні боти | Застосунок DCO, перевірки повідомлень комітів |
| Запис згоди | База даних підписів | Сама історія Git |
| Покриття роботодавця | Корпоративна CLA явно покриває працівників | Контриб'ютор самостійно засвідчує, що має право подавати |
| Найкраще підходить | Проєктам із корпоративною підтримкою, подвійним ліцензуванням або релевантним для поглинання | Проєктам спільноти, де тертя від внесків має найбільше значення |
Коли CLA — правильний вибір
Обирайте CLA, коли майбутнє проєкту може залежати від прав, які DCO не охоплює:
- Ви плануєте подвійне ліцензування або зміну ліцензії. Якщо комерційна редакція, зміна ліцензії чи перехід від копілефту до дозвільної ліцензії хоч віддалено вірогідні, CLA з широким зворотним дозволом — єдиний легкий спосіб зберегти цю можливість відкритою. Відновлення згоди через роки — це сценарій кошмару.
- За проєктом стоїть компанія. Корпоративні спонсори, покупці та корпоративні клієнти, які проводять юридичну перевірку IP, хочуть реєстр підписів, а не археологію. Google, проєкти Apache та Canonical використовують CLA саме з цієї причини.
- Патенти важливі у вашій сфері. Кодеки, бездротові протоколи, архітектури ML-моделей — у патентно насичених галузях явний патентний дозвіл CLA виконує реальну роботу, яку DCO мовчки пропускає.
- Фонд цього вимагає. Деякі фонди вимагають свою CLA як умову розміщення чи випуску. Перевірте, перш ніж припускати, що DCO достатньо.
Якщо ви обираєте цей шлях, тримайте саму CLA стандартною й нудною: почніть з Apache ICLA або шаблону Harmony, а не пишіть із нуля, опублікуйте як індивідуальну, так і корпоративну версії, і під'єднайте бота для підпису в перший же день, щоб тертя було одним кліком, а не круговертю з PDF.
Коли перемагає DCO
Обирайте DCO, коли внески — це життєва сила, а тертя — ворог:
- Проєкти спільноти з багатьма випадковими контриб'юторами. Виправлення документації, виправлення друкарських помилок, невеликі патчі — внески, які найімовірніше відсіються на бар'єрі підпису, також ті, з якими DCO впорається витончено.
- Дозвільна ліцензія, без планів зміни ліцензії. Якщо проєкт назавжди залишиться MIT або Apache-2.0 і жодної комерційної редакції не передбачається, додаткові права CLA дають вам мало.
- Соло-мейнтейнери та малі команди. DCO не потребує інфраструктури для підписів, юридичної особи для зберігання угод і процесу для контрасигнації корпоративних форм. Це управління, яке можна вести з файлу
CONTRIBUTING.mdта статус-чеку. - Позиція максимальної сумісності. Деякі контриб'ютори — особливо ті, хто працює у великих компаніях із суворою IP-політикою — можуть підписати DCO, але не можуть підписати зовнішню CLA без юридичного перегляду. DCO залишає ці двері відчиненими.
Що б ви не обрали, запишіть це рішення. CONTRIBUTING.md, який викладає політику, показує точний потік підпису чи підписання й посилається на повний текст, усуває найпоширеніше джерело плутанини: контриб'ютори вгадують вимоги з невдалого статус-чеку.
5 помилок, які підривають будь-який вибір
1. Вказувати обидва. Найпоширеніша реальна невдача — це CONTRIBUTING.md, який вимагає підписів DCO в одному параграфі й підписів CLA в іншому — зазвичай після незавершеної міграції. Контриб'ютори дотримуються однієї інструкції, інша перевірка не проходить, а мейнтейнери однаково зливають — що зводить нанівець сенс обох. Оберіть один механізм, забезпечте його дотримання й видаліть усі сліди іншого.
2. Відсутність автоматичного контролю. Політика, викладена лише прозою, — це пропозиція. Вбудуйте перевірку у свій робочий процес pull request як обов'язковий статус-чек — застосунок DCO для підписів, CLA Assistant або EasyCLA для підписань — щоб неузгоджений внесок не міг злитися випадково чи через втому мейнтейнера.
3. Ігнорування корпоративних контриб'юторів. Якщо компанії використовують ваш проєкт і патчать його, працівники подаватимуть код у робочий час. За політики CLA це означає отримати підписану CCLA заздалегідь, поки стосунки теплі. За політики DCO це означає переконатися, що вимога підпису достатньо помітна, щоб перший внесок нікого не перетворився на IP-інцидент.
4. Припущення, що трудові договори дозволяють робити внески. Зворотний бік тієї ж медалі: якщо ви робите внески в інші проєкти, спершу перевірте власний трудовий договір. Багато хто за замовчуванням передає IP сайд-проєктів, пов'язаних із роботою, роботодавцю. Засвідчення DCO («я маю право це подавати») істинне лише тоді, коли ці папери так кажуть.
5. Відсутність політики для коду, створеного ШІ. Згенеровані машиною внески породжують питання походження, яких не передбачав ні текст DCO епохи 2004 року, ні більшість шаблонів CLA. Визначте свою позицію — дозволено з переглядом, з розкриттям чи заборонено — і викладіть її в CONTRIBUTING.md поряд із вашою політикою CLA/DCO, перш ніж надійде ваш перший згенерований ШІ pull request, а не після.
Не забувайте про грошовий бік вашого проєкту
Ось частина, яку мейнтейнери відкладають до податкового сезону: у ту мить, коли ваш проєкт заробляє свій перший долар — виплати GitHub Sponsors, пожертви Open Collective, консультаційна робота, що прийшла завдяки вашому README — у нього з'являються фінанси, а фінанси потребують бухгалтерії.
Та сама дисципліна, яка робить походження внесків придатним для аудиту, робить гроші проєкту керованими. Відстежуйте дохід від спонсорства окремо від зарплати, щоб знати, який це оподатковуваний дохід від самозайнятості. Записуйте витрати проєкту — поновлення домену, хвилини CI, вечір, який юрист витратив на перегляд вашої CLA — на окремих рахунках, щоб відрахування не випаровувалися у виписки з особистих карток. Якщо проєкт виросте в LLC або приєднається до фіскального хоста, чисті історичні записи зроблять перехід нудним, а не криміналістичним.
Облік у простому тексті надзвичайно добре підходить для цього робочого процесу: ваш реєстр живе в системі контролю версій поряд із вашим кодом, кожен запис має історію, і ніщо не ховається у пропрієтарному форматі. Наші документи пояснюють, як запустити перший реєстр за хвилини.
Тримайте бухгалтерію проєкту такою ж чистою, як його історію Git
Вибір між CLA та DCO займає вечір; розплутування походження чи фінансів проєкту через роки займає тижні. Ухваліть рішення про внески зараз, автоматизуйте його контроль і приділіть грошам проєкту таку саму увагу, як його комітам. Beancount.io пропонує облік у простому тексті, який дає вам повну прозорість і контроль над вашими фінансовими даними — жодних чорних скриньок, жодної прив'язки до постачальника. Почніть безкоштовно і дізнайтеся, чому розробники та фінансові фахівці переходять на облік у простому тексті.
