CLA или почему ваш PR в Open Source не может быть принят

Всем привет!

Вероятно, часть людей уже меня знает, но всё же представлюсь. Меня зовут Михаил Поливаха, я являюсь техническим лидером проекта Axelix.

Я уже какое-то время назад выпускал статью, которая поясняла, что такое Copyright, что такое лицензия в общем её смысле, какие типы лицензий бывают и т.д. Рассматривайте данную статью как некое продолжение этой прошлой статьи.

Сегодня я хочу осветить такой момент, как CLA и почему в том или ином виде он есть у любого крупного Open Source-а. Мы также рассмотрим, как AI влияет на CLA и на принятие контрибьюшенов со стороны. Есть ещё DCO, и его, например, уже давно использует Linux, и Spring Framework в своё время перешёл на него с CLA. Но DCO, я думаю, стоит обсудить отдельно. Если интересно будет — пишите, я потрачу время, расскажу.

В общем, без долгих прелюдий, начнём.

Глубина Проблемы

Чтобы глубже погрузиться в проблему, расскажу историю. У нас в Axelix был случай, когда мы буквально закрыли PR стороннего контрибьютора (просто не смогли принять его изменения) в силу того, что человек не подписал CLA (это делается буквально за 1 мин). Ссылку я давать публично не буду дабы избежать недопониманий, но кому надо — найдет.

Казалось бы, формальность, но я скажу следующее — большинство долгоживущих Open Source проектов (включая Axelix), даже если Ваше изменение является очень ценным, просто физически не смогут без этого принять патч. Вот почему.

Итак, Вы решили открыть PR

Как мы уже обсуждали в прошлой статье, когда Вы (пока выносим из уравнения AI для простоты, о нём чуть позже) написали код, то Вы владеете copyright-ом на этот код. Если же мы говорим про контрибьюшены в Open Source, то скорее всего, Вы не написали целый проект с нуля, а Вы доработали некоторое уже существующее поведение:

• Внесли новые source файлы

• Обновили уже существующие

• Или даже удалили source файлы, авторами которых Вы не являетесь!

И вот результатом Вашей интеллектуальной работы является некоторый git patch, который представлен в виде PR-а в репозитории. И вот Вы зашли на GitHub и, собственно, открыли Pull Request. Ура.

Как это видят maintainer-ы проекта

Теперь давайте представим то, как это видит core команда (то есть та небольшая команда, которая разрабатывает продукт). В зависимости от того, как договорились между собой maintainer-ы продукта, интеллектуальным правом (IP) на продукт может владеть:

• Либо коллективно вся команда (Вася владеет IP на этот кусок кода, Оля — на вот этот и т.д.)

• Либо может владеть какая-то “сущность”, назовём её так (базовый пример — юр. лицо, компания Oracle, например)

• Либо какой-то один человек (такие случаи редки)

Но факт есть факт: когда Вы вносите contribution в проект, этот проект уже имеет какую-то структуру Copyright. Она может быть разная, но она всегда такая, что позволяет организации/компании выпускать релизы, возможно делать dual-licensing (вспоминаем кейс с MySQL) и т.д. И вот в этот copyright-ный салат приходит Ваш PR. Начинаем карусель.

Так а в чём дело-то?

Дело в том, что Вы владелец copyright на Ваш git patch. Получается, что если Ваш contribution просто так принять в проект, то в общую структуру copyright-а войдёте Вы со своими изменениями.

Это проблема? В общем случае да, это проблема, и вот почему.

Ну что, выпускаем релиз!

Предположим, что безо всякого CLA (мы о нём ещё не говорили, об этом позже), Ваш патч принимается. PR сливается, новый релиз с учетом Ваших изменений (например, публикация в maven central) выходит на свет… Или нет? Вообще-то релиз продукта на условный maven central это распространение дистрибутива. Причем дистрибутива, который собран из кода, владельцем copyright-а которого являетесь Вы.

Давали ли Вы разрешение на публикацию своего кода в релизе…? В конкретно этом случае лёд довольно тонкий, но он есть.

Часто саму по себе публикацию покрывает лицензия проекта. Например, в Apache License 2.0 есть раздел 5 (Contributions): по нему любой Ваш вклад по умолчанию лицензируется на тех же условиях, что и проект.

Ещё раз — когда Ваши измененяи принимает проект, он принимает их чаще всего на условиях своей лицензии (опять же, как в кейсе с Apache License 2). Но этого часто недостаточно.

