Developer Certificate of Origin

Developer Certificate of Origin (DCO, с англ. — «Сертификат происхождения разработчика») — это механизм юридического подтверждения авторства и правомерности вклада в проект с открытым исходным кодом. DCO представляет собой короткое заявление (сертификат), которое разработчик добровольно добавляет к каждому своему коммиту или запросу на слияние (pull request), подтверждая, что он имеет право передать данный код проекту на условиях его лицензии. В отличие от лицензионных соглашений (CLA), DCO не требует передачи исключительных прав на код организации-владельцу проекта, а лишь удостоверяет факт создания или законного получения вклада.

История

Концепция DCO была разработана в 2004 году организацией Linux Foundation в рамках проекта по созданию правовой базы для ядра Linux. Поводом послужили судебные иски, связанные с нарушением авторских прав в ядре, в частности, иск компании SCO Group против IBM, в котором SCO утверждала, что в ядро Linux был включён код, нарушающий её права. Для предотвращения подобных споров и упрощения отслеживания происхождения кода была предложена система Signed-off-by — строка в сообщении коммита, содержащая подпись разработчика.

Первоначально механизм использовался только в разработке ядра Linux, но со временем был принят многими другими проектами, включая Git, Kubernetes, Docker, Eclipse Foundation и проекты под эгидой Apache Software Foundation. В 2010-х годах DCO стал альтернативой более сложным и бюрократизированным Contributor License Agreements (CLA), особенно в сообществах, где ценится простота и децентрализация.

Текст сертификата

Официальный текст Developer Certificate of Origin (версия 1.1) состоит из следующих пунктов:

``` Developer Certificate of Origin Version 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. ```

Сокращённый перевод на русский язык:

• (a) Вклад создан мной полностью или частично, и я имею право передать его под лицензией проекта.
• (b) Вклад основан на предыдущей работе, которая, насколько мне известно, распространяется под подходящей открытой лицензией, и я имею право передать её с изменениями.
• (c) Вклад был передан мне другим лицом, которое подтвердило (a), (b) или (c), и я не вносил изменений.
• (d) Я понимаю и соглашаюсь, что проект и вклад являются публичными, и запись о вкладе (включая мои личные данные) хранится бессрочно.

Механизм работы

Процесс подписания

Для соблюдения DCO разработчик должен добавить в каждый коммит строку вида:

`` Signed-off-by: Имя Фамилия email@example.com ``

Эта строка может быть добавлена автоматически с помощью опции -s или --signoff в Git:

``bash git commit -s -m "Сообщение коммита" ``

При отправке pull request (запроса на слияние) платформа (например, GitHub, GitLab) может проверять, содержит ли каждый коммит в ветке такую строку. Если хотя бы один коммит не подписан, запрос может быть отклонён автоматически или вручную.

Проверка DCO

Для автоматизации проверки используются специальные инструменты, такие как:

• DCO Bot (разработчик — CNCF, Cloud Native Computing Foundation) — бот для GitHub, который добавляет статус проверки к каждому pull request.
• GitLab CI/CD — настраиваемые пайплайны, проверяющие наличие строки Signed-off-by.
• Встроенные средства Git — команда git log --check позволяет проверить историю коммитов на соответствие DCO.

Если коммит не подписан, разработчик может исправить ситуацию, переписав историю (rebase) или добавив подпись через git commit --amend -s. В некоторых проектах также разрешено добавлять подпись в тело pull request, но это менее надёжный способ.

Отличие от Contributor License Agreement (CLA)

DCO и CLA — два основных способа юридического оформления вкладов в открытые проекты, но они принципиально различаются:

DCO считается более лёгким и дружественным к сообществу подходом, так как не требует от разработчика передачи прав на свой код. Однако он не даёт организации-владельцу проекта таких же широких прав, как CLA (например, права на перелицензирование или судебное преследование нарушителей).

Применение в крупных проектах

Ядро Linux

DCO является обязательным требованием для принятия любого патча в ядро Linux. Каждый коммит в репозитории ядра содержит строку Signed-off-by, и отсутствие такой строки является основанием для отклонения. Процесс проверки осуществляется мейнтейнерами подсистем и автоматизированными инструментами.

Kubernetes и CNCF

Проекты, входящие в Cloud Native Computing Foundation (CNCF), такие как Kubernetes, Prometheus, Envoy, используют DCO как стандартный механизм. Для них разработан специальный бот DCO, который проверяет каждый pull request. В случае нарушения DCO бот блокирует слияние до исправления.

Docker

Docker (компания, разработчик одноимённого ПО) также использует DCO для всех вкладов. Это было введено после перехода проекта на открытый исходный код в 2013 году.

Git

Сам Git, будучи системой управления версиями, не требует DCO, но его разработчики (включая Линуса Торвальдса) активно используют механизм Signed-off-by в своей работе.

Критика и ограничения

Несмотря на широкое распространение, DCO имеет ряд недостатков и подвергается критике:

• Юридическая неопределённость: DCO не является договором в строгом смысле слова. Его юридическая сила в разных юрисдикциях может различаться. В частности, в странах континентального права (включая Россию) он может не иметь такой же силы, как в США.
• Отсутствие проверки личности: Подпись в коммите не является криптографической подписью (хотя может быть дополнена GPG-подписью). Любой может поставить чужое имя и email, что делает DCO уязвимым для подделки.
• Сложность для крупных организаций: Для компаний, где код пишут десятки разработчиков, DCO может быть неудобен, так как требует от каждого сотрудника индивидуального подтверждения. В таких случаях часто предпочитают CLA.
• Не решает проблему лицензионной совместимости: DCO подтверждает только право на передачу кода, но не гарантирует, что код не нарушает лицензионные условия третьих сторон (например, если разработчик скопировал код из проекта с несовместимой лицензией).

Интересные факты

• Текст DCO версии 1.1 был написан юристом Linux Foundation Карен Сэндлер (Karen Sandler) и впервые опубликован в 2004 году.
• В 2020 году организация Eclipse Foundation объявила о переходе с DCO на CLA для всех своих проектов, мотивируя это необходимостью более строгого контроля за интеллектуальной собственностью.
• Некоторые проекты (например, Node.js) используют гибридный подход: DCO для небольших вкладов и CLA для крупных (например, от компаний).
• В России DCO используется проектами, входящими в экосистему Linux Foundation, а также некоторыми локальными сообществами, но не имеет законодательного регулирования.

Источники

• Linux Foundation. Developer Certificate of Origin. Version 1.1. 2004.
• Torvalds, L. Linux kernel coding style. Documentation/process/submitting-patches.rst. 2005–2023.
• CNCF. DCO Bot documentation. GitHub. 2018.
• Eclipse Foundation. Eclipse Foundation Contributor License Agreement. 2020.
• Rosen, L. Open Source Licensing: Software Freedom and Intellectual Property Law. Prentice Hall, 2004.