Открытые лицензии MIT, Apache и GPL в заказном проекте: что они значат для заказчика и что проверить при сдаче

Короткий ответ: в любом заказном сайте, сервисе или приложении есть чужой открытый код — фреймворки, библиотеки, шрифты. Лицензии MIT, BSD и Apache почти ничего не требуют: сохранить уведомление об авторстве. GPL и AGPL требуют открыть ваш код, если вы передаёте программу другим или (для AGPL) даёте ею пользоваться по сети. Проверяется это списком зависимостей при сдаче.

Почему в любом проекте есть чужой открытый код?

Потому что писать с нуля то, что давно написано и проверено тысячами проектов, — дорого и рискованно. Веб-фреймворк, работа с датами, загрузка файлов, шифрование, интерфейсные компоненты — всё это берут из открытых библиотек, а под заказ пишут бизнес-логику, экраны и интеграции.

Даже небольшое веб-приложение тянет за собой десятки, а то и сотни пакетов: вы подключаете десяток напрямую, а каждый из них — свои зависимости. Это нормальная практика, а не экономия на качестве. Вопрос не в том, есть ли в проекте открытый код, а в том, на каких условиях каждый кусок можно использовать.

С точки зрения российского права это открытая лицензия по ст. 1286.1 ГК РФ: договор присоединения, условия которого доступны каждому. По умолчанию она безвозмездна, действует по всему миру, а для программ без указанного срока — на весь срок действия исключительного права. Важная деталь из п. 4 той же статьи: если вы предоставляете другим права на такой код сверх условий открытой лицензии, правообладатель вправе отказаться от договора с вами.

Отсюда главное для заказчика: права на библиотеки не принадлежат ни студии, ни вам. Обе стороны пользуются ими на условиях авторов. В типовом договоре Roboweb.team это записано прямо: компоненты третьих лиц, в том числе распространяемые на условиях открытых лицензий, в предмет лицензии исполнителя не входят, права на них остаются у правообладателей (п. 5.3). Права на сам заказной код — отдельная тема, о ней в статье «Кому принадлежит код сайта после разработки».

Чем MIT, BSD, Apache отличаются от GPL и AGPL?

Первые три — разрешительные: берите, меняйте, встраивайте в закрытый продукт, только сохраните уведомление об авторстве. GPL и AGPL — с копилефтом: если вы передаёте программу с таким кодом другим, то передаёте и её исходники на тех же условиях. Разница не в цене — все бесплатны, — а в том, что вы обязаны отдать.

Разберём по группам, без юридического словаря.

• MIT, BSD, ISC. Текст MIT занимает один абзац: делайте что угодно, но уведомление об авторстве и текст разрешения должны остаться во всех копиях или существенных частях программы. Плюс отказ от гарантий: программа поставляется «как есть». Под такими лицензиями выходят многие библиотеки JavaScript, Python и PHP.
• Apache 2.0. По сути тоже разрешительная, но подробнее. Раздел 4 требует приложить копию лицензии, пометить изменённые файлы и сохранить файл NOTICE, если он есть. Раздел 3 даёт патентную лицензию от авторов — и прекращает её для того, кто сам подаст патентный иск по этой программе. Для бизнеса это плюс: меньше риска, что автор библиотеки потом придёт с патентом.
• MPL 2.0. Компромисс: копилефт действует на уровне файла. Если вы поменяли файлы самой библиотеки, эти файлы должны оставаться открытыми; ваш собственный код рядом — нет.
• LGPL. «Мягкий» вариант GPL для библиотек. Закрытая программа может её использовать, если пользователь в состоянии заменить библиотеку своей версией: раздел 4 LGPLv3 требует уведомить, что библиотека используется, приложить тексты лицензий и дать возможность пересобрать программу с изменённой библиотекой.
• GPL. GPLv3 прямо разрешает запускать, менять и использовать программу без каких-либо условий, пока вы её никому не передаёте. Передаёте — тогда всё произведение целиком, со всеми частями, должно распространяться под GPL (разд. 5), а вместе с готовой сборкой — исходный код (разд. 6).
• AGPL. GPL плюс одно правило: раздел 13 AGPLv3 обязывает того, кто изменил программу, предложить её исходный код всем, кто работает с ней удалённо по сети.

Сводка — в таблице. Это ориентир для разговора с разработчиком, а не юридическое заключение: детали зависят от версии лицензии и того, как именно компонент подключён.

Лицензия	Можно ли держать свой код закрытым	Что обязано остаться	SaaS и мобильное приложение
MIT, BSD, ISC	Да	Уведомление об авторстве и текст лицензии в копиях библиотеки	Ограничений по сути нет; в приложении нужен экран или файл с лицензиями
Apache 2.0	Да	Текст лицензии, файл NOTICE, пометки в изменённых файлах	Ограничений нет; плюс патентная лицензия от авторов
MPL 2.0	Да, кроме изменённых файлов самой библиотеки	Исходники изменённых файлов библиотеки открыты на её условиях	Подходит, если не править чужие файлы без нужды
LGPL	Да, если библиотека подключена отдельно и её можно заменить	Уведомление, тексты лицензий, возможность пересобрать с другой версией библиотеки	Сервер — без проблем; в мобильном приложении выполнить условия сложно
GPL	Нет, если программа передаётся другим	При распространении — исходный код всего произведения под GPL	Сервер без передачи копий — можно; приложение в магазине — весь код под GPL
AGPL	Нет, если люди работают с изменённой версией по сети	Исходный код изменённой версии — всем её сетевым пользователям	Главный риск для SaaS