То есть на «просто выпустить релиз» разрешение, как правило, у мейнтейнеров есть. Ну ладно, с релизом справились, поехали дальше.

Делаем re-licensing

А вот другой пример. Допустим, проект, в который Вы решили внести патч, называется OpenRewrite. И вот Вы внесли туда свой патч, всё круто. А потом по ряду причин Moderne (основной разработчик OpenRewrite) решает, что хочет сменить лицензию с ALV2 на Source Available License. Это, как мы помним из прошлой статьи, называется re-licensing.

Давали ли Вы разрешение на re-licensing именно своего кода? Явным образом нет. Получается, делать подобное OpenRewrite вроде как не может (кстати, я не просто так взял именно эту компанию для примера. Почитайте вот эту статью. Там как раз описывался процесс re-licensing OpenRewrite и его нюансы).

И вот тут кроется суть: большая часть махинаций с лицензиями:

• Sublicensing

• Dual-licensing

• Re-licensing (как в примере с Moderne)

и т.д. — вот это уже та область, где без явного соглашения со стороны контрибьютера действовать крайне опасно. Надеюсь, я донёс мысль.

Как это решают на практике?

А что тогда делать?

И тут концептуально 2 варианта:

1. Вариант первый: Вы передаете copyright на свои изменения условным владельцам продукта. Тем самым, Вы, по сути, отдаете авторство на свои изменения в проекте.

2. Вариант второй: Вы оставляете за собой авторство своих изменений и copyright на свои изменения, НО — при этом Вы позволяете мейнтейнерам проекта Ваши изменения: re-license-ить, распространять, копировать и т.д.

Оба варианта предполагают наличие некоторого соглашения между Вами как контрибьютором, и между тем зоопарком, который держит copyright на проекте.

Это соглашение и называется CLA. Contributor License Agreement. Если простыми словами, это соглашение, которое говорит о том, на каких условиях уже Ваш git patch залетает в общую кодовую базу.

От себя скажу, что первый способ именно в Open Source очень непопулярный, хотя были компании, которые так делали (но опять же, практика показала, что это прямо торпеда в борт, очень опасно для работы с сообществом).

Axelix, как и большинство других проектов, оставляет за Вами Ваше авторство и не претендует на него (Вообще, CLA Axelix-а во многом похож на Google-овский, который используется в проектах Guava, Flogger и т.д. Вот его полная версия, опять же, для любознательных).

А вот когда Вы работаете на какую-то компанию (на банк, например), Вы подписываете трудовой договор, NDA и приложения к трудовому договору. В этих документах закрепляется, что все права на произведенный Вами код в таких-то условиях принадлежат Вашему работодателю. Это вот как раз вариант первый.

На эту тему кстати в своё время было долгое и мучительное противостояние у Nginx и компании Rambler. Корнем там стал как раз тот факт, что Игорь Сысоев, автор Nginx, создавал его, пока был сотрудником Rambler, и Rambler решил, что может претендовать на интеллектуальное право. Формально претензии предъявлял не сам Rambler, а связанная с ним кипрская Lynwood Investments, которой Rambler передал права; параллельно было и уголовное дело с обысками в офисе Nginx. В итоге, во многом благодаря массовой и бурной реакции общественности, дело фактически развалилось, иск был отозван, и с Nginx всё хорошо.

В общем, друзья, CLA это важно. Без него у maintainer-ов не будет полного и однозначного набора прав, чтобы уверенно распоряжаться Вашим кодом (особенно там, где речь про вопросы его лицензирования). Золотая середина, как я уже сказал — признаем авторство за Вами, но Вы даете возможность делать по сути что угодно с Вашим кодом. Это хорошая и проверенная временем стратегия.

Небольшой Off-Top

Кстати, для джавистов, наверняка замечали вот такие комментарии в Spring Boot или в Axelix:

