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