Чтобы не нарушить лицензии open source и снизить юридические риски, закрепите простой процесс: точно определяйте лицензии каждой зависимости, проверяйте совместимость при объединении кода, выполняйте условия атрибуции/NOTICE, автоматизируйте сканирование в CI/CD и фиксируйте решения. При сомнениях проводите юридическую проверку open source лицензий и документируйте исключения.
Что важно помнить о лицензиях Open Source
- Лицензия действует как договорные условия: права есть только при соблюдении обязанностей (атрибуция, публикация текста лицензии, раскрытие исходников - если требуется).
- Пермишсивные лицензии обычно проще для продукта, copyleft - требует дисциплины при распространении производных работ.
- Совместимость лицензий важнее "популярности" библиотеки: конфликты чаще возникают при статической линковке и включении кода в поставку.
- Правило "взяли из GitHub" не заменяет лицензию: нужен конкретный файл LICENSE/заголовки/NOTICE и подтверждение для версии, которую вы используете.
- Коммерческое использование open source лицензий обычно возможно, но почти всегда с условиями, которые нужно выполнить в релизе и документации.
- Аудит лицензий open source - это не разовая акция, а непрерывный процесс в разработке и сборке.
Как устроены основные типы лицензий: permissive vs copyleft
Permissive (MIT, BSD, Apache-2.0) обычно подходят, если вы хотите свободно использовать/модифицировать/распространять код, включая коммерческие продукты, сохраняя уведомления об авторстве и текст лицензии. Copyleft (GPL, AGPL, LGPL) накладывает требования на распространение производных работ: от предоставления исходников до условий на сеть (AGPL).
Когда НЕ стоит выбирать/подключать copyleft без подготовки: если вы планируете закрытую поставку, статическую линковку с библиотекой под GPL/LGPL без понимания условий, или не готовы поддерживать выдачу исходников/offer на исходники и корректные уведомления в релизах.
| Лицензия | Класс | Разрешает | Основные обязанности/ограничения | Типичные риски в продукте |
|---|---|---|---|---|
| MIT | Permissive | Использование, модификация, распространение, в т.ч. коммерческое | Сохранить копирайт и текст лицензии в поставке | Пропущенная атрибуция/нет лицензии в дистрибутиве |
| BSD-2/3-Clause | Permissive | Аналогично MIT | Сохранить уведомления; у 3-Clause - не использовать имя автора для продвижения | Маркетинг/документация нарушают "non-endorsement" |
| Apache-2.0 | Permissive | Коммерческое использование, модификация, патентная лицензия | Сохранить LICENSE/NOTICE (если есть), указать изменения, соблюдать условия по товарным знакам | Потеря NOTICE, неверная атрибуция изменений |
| LGPL-2.1/3.0 | Weak copyleft | Использование библиотеки в проприетарном ПО при соблюдении условий | Условия зависят от способа линковки/распространения; обеспечивать возможность замены/перелинковки (часто), предоставлять тексты лицензий | Статическая линковка без выполнения требований, отсутствие offer/исходников для модификаций LGPL-компонента |
| GPL-2.0/3.0 | Strong copyleft | Свободное распространение производных работ | При распространении производного ПО - предоставлять исходники и сохранять лицензирование по GPL | "Заражение" поставки: включили GPL-код в продукт, который нельзя/не хотите открывать |
| AGPL-3.0 | Network copyleft | Использование и распространение | Требования GPL + предоставление исходников пользователям, взаимодействующим с ПО по сети (при соответствующих условиях) | SaaS/веб-сервисы: риск обязательства раскрытия исходников при неправильно оценённом сценарии |
Как правильно определить лицензию в вашем проекте
Чтобы корректно определить лицензирование, подготовьте минимальный набор доступов и артефактов. Это основа для внутреннего реестра и последующей юридической проверки open source лицензий.
- Доступ к репозиториям исходного кода и истории (Git), включая сабмодули и зеркала.
- Файлы сборки и lock-файлы: package-lock.json/yarn.lock/pnpm-lock.yaml, poetry.lock, requirements.txt, go.sum, Cargo.lock, pom.xml/gradle, Gemfile.lock и т.п.
- Артефакты поставки: контейнерные образы, инсталляторы, архивы релиза, "About/Legal" страницы.
- Список всех каналов распространения: App Store/Marketplace, on-prem дистрибутив, Docker registry, npm/pypi, OEM-поставки.
- Инструмент для сканирования лицензий (любой SBOM/лицензионный сканер) и место хранения результатов (репозиторий compliance/Confluence/вики).
Практика: фиксируйте лицензию не "в целом у проекта", а для конкретной версии зависимости (по хэшу/тегу), потому что лицензирование может меняться.
Совместимость лицензий при объединении и встраивании кода
-
Определите форму интеграции. Различайте "использую как отдельный сервис", "линкую библиотеку", "встраиваю исходники", "копирую куски кода". От этого зависит, что считается производной работой и какие условия включаются в вашу поставку.
- Отдельный процесс/сервис + API обычно безопаснее, чем включение кода в бинарник, но всё равно требует соблюдения атрибуции и условий распространения.
- Статическая линковка и копирование исходников требуют самой строгой проверки.
- Соберите лицензии всех компонентов и их исключения. У многих проектов есть дополнительные файлы NOTICE, licensing exceptions или двойное лицензирование (dual-license). Проверьте LICENSE, заголовки файлов, папку COPYING, README и страницу релизов.
-
Проверьте "наследование" условий в дистрибутиве. Если вы распространяете продукт (бинарник/контейнер/пакет), убедитесь, что условия каждой лицензии выполняются именно в этом канале поставки, а не только в репозитории.
- Для copyleft заранее решите, готовы ли вы раскрывать исходники/предлагать исходники и в каком формате.
- Для Apache-2.0 проверьте сохранение NOTICE, если он есть у компонента.
- Проверьте конфликты совместимости. Сопоставьте "что требует лицензия A" и "что запрещает лицензия B" при совместном распространении. При конфликте выбирайте другой компонент, меняйте архитектуру интеграции или оформляйте коммерческую лицензию у правообладателя.
- Задокументируйте решение и установите правила для PR. Зафиксируйте: компонент, версия, лицензия, способ интеграции, что нужно положить в дистрибутив (LICENSE/NOTICE/атрибуция), кто утвердил и когда. Это резко упрощает аудит лицензий open source.
Быстрый режим
- Сгенерируйте список зависимостей из lock-файлов и соберите их лицензии сканером/SBOM.
- Отметьте все copyleft/неясные лицензии и компоненты без LICENSE как "блокирующие".
- Для релиза сформируйте пакет Legal: Third-Party Notices + тексты лицензий + NOTICE.
- В CI включите правило: новые зависимости без лицензии/с запрещённым классом - ломают сборку.
- Если компонент критичен и рискованен - запросите консультацию юриста по open source лицензиям и зафиксируйте вывод письменно.
Оформление сторонних зависимостей: атрибуция, NOTICE и лицензии
Проверяйте результат не "по ощущениям", а по выходным артефактам релиза: архив, контейнер, страница About/Legal, репозиторий с исходниками (если требуется).
- В поставке есть файл(ы) с текстами всех применимых лицензий (Third-Party Licenses/OSS Licenses) и они соответствуют версиям зависимостей.
- Сохранены все copyright-уведомления и требуемые атрибуции (включая "внутри исходников", если вы их распространяете).
- NOTICE-файлы (если требуются) включены и не "обрезаны" при сборке/минимизации.
- Если вы модифицировали OSS-компонент, отражены требуемые пометки об изменениях (где это требуется лицензией/NOTICE).
- Для компонентов под copyleft выполнены условия распространения: доступ к исходникам/offer на исходники, корректная лицензия на производную работу (если применимо).
- Для контейнеров и embedded-устройств предусмотрено, как пользователь получит тексты лицензий и исходники (например, через отдельный URL в документации).
- В UI/документации нет утверждений, нарушающих условия "non-endorsement" и требований по товарным знакам.
- Есть внутренний реестр: компонент → версия → лицензия → ссылка на исходник → как соблюдаем (артефакт/путь в релизе).
Автоматизация проверки и аудита лицензий: инструменты и workflow
Автоматизация нужна, чтобы юридическая проверка не превращалась в ручной "разбор полётов" перед релизом. Ниже - типовые ошибки, из-за которых аудит лицензий open source даёт ложную уверенность.
- Сканируют только прямые зависимости и игнорируют транзитивные (в lock-файлах их обычно больше всего).
- Доверяют "лицензии из registry" и не сверяют с LICENSE/NOTICE в исходниках конкретной версии.
- Не учитывают способ поставки: "в репозитории всё есть", а в контейнере/инсталляторе нет ни LICENSE, ни NOTICE.
- Нет политики для "UNKNOWN/NOASSERTION": такие компоненты должны блокировать релиз или требовать ручного подтверждения.
- Не фиксируют исключения и решения: через месяц невозможно понять, почему компонент допустили.
- Смешивают лицензирование кода и лицензии на медиа/шрифты/модели: у ассетов часто отдельные условия.
- Не проверяют куски копипаста: фрагменты кода из ответов/сниппетов могут иметь несовместимые условия.
- Нет gate в CI/CD: отчёт генерируется, но не влияет на merge/release.
Практичный workflow для CI/CD:
- На каждый PR: скан зависимостей + дифф по новым лицензиям; политика allow/deny по классам.
- На релиз: генерация SBOM и пакета Third-Party Notices как артефактов сборки.
- Раз в спринт/месяц: пересмотр исключений и ручная выборочная верификация критичных компонентов.
Порядок действий при выявлении нарушения лицензии или получении претензии
Выбирайте вариант в зависимости от того, где обнаружена проблема (в репозитории, в релизе, у клиента) и насколько компонент критичен.
- Быстрое устранение несоответствия. Добавьте недостающие тексты лицензий/атрибуцию/NOTICE в поставку и выпустите патч-релиз; подходит, когда нарушение связано с оформлением, а не с несовместимостью.
- Замена или перепроектирование интеграции. Уберите компонент, замените аналогом или вынесите в отдельный сервис/процесс; уместно при конфликте совместимости (например, нежелательные условия copyleft).
- Открытие исходников/выполнение copyleft-обязательств. Подходит, если вы готовы привести продукт в соответствие требованиям лицензии и это не разрушает бизнес-модель.
- Переговоры о коммерческой лицензии/исключении. Запросите у правообладателя альтернативное лицензирование или исключение; часто это быстрее и безопаснее, чем спор. На этом этапе обычно нужна консультация юриста по open source лицензиям.
Ответы на типичные юридические ситуации по лицензиям
Можно ли использовать open source в коммерческом продукте?
Обычно да: коммерческое использование open source лицензий допускается, если вы выполняете условия конкретной лицензии (атрибуция, включение текста лицензии, NOTICE, иногда раскрытие исходников при распространении).
Если мы не распространяем продукт, а используем библиотеку только внутри компании, что меняется?
Чаще всего снижается объём обязанностей по распространению, но остаются требования лицензии при копировании/модификации и при публикации наружу. Для SaaS-сценариев отдельно оценивайте AGPL и сетевые условия.
Достаточно ли просто указать ссылку на репозиторий вместо текста лицензии?
Обычно нет: многие лицензии требуют включать сам текст лицензии и уведомления в дистрибутиве. Ссылка может быть дополнением, но не заменой.
Что делать с зависимостями, у которых лицензия указана как UNKNOWN/NOASSERTION?
Считайте это блокером: найдите LICENSE в исходниках конкретной версии, проверьте заголовки файлов или замените компонент. Это базовое правило для юридической проверки open source лицензий.
Нужно ли публиковать исходники нашего приложения, если внутри есть компонент под GPL?
Если вы распространяете производную работу и она подпадает под условия GPL, обычно требуется предоставление исходников и лицензирование производного по GPL. Конкретика зависит от того, как именно включён компонент.
Мы нашли нарушение в уже отгруженной версии. Как минимизировать риски?
Соберите факты, устраните нарушение в ближайшем патче и подготовьте корректный пакет Legal для клиентов. Параллельно зафиксируйте внутренне причину и добавьте gate в CI, чтобы не повторилось.
Когда нужен аудит и когда достаточно автоматического сканера?
Автосканер нужен всегда, но аудит лицензий open source обязателен перед крупными релизами, сменой модели распространения и при появлении copyleft/неясных лицензий. Для спорных случаев полезна консультация юриста по open source лицензиям.
