DCO не является CLA
Про отличия между сертификатом происхождения разработчика (DCO) и лицензионным соглашением с контрибьютором (CLA).
Этот пост - часть серии постов Line by Line.
Чтобы иметь возможность использовать программное обеспечение, которое вы найдете в Интернете, вам нужно несколько вещей:
• код
• копия правил использования кода — “лицензионные условия”
• доказательство того, что кто-то действительно применил эти условия к коду - “предоставление лицензии”
• доказательства того, что кто-то действительно имел законные полномочия применять эти условия к коду, иногда называемые “источником происхождения”
Все лицензии на программное обеспечение, DCO и CLA являются лишь средствами достижения этих целей:
DCO
DCO был написан специально для процесса разработки ядра Linux. Он краткий. Мы можем прочитать его, выбрав те части, которые помогут нам получить гарантии, которые пользователи хотят получить от открытого программного обеспечения:
Внося свой контрибьют в этот проект, я подтверждаю, что:
(а) Контрибьют был создан мной полностью или частично, и я имею право представить его в соответствии с лицензией с открытым исходным кодом, указанной в файле; или
(b) Контрибьют основан на предыдущем произведении, на которое, насколько мне известно, распространяется соответствующая лицензия с открытым исходным кодом, и в соответствии с этой лицензией я имею право представить это произведение с изменениями, независимо от того, создано ли оно мной полностью или частично, под той же лицензией с открытым исходным кодом (за исключением случаев, когда мне разрешено представлять материалы по другой лицензии), как указано в файле; или
(c) Контрибьют был предоставлен непосредственно мне каким-либо другим лицом, которое подтвердило (a), (b) или (c), и я не вносил в него изменений.
(d) Я понимаю и соглашаюсь с тем, что этот проект и контрибьют являются общедоступными и что запись о контрибьюте (включая всю личную информацию, которую я предоставляю вместе с ним, включая моё подписание) хранится неопределенный срок и может быть распространена в соответствии с этим проектом или соответствующей лицензией (лицензиями) с открытым исходным кодом.
Два важных комментария:
Во-первых, DCO неоднократно упоминает о праве на получение лицензии — источнике происхождения — как напрямую, когда исходный код поступает непосредственно от одного разработчика, так и косвенно, когда код передается от разработчика к разработчику и в конечном итоге Линусу[1].
Во-вторых, DCO предполагает, что условия лицензии указаны в каждом файле, и что условия лицензии в верхней части файла означают, что произведение в этом файле лицензируется в соответствии с этими условиями. DCO предполагает, что лицензии с открытым исходным кодом “задействованы”, но не выполняет работу по их задействованию.
В DCO заложены ещё более важные допущения, которые вы можете по-настоящему увидеть, только читая между строк или опираясь на контекст:
Во-первых, проект[2] является GPL, а конкретно GPLv2. Если вы взломаете код ядра, у вас будет только один допустимый вариант лицензии: GPLv2. Если вы вводите код, который изначально был разработан независимо, он должен находиться под какой-либо разрешительной лицензией, “совместимой” с GPLv2.
Во-вторых, “подписание” означает подписание строк, добавленных к коммитам, например, с флагом --signoff для коммита в git. По мере того, как патчи попадают в списки рассылки и передаются от рецензента к рецензенту, на пути к Линусу на каждом этапе добавляется новый подписанный автор, документирующий каждого, кто приложил руку на этом пути.
В-третьих, ядро Linux застряло на GPLv2 и никогда не получит лицензию на других условиях. Ядро не перешло на GPLv3, когда оно было выпущено, и, с практической точки зрения, это, вероятно, не смогли бы сделать, даже если захотели бы. Слишком много людей внесли свои контрибьюты в создание ядра. Они, а также их работодатели или клиенты являются правообладателями таких произведений. Они никогда не предоставляли какой-либо широкой лицензии фонду Linux Foundation или организации, дающей этому фонду право лицензировать их произведения на других условиях.
здесь имеется в виду Линус Торвальдс, создатель Linux - прим. пер. ↩︎
имеется в виду, код ядра Linux (Linux kernel) - прим. пер. ↩︎
В этом посте детали по лицензионным вопросам на Linux
Предположительные допущения
Здесь слишком много предположений. Давайте перечислим их вместе, в самых общих чертах:
- Условия лицензии указаны в каждом файле.
- Файлы кода, содержащие лицензионные условия, лицензируются в соответствии с этими условиями.
- Выбор лицензионных условий для контрибьютов устанавливается заранее или жёстко ограничен.
- Участники используют функцию подписания.
- Эта функция применяет сертификат разработчика о происхождении для произведения к тем коммитам, где он присутствует.
- Проект не может или не будет нуждаться в изменении своих лицензионных условий в будущем.
Допущения 2 (лицензирование файлов) и 5 (последствия авторизации) – это, по сути, юридические вопросы. Отложим их. Может быть, в другой раз в других постах в блоге.
Из остального: как много для вашего проекта?
Предположение 1 – условия лицензирования в файлах - это выбор рабочего процесса. Иногда это предположение остаётся в силе, как во многих Java-проектах, где файлы обычно начинаются с комментариев к коду. Иногда этого не происходит, как во многих проектах на JavaScript, где условия лицензии отображаются в файле LICENSE или на которые ссылаются в метаданных package.json.
Предположение 3 – ограниченный выбор условий лицензии – зависит от лицензии, применяемой к существующему коду проекта. Для проектов под GPLv2 это предположение в значительной степени справедливо. Для проектов под GPLv2+ или GPLv3+ выбор может быть больше, чем между версиями GPL.
Для проектов под MIT, BSD, Apache 2.0, Blue Oak или других проектов с разрешённой лицензией не существует однозначных условий лицензирования контрибьютов. Эти лицензии позволяют вносить изменения, дополнения и другие произведения на любых условиях, которые пожелают разработчики, включая коммерческие условия, которые никто не назвал бы “открытыми”.
Я бы сказал, что предположение 6 никогда не бывает безопасным, даже для ядра Linux. Как можете видеть, суды могут начать толковать или применять GPLv2 неудачным образом. Например, они могут ослабить его правило авторского лева или ясность, которую оно обеспечивает в отношении условий для исправлений и контрибьютов. Закон также может измениться таким образом, что потребуется обновить или исправить GPLv2, чтобы эта лицензия работала по назначению или вообще работала. Привязка к конкретным условиям лицензии приносит желанную уверенность в неизменности, наряду со всей её опасной негибкостью.
Действующее CLA
Де-факто стандартными условиями лицензионного соглашения о внесении контрибьютов являются формы фонда Apache Foundation. Многие известные компании, использующие CLA, в основном просто развивают формы Apache, заменяя “Apache” своим названием, с небольшими дополнительными настройками или вообще без них. Зная про это, просматривать множество CLA станет намного проще. Сначала проведите различие с формой от Apache.
Форма CLA в Apache для физических лиц, в отличие от компаний, состоит всего из двух страниц. Давайте рассмотрим основные условия, пропустив первоначальный раздел с определениями:
2.Предоставление лицензии на авторское право. В соответствии с положениями и условиями настоящего Соглашения, настоящим Вы предоставляете Фонду и получателям программного обеспечения, распространяемого Фондом, бессрочную, всемирную, неисключительную, безвозмездную, безотзывную лицензию авторских прав на воспроизведение, создание производных произведений, публичный показ, публичное исполнение, сублицензирование, а также распространение Ваших контрибьютов и подобных производных произведений.
Здесь у нас есть некоторые лицензионные условия и чёткое заявление о том, что они применяются к некоторому программному обеспечению, а именно к контрибьюту, включаемому в проект.
Если вам это кажется знакомым, то так и должно быть. Сравните предоставление лицензии в тексте Apache 2.0. Но это ничем не похоже на DCO. Мы не видели ничего подобного в DCO.
Обратите также внимание на то, чего не хватает в лицензии Apache. Нет никаких условий в отношении файлов уведомлений, указания авторства или чего-либо подобного. Это означает, что фонд Apache Foundation получает более широкие права на поступающий контрибьют, чем те, которые он предоставляет под лицензией Apache 2.0. Но это также означает, что в будущем фонд получит возможность лицензировать контрибьюты на других условиях — возможно, под Apache 3.0. Их формы CLA не предполагают, что можно навсегда привязывать проекты к Apache 2.0 без возможности исправления или замены условий лицензии в будущем.
Обратите также внимание, что это лицензия на авторское право, а не отчуждение авторских прав. Отсюда и “лицензионное соглашение с контрибьютором”. Автор остаётся владельцем авторских прав на свои материалы.
Я бы сказал, что практическая разница между передачей авторских прав и отчуждением авторских прав сильно преувеличена. Особенно это касается контрибьютов в крупные существующие проекты, предоставляемых на открытых условиях. Но для тех, кто испытывает инстинктивное отвращение к идее отчуждения исключительного права, стоит отметить, что это не то, чем занимаются CLA. Называть отчуждение исключительного права соглашением с контрибьютором (CLA) или лицензионным соглашением с авторским левом, неправильно.
3.Предоставление лицензии на патентные права. В соответствии с положениями и условиями настоящего Соглашения, настоящим Вы предоставляете Фонду и получателям программного обеспечения, распространяемого Фондом, бессрочную, всемирную, неисключительную, безвозмездную, безотзывную (за исключением случаев, указанных в этом разделе) патентную лицензию на использование, предложение к продаже, импорту и передаче иным образом Произведение, если такая лицензия распространяется только на те патентные заявки, на которые Вы имеете право, и которые обязательно нарушаются только в результате Вашего Контрибьюта(ов) или в результате сочетания Вашего Контрибьюта (ов) с Произведением, на которое был предоставлен такой(ие) Контрибьют(ы). Если какая-либо организация подаст патентный иск против Вас или любой другой организации (включая перекрёстный иск или встречный иск в судебном процессе), утверждая, что ваш Контрибьют или Произведение, в которое вы внесли свой Контрибьют, представляет собой прямое нарушение патентных прав, то любые патентные лицензии, выданные этой организации в соответствии с настоящим Соглашением на этот Контрибьют или Произведение, в которое вы внесли свой Контрибьют, представляют собой прямое нарушение патентных прав на Контрибьют или Произведение, и все патентные лицензии должны быть прекращены с даты подачи такого иска.
То, что мы только что видели в отношении авторского права, мы теперь видим и в отношении патентов. Сравните это с разделом 3 лицензии Apache 2.0, и вы увидите, что в целом всё то же самое.
4.Вы заявляете, что имеете законное право предоставить вышеуказанную лицензию. Если ваш(и) работодатель(и) обладает(ют) правами на интеллектуальную собственность, которую вы создаете и которая включает ваши контрибьюты, вы подтверждаете, что получили разрешение на предоставление контрибьютов от имени работодателя, что ваш работодатель отказался от таких прав в отношении ваших контрибьютов в Фонд или что ваш работодатель заключил отдельное корпоративное соглашение (CLA) с Фондом.
Это первая часть о происхождении в Apache CLA для физических лиц. Быть “законно уполномоченным” и “иметь право” указывают на одно и то же.
Если вы думаете, что это напоминает DCO, то вы правы. Это выполняет ту же самую задачу. Но в то время, как текст DCO во многом про распространение исправлений (патчей) среди множества контрибьюторов и ревьюеров, текст Apache CLA для физических лиц больше про то, имеют ли физические лица, в отличие от их работодателей или клиентов, законное право лицензировать контрибьюты. Это разумно: большая часть работы над программным обеспечением подпадает под действие правил и контрактов работы по найму, которые по контракту делают правообладателем работодателя или заказчика, а не разработчика. В рамках процесса Apache CLA, часто используется как корпоративный CLA от компаний, так и индивидуальные CLA от разработчиков.
5.Вы заявляете, что каждый Ваш контрибьют является Вашим оригинальным произведением (см. раздел 7 о материалах, представленных от имени других лиц). Вы заявляете, что представленные Вами Контрибьюты содержат полную информацию о любых сторонних лицензиях или других ограничениях (включая, но не ограничиваясь, соответствующих патентах и товарных знаках), о которых вам лично известно и которые связаны с любой частью Ваших Контрибьютов.
Здесь мы находим отголоски формулировок DCO об оригинальных произведениях и произведениях, заимствованных у других авторов, которые уже выпустили их на своих собственных лицензионных условиях. Вы можете прочитать “заявляете” как юридический синоним "говорите", “обещаете” или “гарантируете”. Таким образом, этой формулировкой контрибьютор убеждает других в том, что у него есть права, необходимые для внесения предоставления своего контрибьюта.
6.Мы не ожидаем, что Вы будете оказывать поддержку по Своим Контрибьютам, за исключением случаев, когда Вы сами этого желаете. Вы можете предоставлять поддержку бесплатно, за определенную плату или вообще её не предоставлять. За исключением случаев, предусмотренных применимым законодательством или оговоренных в письменной форме, Вы предоставляете свои материалы на УСЛОВИЯХ “КАК ЕСТЬ”, БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ УСЛОВИЙ, явных или подразумеваемых, включая, помимо прочего, любые гарантии или условия ПРАВА СОБСТВЕННОСТИ, НЕНАРУШЕНИЯ ПРАВ, КОММЕРЧЕСКОЙ ЦЕННОСТИ или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.
Опять же, это отголоски Apache 2.0 и почти всех открытых лицензий на программное обеспечение, которые обычно отказываются от гарантий, чтобы избежать финансовой ответственности разработчика за проблемы с произведением, которое он изначально предоставил бесплатно. Обратите внимание, что язык со ВСЕМИ ЗАГЛАВНЫМИ БУКВАМИ здесь короче, чем в Apache 2.0, MIT или BSD. Есть несколько случаев, когда контрибьютор может быть привлечен к юридической ответственности в соответствии с CLA для физических лиц: когда он сделал ложные заявления о том, что имеет законное право лицензировать свои контрибьюты.
7.Если Вы хотите представить произведение, которое не является Вашим оригинальным творением, Вы можете представить его Фонду отдельно от любого контрибьюта, указав полную информацию о его источнике и о любых лицензиях или других ограничениях (включая, но не ограничиваясь, соответствующих патентах, товарных знаках и лицензионных соглашениях), в отношении которых вы лично осведомлены и явно отмечаете произведение как “Предоставленное от имени третьей стороны: [с указанием её имени здесь]”.
Вспомните пункт (b) из DCO, в котором говорится об обеспечении уверенности, что произведение, которое не ваше, распространяется под хорошей открытой лицензией.
8.Вы соглашаетесь уведомлять Фонд о любых ставших вам известными фактах или обстоятельствах, которые могут сделать эти заявления неточными в каком-либо отношении.
Если вы подписали CLA, но становится ясно, что люди на самом деле не должны полагаться на подписанное вами CLA, это то, о чем хотят знать пользователи программного обеспечения Фонда и Apache.
Больше сведений о лицензии Apache 2.0 смотрите здесь
Так для чего же нужен DCO?
Исходный сертификат разработчика делает меньше, чем лицензионное соглашение с разработчиком, как, например, Apache CLA для физических лиц. Но и DCO, и Apache CLA для физических лиц функционируют как части систем, предназначенных для выполнения всей работы. В процессе рассмотрения:
Лицензия Apache 2.0, индивидуальные и корпоративные CLA с Apache и рабочий процесс Apache были разработаны совместно для совместной работы. Они восполняют пробелы друг друга, объединяясь в надежную систему управления интеллектуальной собственностью для разработки открытого программного обеспечения.
GPLv2, DCO и Kernel Flow также работают вместе как единая система, во многом аналогичным образом. Они также подтверждают предположения друг друга. Но они разрабатывались поэтапно.
DCO оказался сильно специфичным — он отлично подходил для нескольких проектов и совершенно не подходил для большинства других — по ряду причин.
Во-первых, DCO был последней внедренной частью системы ядра. GPLv2 уже была написана и давно применялась к коду ядра. Kernel Flow развивался и продолжает развиваться, но в то время уже вовсю работал.
Во-вторых, ядро [Linux] – невероятно важный проект, достаточно важный, чтобы требовать проведения юридической работы и обсуждения процесса, связанного с ядром. И другое важное программное обеспечение того времени, такое как сам Git, также использовало Kernel Flow. В 2004 и 2006 годах ещё не был запущен подход с пулл-реквестами и репозиториями в стиле GitHub.
В-третьих, важность ядра привела к тому, что оно подверглось юридической критике со стороны компаний, претендующих на его часть или его успех. DCO стал непосредственным ответом на заявления компании SCO о том, что части исходного кода Linux были получены не от Линуса или других разработчиков открытого программного обеспечения, а из оригинального исходного кода UNIX, лицензированного университетами и компаниями, права на который купила SCO.
У Линуса и разработчиков ядра не было письменных отчётов, показывающих, откуда взялась каждая строка кода ядра и кто её лицензировал. Это дало SCO возможность заявить — в конечном счете безуспешно, но в промежуточный период вызывало раздражение, — что код без документально подтверждённого происхождения принадлежит ей. DCO и процесс подписания были запущены для создания недостающей документации в будущем.
Претензия заключалась не в том, что были предоставлены части ядра, а в том, что они использовались под неправильной лицензией. Эта проблема лицензионных условий или предоставления лицензии, решаемая CLA для оригинального произведения и приемлемыми лицензиями с открытым исходным кодом для всего остального. Претензия заключалась в том, что авторы вообще не имели законного права вносить свои контрибьюты в код. Это проблема происхождения, решаемая лицензией и процедурами ядра с добавлением DCO.
scl-paullauria
Детали судебных притязаний SCO смотрите здесь
Создайте систему
При лицензировании контрибьютов, как и во многом другом, проект должен продумать свои цели и риски, а затем убедиться, что его условия и процессы соответствуют им в той мере, в какой это возможно при разумных затратах и неудобствах.
Некоторые проекты настолько малы, узкоспециализированы или одноразовы, и так будет всегда, что любые инвестиции в процесс в лучшем случае являются формой, практикой или случайным развлечением. Некоторые проекты не сталкиваются с серьёзным риском возникновения проблем с происхождением [контрибьютов]. Некоторые проекты хотят всегда придерживаться одного конкретного набора лицензионных условий, не говоря уже о рисках. Чёрт возьми, большинство проектов никогда не получают внешней поддержки. Возможно, им не следует тратить время или энергию на то, чтобы справиться с ними, пока она не появится.
К сожалению, слишком многие проекты явно имеют как цели, так и риски, связанные с лицензированием контрибьютов, и либо ничего не предпринимают для их решения, либо переходят от целостной системы, подобной системе CLA, к бессвязной, дырявой мешанине, основанной на вере в то, что простое произнесение названия “DCO” приведёт к изгнанию злых духов авторского права.
Несколько откровенных советов, объединяющих всё это вместе:
По моей оценке, если вы добавите DCO в файл типа CONTRIBUTING.md и продолжите свой весёлый путь с использованием процесса разработки на основе пулл-реквестов, вы практически ничего не добьётесь, кроме того, что обманете себя, думая, что вы поставили чекбокс. Если вы разместите текст DCO где-нибудь без лицензии, например GPL, которая касается последующего лицензирования, или рабочего процесса разработки, например Kernel Flow, в котором разработчики обращаются к DCO, это не приведет к немедленному краху вашего проекта и не привлечет к вам огромное количество юристов. Но если вашему проекту повезло, что он имеет значение, и если вам не повезло, что у него возникли проблемы, это сработает примерно так же, как старый пыльный огнетушитель, оставшийся от последнего арендатора, который никто так и не удосужился проверить. В чрезвычайной ситуации это может привести к небольшому разочарованию и без того стрессовой ситуации. Это не спасёт положение.
Если вас раздражают CLA, сделайте их менее раздражающими. Настройте CLA-бота. Попросите людей согласиться с условиями через комментарии к запросу на удаление или добавьте файлы в подкаталог вашего репозитория перед объединением. Все они, как и DCO, вводятся постфактум, чтобы восполнить пробелы в несовершенном подходе к управлению контрибьютами. GitHub не предоставлял готовое решение для управления контрибьютами для потока пулл-реквестов, а также не предлагал его сторонним разработчикам. Если это необходимо для вашего проекта, вы должны использовать своё решение.
Если простое упоминание о CLA вызывает у вас приступы паники или апоплексический удар, я сделаю для вас всё, что в моих силах[1]. Ознакомьтесь с этими проблемами и с тем, как их решают юридические инструменты. Прочтите несколько CLA и разберитесь в них. Поделитесь этим постом, если это поможет. Смотрите также более раннюю, более короткую статью, посвященную вопросам политики, или эту статью о том, почему мы всё ещё заполняем пробелы GitHub, несмотря на их собственные условия предоставления сервиса.
CLA и процессы по ним документируют лицензионные условия, предоставление лицензий и достоверность происхождения. Они не произносят магических заклинаний. Если завтра я отправлю вам юридическую рассылку, в которой утверждаю, что какая-то часть кода вашего проекта нарушает лицензионные условия моего клиента или была отправлена кем-то, у кого нет законного права лицензировать её, что вы собираетесь прикрепить или на что сослаться в своём ответе, чтобы доказать, что я неправ? Вот в чём вопрос. “Мы объединили пулл-реквест, добавив DCO в файл CONTRIBUTING, потому что видели, как это делают другие проекты” – это не ответ.
здесь имеется в виду автор оригинальной статьи – прим. пер. ↩︎
Смотрите CLA Яндекса как один из примеров CLA российских компаний (и моей работы)