/** * Immutable semantic version value object. * ... rest of the javadoc * * @author Artemiy Degtyarev * @author Nikita Kirillov * @author Mikhail Polivakha */public class SemanticVersion implements Comparable<SemanticVersion> {    private static final Comparator<SemanticVersion> ORDER = Comparator.comparingInt(SemanticVersion::major)            .thenComparingInt(SemanticVersion::minor)            .thenComparingInt(SemanticVersion::patch)            // A qualifier (e.g. a pre-release like -SNAPSHOT) sorts below the same version without one.            .thenComparing(version -> version.qualifier == null);  //}

И вот тут есть javadoc теги, например @author Artemiy Degtyarev (Артём, привет! Спасибо за contribution). Тут важно не путать: сам по себе @author тег не передаёт и не определяет владельца copyright. Он лишь фиксирует авторство и attribution (кто внёс вклад в файл). Понятное дело, кто именно владеет правами, определяют закон и договоры (CLA, трудовой договор), а не javadoc. Тем не менее, и Spring Framework, и Axelix просят Вас добавлять себя в @author тег в javadoc как раз чтобы зафиксировать факт Вашего авторства и вклада в данный файл.

А как же AI на это влияет?

Вот тут наша с Вами карусель начинает крутиться с ещё большей скоростью. И дело вот в чём.

Важно (!): отрасль до сих пор стабилизируется. Судебная система ещё даже близко не переварила AI. Всё ещё может поменяться. К тому же, речь будет в первую очередь про практику в США, т.к. там она наиболее оформлена. В ЕС, РФ и других юрисдикциях практика своя, и единого консенсуса нет.

На деле, суды по миру признают, что владеть Copyright-ом могут только вполне себе конкретные субъекты права. Например, AI модель, то есть условный Claude, не является субъектом правовых отношений и владеть Copyright-ом не может. Это первое. Так что, частично, выдыхайте.

Тем не менее, мы же понимаем, что код, который Вам сгенерировал AI, на самом-то деле является результатом пережёвывания этим AI всех исходников, под всеми open source (и не open source) лицензиями. И кто в итоге владеет-то тогда copyright-ом на этот код? Тут вопрос сложный, но есть уже некоторый консенсус, в котором код, сгенерированный AI, признают “ineligible for copyright protection”, то есть он изначально не подпадает под охрану (это не совсем то же самое, что «перешёл в Public Domain», но на практике эффект похож: монопольных прав на такой код ни у кого нет). И сейчас превалирующее мнение такое:

Чисто AI-сгенерированный код не охраняется авторским правом, кроме случаев, когда человек существенно доработал код AI.

Сразу же предвижу вопрос — а что значит это Ваше “существенно”?!

Ответ: нужен судебный прецедент. Нужно, чтобы суды пару раз провели такие кейсы через себя, вынесли решения, и тогда будет какая-то модель.

Сейчас то, что именно означает “существенно” — это минное поле. Никто этого не знает.

Ещё один Off-Top

Кстати, именно потому, что нет чёткого понимания, насколько крупным должен быть modification со стороны человека, некоторые проекты, например Open JDK (Важно: не только по этой причине, но это официально одна из заявленных) просто отказываются принимать код, который создавался с использованием любых (!) средств генеративного AI:

Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems. Content, in this context, includes but is not limited to source code, text, and images in OpenJDK Git repositories, GitHub pull requests, e-mail messages, wiki pages, and JBS issues.

Contributors in the OpenJDK Community may use generative AI tools privately to help comprehend, debug, and review OpenJDK code and other content, and to do research related to OpenJDK Projects, so long as they do not contribute content generated by such tools.

Так что, Oracle, например, которая владеет торговой маркой Java, решила вопрос на корню для OpenJDK​ (кстати, для GraalVM вынесли другое решение)​.

Итоги

Ну, что подведу итоги.

Без CLA у мейнтейнеров нет ясного и полного набора прав на Ваш код: рядовой релиз обычно покрывает лицензия проекта, а вот re-licensing, dual-licensing и защита прав в суде без CLA под вопросом. Чтобы Вы могли явно разрешить делать те или иные вещи с Вашим git patch-ем, Вы подписываете (обычно онлайн) CLA. В большинстве своём (в т.ч. и в рамках Axelix), CLA не подразумевает передачу Вами copyright и права авторства.

В случае генеративного AI, всё усложняется. Пока можно точно сказать, что код, сгенерированный для Вас условным GitHub Copilot-ом, не принадлежит Microsoft или Copilot-у, но вполне вероятно, что чисто AI-сгенерированный код авторским правом просто не охраняется (в практике США), т.е. монопольных прав на него у Вас не будет, кроме тех случаев, если Вы существенно доработали код от AI.

Что значит “существенно”? Поживём увидим, пока не ясно.

Всем успехов!