Лицензии open source зависимостей: что проверять и когда это критично

Прямой ответ

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

Три категории лицензий:

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

Слабый копилефт позволяет использовать библиотеку без открытия кода продукта, но изменения в самой библиотеке должны быть опубликованы. Использование без изменений обычно не создаёт обязательств.

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

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

Проверка осложняется тремя обстоятельствами:

1. Транзитивные зависимости. Прямых зависимостей в проекте десятки, а с учётом транзитивных — сотни. Лицензия каждой из них applies к продукту.

2. Разные версии — разные лицензии. Библиотека может сменить лицензию между версиями. Обновление зависимости меняет лицензионные условия без изменения кода.

3. Двойное лицензирование. Часть библиотек доступна под открытой лицензией для открытых проектов и под коммерческой — для проприетарных. Проверка требует понимания, какая лицензия применяется в вашем случае.

Практика: проверка лицензий зависимостей

1. Соберите перечень лицензий. Инструменты формирования SBOM выводят лицензию для каждого компонента, включая транзитивные; о составе продукта — в статье про supply chain.

2. Задайте список разрешённых лицензий. MIT, BSD, Apache 2.0 и аналогичные разрешительные лицензии обычно допустимы. Список фиксируется в конфигурации проверки.

3. Отмечайте лицензии, требующие разбора. GPL и AGPL помечаются как требующие оценки, а не запрещаются автоматически: в некоторых случаях использование допустимо.

4. Проверяйте лицензии в конвейере сборки. Проверка выполняется автоматически, поскольку добавление зависимости происходит без явного решения о лицензии; о проверках — в статье про конвейер CI.

5. Сохраняйте тексты лицензий в поставке. Требование разрешительных лицензий — указать авторство и текст, что выполняется включением файла с перечнем.

6. Проверяйте лицензии при обновлении зависимостей. Смена лицензии между версиями — реальное явление, и обновление меняет условия использования; о процессе — в статье про обновление зависимостей.

7. Отдельно оценивайте компоненты под AGPL в веб-сервисе. Сетевое использование активирует условие о предоставлении исходного кода.

8. Фиксируйте решения. Если компонент под копилефт-лицензией разрешён к использованию, основание решения документируется; о проверках состава — в статье про аудит зависимостей.

Рекомендации:

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

Практический сценарий: зависимость под AGPL в веб-сервисе

Контекст: при проверке перечня лицензий перед релизом обнаружился компонент под AGPL, добавленный транзитивно через библиотеку для работы с очередями.

1. Диагностика. Прямых зависимостей с копилефт-лицензией в проекте не было. Компонент попал в дерево через промежуточную библиотеку, и его лицензия не проверялась при добавлении.
2. Причина. Проверка лицензий выполнялась вручную и только для прямых зависимостей. Транзитивное дерево не анализировалось, а конвейер проверку лицензий не выполнял.
3. Действия. (а) Сформировали полный перечень лицензий с учётом транзитивных зависимостей; (б) нашли альтернативную библиотеку под Apache 2.0 с тем же набором возможностей и заменили зависимость; (в) добавили проверку лицензий в конвейер со списком разрешённых и списком требующих разбора; (г) проверили остальные сервисы и нашли ещё один случай транзитивного AGPL; (д) зафиксировали правило: новая зависимость проходит проверку лицензии до слияния.
4. Результат. Проверка стала автоматической и покрывает транзитивные зависимости, а обнаружение происходит до релиза, а не после.

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

FAQ

Какие лицензии безопасны для проприетарного продукта? Разрешительные: MIT, BSD, Apache 2.0. Требуется сохранить текст лицензии и уведомление об авторстве в поставке.

Чем AGPL отличается от GPL? Условием о сетевом использовании: взаимодействие пользователей с программой по сети даёт им право получить исходный код, даже если программа не распространяется.

Нужно ли проверять транзитивные зависимости? Да. Они входят в состав продукта и несут те же лицензионные условия, что и прямые зависимости.

Что делать, если зависимость сменила лицензию? Оценить новую лицензию до обновления версии. Обновление без проверки меняет условия использования продукта.

Источники: GNU AGPL v3, MIT License, Apache License 2.0 — ссылки в шапке.