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

MAATRIX

> Дисклаймер. Это обзорный материал про общую методику проверки, а не юридическая консультация. Лицензии открытого кода — реальные договоры с реальными последствиями при нарушении, и трактовка конкретных формулировок зависит от юрисдикции, характера продукта (SaaS, on-premise, встроенное ПО) и способа использования компонента. Перед решением по конкретному продукту и конкретному набору зависимостей проконсультируйтесь с юристом, специализирующимся на праве интеллектуальной собственности. Открытый код давно перестал быть чем-то экзотическим — в среднем коммерческом продукте open source составляет от половины до девяноста с лишним процентов кодовой базы, если считать все зависимости и их зависимости. Проблема в том, что «бесплатно скачать» и «можно использовать в продукте, который вы продаёте» — разные вопросы, и путаница между ними обходится дорого: от требования выложить исходный код собственного продукта до иска от правообладателя. Дальше — рабочая методика, которая позволяет системно проверить любой open-source компонент перед тем, как он попадёт в прод, без углубления в конкретику одной отдельной лицензии.

Почему «это же популярный проект» — не аргумент

Логика «этим пользуются тысячи компаний, наверное, можно» звучит убедительно, но игнорирует важное. Лицензия — свойство конкретной версии конкретного репозитория, а не проекта «вообще»: разработчики меняют лицензию между релизами, иногда переходя с permissive-лицензии на source-available с коммерческими ограничениями именно в ответ на то, что облачные провайдеры зарабатывали на проекте, не отдавая ничего обратно. Если вы зафиксировали в зависимостях старую версию, а лицензия на сайте проекта уже относится к новой — вы рискуете читать не тот текст.

Кроме того, «популярность» ничего не говорит о том, что именно требует лицензия — среди очень известных проектов немало таких, что накладывают серьёзные требования на встраивание в коммерческий продукт, и это никак не связано с числом звёзд на GitHub. А поле license в метаданных пакета (npm, pip, composer, cargo) иногда расходится с тем, что написано в файле лицензии самого репозитория — устаревшие или неверно заполненные метаданные встречаются регулярно. Проверять нужно первоисточник, а не поисковую выдачу.

Дальше — пошаговый чек-лист, который стоит проходить для каждого нетривиального open-source компонента, а не только один раз в начале проекта.

Шаг 1. Найдите реальный файл лицензии в самом репозитории

Не полагайтесь на бейдж лицензии в README или на страницу проекта — идите в сам репозиторий и ищите файл лицензии напрямую. Что искать:

• LICENSE, LICENSE.md, LICENSE.txt — самый частый вариант;
• COPYING, COPYING.LESSER — характерно для проектов экосистемы GNU;
• лицензионный заголовок в шапке отдельных исходных файлов — иногда отличается от корневого LICENSE (dual-licensing, смешанный код из разных источников);
• поле license в package.json, pyproject.toml, composer.json, Cargo.toml — удобно для быстрой сортировки, но не заменяет чтение самого файла;
• директорию licenses/ или THIRD-PARTY-NOTICES — там может быть перечень вложенных лицензий, если проект сам тянет чужой код.

Смотрите на файл лицензии именно той версии (тега, коммита), которую вы реально используете, а не на файл в ветке main на сегодняшний день. Если проект перешёл на BSL (Business Source License) или другую source-available лицензию в версии 8.0, а вы используете версию 6.2 под MIT — для вас актуальна лицензия 6.2, но при обновлении до 8.0 условия могут измениться радикально. Перечитывайте файл лицензии заново при каждом мажорном апгрейде зависимости, а не полагайтесь на «раньше было MIT, значит и сейчас MIT».

Если файла лицензии нет вообще — это не значит «можно всё»: по умолчанию действует полное авторское право, и публикация кода на GitHub сама по себе не даёт права на коммерческое использование. Такой пакет — повод остановиться и разобраться отдельно.

Шаг 2. Определите категорию лицензии и её требования

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

Для каждой лицензии фиксируйте три вещи: нужно ли сохранять уведомление об авторских правах, нужно ли раскрывать исходный код изменений (и в каком объёме), есть ли патентные оговорки — например, Apache 2.0 содержит явный патентный грант с условием его отзыва при патентном иске к держателям авторских прав.

Шаг 3. Проверьте требования к атрибуции — NOTICE и лицензионное соглашение

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

• файл NOTICE или THIRD-PARTY-LICENSES.md в корне репозитория продукта — перечень компонентов, версий, лицензий и (где требуется) текста уведомления;
• пункт «Open Source Software» в пользовательском соглашении или разделе «О программе» — особенно важно для десктопных и мобильных продуктов, где пользователь физически получает бинарник;
• для веб-сервисов — страница /legal/open-source, доступная из футера или настроек аккаунта.

Формат NOTICE-файла обычно простой:

Продукт использует следующие open-source компоненты:

- lodash 4.17.21 (MIT License)
  Copyright (c) JS Foundation and other contributors
- OpenSSL 3.x (Apache License 2.0)
  Copyright (c) The OpenSSL Project

Полные тексты лицензий доступны по запросу / в приложении A.

