Open source в договоре с клиентом: какие обещания нужно проверить

Вы можете давать клиенту гарантии, даже если в продукте есть open source. Такой код разрешено использовать, менять и распространять на условиях открытой лицензии. Но сначала нужно проверить, позволяют ли ваши права и условия этих лицензий выполнить обещанное. Право использовать чужую библиотеку или другой фрагмент кода не означает, что права на него принадлежат вам.

Представим, что клиент прислал договор с тремя условиями: вам принадлежат права на всю программу, вы не используете в ней open source и вам не придётся раскрывать исходный код. Исходным кодом называют текст программы, с которым работают разработчики. Каждое обещание нужно проверить отдельно. Даже если вы соблюдаете все лицензии, обещание об отсутствии open source может быть неверным.

При проверке я выясняю, из чего состоит продукт, какие права у вас есть и что подтверждает каждое обещание. У других лицензий могут быть дополнительные требования.

Начните с того, что получает клиент

Попросите технического руководителя описать версию продукта, о которой идёт речь в договоре.

{ }

На ваших серверах

Какие части программы остаются у вас?

</>

У клиента

Что он скачивает, устанавливает, встраивает в свой продукт или получает в виде исходного кода?

Учитывайте не только код вашей команды, но и чужие библиотеки, внесённые в них изменения и другой код, без которого они не работают.

Даже если сервис работает на ваших серверах, клиент может получать часть его кода: для браузера, для установки на компьютер или в составе набора инструментов для разработчиков. Чужие библиотеки могут входить и в установочный файл. Поэтому важно понять, что клиент действительно получает. Например, лицензия AGPLv3 различает использование программы через сеть без получения её копии и передачу копии программы. AGPLv3, раздел 0.

Затем уточните, что клиент собирается делать: пользоваться продуктом, менять его, поручать поддержку другой команде или передавать другим людям и компаниям. Проверьте, позволяют ли лицензии эти действия, и учтите ограничения, о которых вы уже договорились с клиентом.

Если программа входит в состав устройства, статья о GPLv3 в устройствах, обновлениях и гарантиях поможет разобраться, как предоставление исходного кода и установка изменений связаны с вашими обязанностями по поддержке.

Проверьте три обещания по отдельности

Прежде чем проверять обещания, прочитайте определения в договоре. Что договор называет программой (Software), что входит в передаваемые результаты (Deliverables) и что относится к коду, данным и другим материалам клиента (Customer Materials)? Уточнение в одном пункте может не действовать в другом. Например, если вы исключили чужие библиотеки из пункта о передаче прав, обещание «в программе нет open source» нужно исправить отдельно.

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

Тексты лицензий, гарантии и исходный код

MIT

Лицензия MIT разрешает широко использовать, изменять и распространять программу, в том числе продавать копии. В копии программы или её существенные части нужно включать строку об авторских правах и текст разрешения из лицензии. Сама лицензия не требует публиковать исходный код. Если вы забыли приложить обязательный текст, это может быть нарушением. Но само по себе это не обязывает вас публиковать исходный код всего продукта. Лицензия MIT.

Apache License 2.0

Раздел 4 требует передавать получателям копию лицензии и ясно отмечать файлы, которые вы изменили. Если вы распространяете исходный код программы, созданной на основе чужого кода, в нём нужно сохранить относящиеся к нему уведомления о правах и авторстве. Если у исходной программы есть файл NOTICE со сведениями об авторстве, относящуюся к вашей программе часть этих сведений тоже нужно передать одним из способов, которые допускает лицензия. Общей обязанности публиковать исходный код нет. Apache License 2.0, раздел 4.

По разделу 7 авторы исходного кода не дают гарантий, в том числе о наличии у них прав и отсутствии нарушений чужих прав, если закон или письменное соглашение не требуют иного. Раздел 9 позволяет вам дать клиенту собственные гарантии или обещать компенсировать потери, если вы распространяете программу. За такие обещания вы отвечаете сами. Вы также должны согласиться защитить каждого участника разработки, которого лицензия относит к Contributor, от требований, возникших из-за ваших дополнительных обещаний, возместить ему потери и освободить от соответствующей ответственности. Ваши обещания должны соответствовать лицензии. То, что авторы кода не дают гарантий, не отменяет ваших собственных обязательств перед клиентом. Apache License 2.0, разделы 7 и 9.

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

Что меняется с AGPL

В открытой лицензии AGPLv3 есть специальное правило для использования программы через сеть. Если вы изменили программу под этой лицензией и пользователи работают с изменённой версией через сеть, раздел 13 требует явно предложить им бесплатно получить её Corresponding Source: исходный код и всё необходимое для сборки, установки, запуска и изменения программы, кроме предусмотренных лицензией исключений. Эта обязанность может возникнуть, даже если пользователь не получает копию программы. AGPLv3, раздел 13.

Даже если вы не меняли файлы самой библиотеки под AGPL, вопрос ещё не решён. Раздел 0 понимает изменение программы шире: это копирование или переработка всей программы либо её части, для которых нужно разрешение владельца авторских прав, кроме создания точной копии. Если соединение библиотеки с вашим кодом создаёт изменённую версию программы под AGPL, раздел 13 может требовать предложить её исходный код пользователям, которые работают с ней через сеть. Прежде чем обещать, что раскрывать код не придётся, нужно разобраться, как библиотека связана с вашим кодом, и проверить применимое право. AGPLv3, разделы 0 и 13.