Что GPL меняет для сайта, программы и приложения?

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

Три типичных сценария.

• Сайт или веб-сервис. Серверная часть живёт у вас, посетители получают только результат её работы — страницы и данные. Здесь GPL-библиотека на сервере обычно ничего не требует. Но есть нюанс с кодом, который выполняется в браузере: скрипты сайта скачиваются на компьютер каждого посетителя, то есть копия передаётся. Поэтому GPL-библиотеку во фронтенде стоит заменить или проверить отдельно.
• Программа, которую вы отдаёте клиентам. Коробочная версия, программа для установки на сервер клиента, приложение для компьютера. Если внутри GPL-код, клиент вправе потребовать исходники всей программы — и дальше распоряжаться ими по GPL, в том числе выложить их в открытый доступ.
• Мобильное приложение. Сборка попадает на телефон каждого пользователя — это распространение в чистом виде. GPL-библиотека внутри означает, что весь код приложения придётся раскрыть на условиях GPL. LGPL в мобильном приложении тоже неудобна: условие «пользователь может заменить библиотеку» в сборке для магазина выполнить трудно. Поэтому в мобильной разработке такие зависимости обычно стараются не брать.

Отдельно о внутреннем использовании. Если программа нужна только вашей компании, GPL разрешает менять её и запускать без раскрытия кода. И даже передача копий подрядчику, который дорабатывает программу исключительно для вас и под вашим контролем, раздел 2 GPLv3 разрешает без условий о раскрытии кода.

Какие лицензии опасны для SaaS?

Для облачного сервиса главный риск — AGPL: если вы изменили AGPL-программу и пользователи работают с ней через интернет, исходный код изменённой версии нужно им предложить. Второй риск — лицензии с ограничениями для облака вроде SSPL и BUSL: они не входят в список одобренных OSI и ограничивают предоставление программы как облачной услуги.

Как это выглядит в жизни. Сервис собран на базе AGPL-системы, разработчик доработал её ядро под вашу задачу. Формально каждый клиент сервиса вправе получить исходники этой доработанной части — а вместе с ней и вашу бизнес-логику, если она встроена в то же произведение. Для продукта, который вы продаёте по подписке, это означает раскрыть его конкурентам.

Что делают на практике:

• не берут AGPL-компоненты в основу продукта, который будет продаваться по подписке, — или берут осознанно, понимая, что раскроется;
• если нужен AGPL-сервис (например, отдельная система рядом), запускают его без изменений, отдельно от своего кода, и общаются с ним через API;
• проверяют базы данных, очереди и поисковые движки: часть из них сменила лицензию на ограниченную для облачных провайдеров, и условия новой версии отличаются от старой;
• для каждой такой зависимости записывают, какая версия и на каких условиях используется, — лицензия может поменяться в следующем выпуске.

Актуальный список одобренных лицензий ведёт Open Source Initiative: если лицензии компонента там нет, это сигнал прочитать её текст целиком, прежде чем строить на ней продукт.

Как получить список лицензий у разработчика?

Попросите выгрузку всех зависимостей проекта с версиями и лицензиями — прямых и вложенных. Для этого не нужен юрист: в каждой экосистеме есть стандартные утилиты, а полный перечень оформляют как SBOM в формате SPDX или CycloneDX. Разработчик должен суметь объяснить каждую спорную строку.

Где это лежит в проекте:

• JavaScript и TypeScript — файлы package.json и package-lock.json (или аналог для другого менеджера пакетов); утилиты собирают из них лицензии каждого пакета;
• PHP — composer.json и composer.lock, команда composer licenses выводит лицензии всех установленных пакетов;
• Python — файл зависимостей проекта, лицензии выгружаются отдельной утилитой;
• мобильные приложения — зависимости сборки iOS и Android; там же обычно готовят экран «Лицензии открытого ПО» в настройках приложения;
• шрифты, иконки, изображения — отдельно: у них свои лицензии, и в менеджере пакетов их часто нет.

Что делать с выгрузкой. Вам не нужно читать все строки — достаточно отфильтровать то, что не входит в разрешительные лицензии: GPL, AGPL, LGPL, MPL, SSPL, BUSL, «UNKNOWN» и «UNLICENSED». По каждой такой строке спросите разработчика: где используется, передаётся ли эта часть пользователям, чем её можно заменить. Строка «лицензия не указана» — отдельный повод для вопроса: без лицензии код по умолчанию использовать нельзя.

Список удобно держать в самом репозитории — рядом с кодом, который у вас должен быть в собственном аккаунте. Зачем заказчику свой репозиторий и что там проверить, разобрали в статье «Репозиторий кода простыми словами».