Генерируйте такой файл автоматически при сборке, а не ведите вручную — большинство сканеров лицензий (раздел ниже) умеют экспортировать список зависимостей в формате, который легко превратить в NOTICE одним шагом пайплайна. Ручной список в проекте с сотнями зависимостей расходится с реальностью уже через пару спринтов.

Шаг 4. Проверьте транзитивные зависимости

Это шаг, который пропускают чаще всего — он требует смотреть не на прямые зависимости из package.json или requirements.txt, а на весь граф, включая зависимости зависимостей.

Классический сценарий: вы подключаете библиотеку A под MIT. Библиотека A внутри использует библиотеку B под LGPL, а B статически линкует библиотеку C под GPL. Формально вы не знаете о существовании C, но именно она определяет требования, если A и B действительно тянут C в финальную сборку.

Почему это важно: лицензия «протекает» по факту того, что код физически попадает в артефакт (бинарник, Docker-образ, бандл), а не по вашему намерению; в экосистемах с глубокими деревьями зависимостей (особенно Node.js) типичный проект тянет за собой сотни-тысячи транзитивных пакетов, и вручную это не разобрать; часть лицензий несовместима друг с другом — код под разными копилефт-условиями теоретически нельзя объединить в одном произведении.

Проверять руками имеет смысл только прямые зависимости и те транзитивные, что автосканер пометил как copyleft. Отдельно смотрите на то, что попадает в продукт не через код, а через инфраструктуру: базовые Docker-образы, статические бинарники, шрифты, датасеты для ML — у всего этого тоже есть лицензии, которые легко упустить из виду.

Шаг 5. Для SaaS отдельно проверьте наличие AGPL-компонентов

Если продукт — SaaS (доступ через сеть, а не передача бинарника), классические условия GPL часто не срабатывают буквально: обязательство раскрыть код обычно привязано к «распространению», а доступ через сеть распространением в классическом смысле не считается — это называют «ASP loophole».

AGPL написана, чтобы закрыть эту лазейку: раскрытие срабатывает при предоставлении функциональности через сеть, а не только при передаче копии программы. Если в стек SaaS-продукта попал AGPL-компонент (СУБД, поисковый движок, очередь сообщений — среди инфраструктурного open source такое встречается регулярно), отсутствие «распространения» бинарника не защищает.

Что делать: при автосканировании лицензий отдельно фильтруйте всё, что помечено AGPL — не смешивайте с общим списком copyleft; смотрите, как компонент используется — как отдельный сервис за сетевой границей или как встроенная в ваш процесс библиотека, это разные ситуации; если не уверены в трактовке для конкретной архитектуры — здесь чек-лист заканчивается и начинается разговор с юристом (у многих проектов под AGPL есть отдельная коммерческая лицензия именно для таких случаев). Подробный разбор GPL/AGPL — в статье «Лицензии на ПО для сервера: где GPL начинает кусаться»; здесь мы намеренно остаёмся на уровне общей методики.

Инструменты автоматической проверки лицензий

Ручная проверка масштабируется плохо — как только зависимостей больше пары десятков, нужен сканер, который проходит по графу и агрегирует лицензии. Концепция одинакова для разных экосистем: инструмент читает lock-файл (чтобы видеть точные версии), достаёт метаданные лицензии каждого пакета и выдаёт отчёт, часто с белым/чёрным списком и возможностью упасть в CI при находке запрещённого.

По экосистемам (без привязки к конкретным версиям команд, которые быстро устаревают — смотрите актуальную документацию инструмента):

• Node.js/npm — инструменты класса license-checker строят отчёт по node_modules, фильтруют по лицензиям, экспортируют в CSV/JSON для генерации NOTICE;
• Python — pip-licenses и подобный licensecheck читают метаданные установленных пакетов; проверяйте в чистом виртуальном окружении с зафиксированными версиями;
• PHP/Composer, Rust/Cargo, Java/Gradle-Maven — у каждой экосистемы есть свои утилиты для чтения lock-файла и вывода лицензий по всем артефактам, включая транзитивные (например, для Cargo — семейство cargo-license/cargo-deny, последний заодно проверяет уязвимости);
• SBOM-инструменты — генераторы Software Bill of Materials (формат SPDX или CycloneDX) дают единый машиночитаемый список компонентов и лицензий независимо от языка — удобно, если продукт состоит из нескольких сервисов на разных стеках, а корпоративный клиент перед покупкой сам запрашивает SBOM.

Практическая схема внедрения: подключите сканер как отдельный шаг CI (после установки зависимостей, до сборки образа), а не разовую ручную проверку раз в квартал; задайте explicit-политику — список разрешённых категорий (обычно permissive) и запрещённых (обычно strong copyleft и AGPL для closed-source SaaS), а всё остальное помечайте на ручной разбор; настройте падение CI при новой зависимости из запрещённой категории — так проблема ловится на этапе pull request'а, а не через полгода при аудите перед сделкой; регенерируйте NOTICE-файл из отчёта сканера раз в релизный цикл. Если пайплайн проверки живёт на предсказуемом VPS для разработки и CI/CD, а не на случайном ноутбуке разработчика, отчёты воспроизводимы.

Отдельно полезны инструменты вроде Renovate — они не проверяют лицензии сами, но держат версии зависимостей актуальными автоматически, снижая риск годами сидеть на древней версии, не замечая, что в новой мажорной сменилась лицензия.

Частые вопросы