Комплект Corresponding Source может включать больше, чем только ваши изменения. Но это не означает, что нужно автоматически раскрыть всё хранилище кода компании. Если вы передаёте программу не в виде исходного текста, а, например, как готовые файлы для установки, лицензия называет это объектным кодом. Раздел 6 отдельно определяет, как в таком случае предоставить исходный код. AGPLv3, разделы 1 и 6.

Прежде чем согласовывать такое обещание, я попрошу технического руководителя показать программу под AGPL, ваши изменения и связанный с ней код, а также объяснить, как всем этим пользуются клиенты. Недостаточно назвать программу «библиотекой» или сказать, что она работает отдельно. Нужно понять, как всё устроено, чтобы определить, какой код и кому придётся предоставить.

Соберите сведения о коде и лицензиях

Начните со списка библиотек и других частей кода в программе. Такой перечень называют software bill of materials, или SBOM. Для проверки лицензий и договора нужны также следующие сведения:

Автоматическая проверка кода помогает найти проблемы, но не отвечает на вопрос, что именно вы обещаете клиенту. Название лицензии в таблице ещё не подтверждает, что клиент получил обязательные тексты и действительно может получить исходный код предусмотренным лицензией способом. Собирайте сведения для конкретной версии продукта и определите, кто отвечает за каждый нерешённый вопрос.

Если команда использует AI при разработке, проверяйте не только подключённые библиотеки. Учитывайте и известные случаи, когда AI повторил чужой код, и чужие фрагменты, найденные при проверке результата. В статье об AI-коде и чужих лицензиях объясняю, почему обещания AI-сервиса о правах на результат не решают этот вопрос.

Пример проверки договора

Представим, что вы передаёте клиенту приложение: часть кода написала ваша команда, а вспомогательную программу вы взяли у другого автора по лицензии MIT. В договоре сказано, что вам принадлежат права на всё, что вы передаёте клиенту, и что open source там нет.

Сначала я проверю версию этой вспомогательной программы, откуда вы её взяли, условия лицензии и то, как её получает клиент. Даже если вы соблюдаете MIT и приложили обязательные тексты, права на эту вспомогательную программу не переходят к вам. А open source остаётся в вашем приложении.

Возможный подход к согласованию:

1. Определить код, написанный специально для клиента, права на который вы передадите, и подтвердить, что они принадлежат вам.
2. Указать вспомогательную программу в приложении к договору и назвать её лицензию.
3. Добавить исключение для неё в оба обещания: о правах на весь код и об отсутствии open source.
4. Проверить, что клиент сможет пользоваться приложением и поддерживать его так, как вы договорились. Передать ему всё, что для этого нужно.

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

Договоритесь, как решать проблемы

Решение зависит от проблемы. Иногда достаточно выполнить пропущенное требование лицензии. В других случаях нужно изменить обещание клиенту, заменить чужой код или получить для него другую лицензию у того, кто вправе её выдать. Одно решение не заменяет другое: например, согласие клиента не отменяет условий, на которых автор разрешил использовать свой код.

Замена чужого кода в следующей версии не устраняет автоматически прошлые нарушения. Нужно отдельно проверить, что происходило с прежними версиями и какие обязанности остались невыполненными. Например, AGPLv3 определяет, когда из-за нарушения вы теряете права, которые даёт лицензия, и при каких условиях эти права восстанавливаются. AGPLv3, раздел 8.

В договоре нужно определить, кто проверяет проблему, какие решения доступны, кто отвечает на претензию, договаривается с её автором и оплачивает расходы. Согласуйте также, как можно менять состав кода в период поддержки и когда для этого нужно согласие клиента. Иначе обещание, которое верно для текущей версии, может оказаться невыполнимым для следующей.

Что проверить перед подписанием

1. Укажите версию продукта, что и как получает клиент и что он собирается с этим делать.
2. Выясните, какой код есть в продукте, какие лицензии действуют, что вы изменили и какие сведения ещё нужно собрать.
3. Отдельно проверьте каждое обещание: кому принадлежат права, выполнены ли лицензии, нужно ли раскрывать исходный код и не нарушены ли чужие права.
4. Внесите исключения, о которых договорились с клиентом, во все нужные пункты договора. Подготовьте код, тексты лицензий и другие обязательные документы для клиента.
5. Определите, кто решает оставшиеся вопросы, проверяет будущие изменения и разбирается с возможными прошлыми нарушениями.

В результате будет ясно, какие обещания соответствуют продукту, что это подтверждает и что ещё нужно сделать, чтобы выполнить остальные.

Нужно проверить условия об open source в договоре?

Помогаю проверить права на код и договор с клиентом: что позволяют используемые вами лицензии и какие обещания вы можете дать. Проверка прав на код · Мой опыт · Контакты.

Рассмотрены отдельные условия лицензий, проверенные 6 октября 2026 года. Выводы зависят от полных текстов лицензий, продукта, договоров и применимого права.