Что проверить при сдаче проекта

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

1. В репозитории есть файл со списком сторонних компонентов: название, версия, лицензия.
2. Для веб-сервиса нет AGPL-компонентов, изменённых под проект, — или их использование согласовано с вами письменно.
3. Для мобильного приложения и программы «в коробке» нет GPL и неудобной LGPL; в приложении есть экран или раздел с лицензиями открытого ПО.
4. Платные компоненты (темы, плагины, шрифты, библиотеки с коммерческой лицензией) куплены на вас или на ваш аккаунт, а не на студию, и ключи переданы.
5. В коде нет фрагментов без указания источника, скопированных из чужих закрытых проектов.
6. Если вы собираетесь регистрировать программу или включать её в реестр, открытые компоненты описаны отдельно от собственного кода: об этом — в статьях о регистрации программы в Роспатенте и о реестре российского ПО.

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

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

Как это устроено в договорах студии. Права на программный код остаются у исполнителя, а заказчик с даты полной оплаты получает простую лицензию на весь срок действия исключительного права (п. 5.2): исходники в его репозитории, размещение на любом сервере, доработка любыми подрядчиками. Логотип, тексты и фирменный стиль, созданные для заказчика, переходят к нему (п. 5.6). Компоненты третьих лиц, включая открытые, в эту схему не входят — их условия задают авторы (п. 5.3). Исполнитель гарантирует, что ему не известно о правах третьих лиц, мешающих использовать результат (п. 5.8), — тоже за исключением этих компонентов. Типовые договоры открыты на странице «Документы».

Что можно добавить в техническое задание или приложение к договору, если продукт чувствителен к лицензиям:

• «Перечень сторонних компонентов с указанием лицензий передаётся вместе с результатом работ»;
• «Компоненты под лицензиями GPL, AGPL, SSPL и аналогичными в составе продукта, который будет распространяться или предоставляться пользователям по сети, используются только с письменного согласия заказчика»;
• «Платные компоненты оформляются на заказчика».

Чего не стоит требовать: «весь код только собственной разработки, без открытых библиотек». Это невыполнимо и сделает проект дороже и слабее — проверенные библиотеки обычно надёжнее самописных.

Когда об этом можно не думать?

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

Можно спокойно выдохнуть, если:

• у вас лендинг, корпоративный сайт или магазин на популярной системе управления — даже если сама система под GPL, посетители получают страницы, а не её код;
• это внутренняя система для сотрудников: CRM, кабинет, учёт — GPL разрешает изменять и использовать её внутри компании;
• Telegram-бот работает на вашем сервере, а пользователи только переписываются с ним.

Стоит разобраться заранее, если вы делаете:

• SaaS по подписке — веб-приложение от 160 000 ₽ по прайсу: здесь AGPL и облачные ограничения бьют прямо по модели заработка;
• мобильное приложение — от 200 000 ₽: сборка у каждого пользователя, GPL недопустима, нужен экран лицензий;
• программу для установки у клиентов или продукт, который планируете продать вместе с бизнесом: при проверке сделки покупатель обычно просит перечень лицензий.

Ошибки, которые встречаются чаще всего:

• считать, что «бесплатно и в открытом доступе» значит «без условий», — условия есть всегда, просто у MIT они короткие;
• проверять только прямые зависимости: GPL-пакет может прийти вложенным, через безобидную библиотеку;
• не следить за обновлениями: компонент мог сменить лицензию в новой версии. Обновления входят в поддержку — от 7 900 ₽/мес, и при каждом крупном обновлении перечень лицензий стоит выгружать заново;
• убирать уведомления об авторстве и тексты лицензий из сборки «для чистоты» — это прямое нарушение даже самой мягкой лицензии.

Короткие ответы на частые вопросы

Можно ли использовать библиотеку под MIT в коммерческом проекте?

Да. MIT разрешает использовать, менять и продавать программу с библиотекой, в том числе в закрытом продукте. Условие одно: сохранить в копиях библиотеки уведомление об авторстве и текст лицензии.

Что такое лицензия GPL коротко?

Это открытая лицензия с условием «копилефт»: программу можно запускать и менять как угодно, но если вы передаёте её другим, то обязаны передать и исходный код всего произведения на тех же условиях.

Нужно ли открывать код сайта, если в нём есть GPL-компонент на сервере?

Обычно нет. Работа пользователей с сайтом по сети не считается распространением по GPL, а серверный код посетителям не передаётся. Исключение — AGPL: там исходники изменённой версии придётся предложить пользователям.

Как узнать, какие лицензии в моём проекте?

Попросите разработчика выгрузить список зависимостей с лицензиями: для JavaScript, PHP и Python для этого есть стандартные утилиты, а полный перечень можно оформить как SBOM в формате SPDX или CycloneDX.

Кому принадлежат права на открытые библиотеки в заказном проекте?

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

Услуги и кейсы по теме: типовые договоры · поддержка сайта от 7 900 ₽/мес · цены и сроки