// вики · гайд · сентябрь 2026
Open source в продукте компании
Проект статьи. Описания лицензий — упрощённые рабочие ориентиры; текст конкретной лицензии и её применимость всегда первичны.
Черновик для обсуждения. Статья отвечает на вопрос «что проверить перед выпуском продукта», но не заменяет аудит конкретной сборки: состав зависимостей решает больше, чем выбор основной лицензии.
Короткий ответ
Пермиссивные лицензии обычно допускают включение кода в закрытый продукт при соблюдении условий конкретной лицензии. Для Apache 2.0 это, в частности, сохранение лицензии и необходимых уведомлений, обозначение изменений и соблюдение условий о NOTICE. Обязанности по GPL и AGPL зависят от состава продукта, модификаций и способа предоставления программы; список компонентов помогает определить, что именно нужно проверить.
Карта лицензий
| Лицензия | В проприетарный продукт | Обязанность открыть код | Запомнить |
|---|---|---|---|
| MIT, BSD | Да | Нет | Сохранить копию лицензии и уведомление об авторах |
| Apache-2.0 | Да | Нет | Патентная лицензия авторов; файл NOTICE; перечень изменений |
| MPL-2.0 | Да, при изоляции | Только изменённые файлы под MPL | Copyleft на уровне файлов: границы модуля важно держать чистыми |
| LGPL-2.1 / 3 | Да, при динамической линковке | Изменения самой библиотеки | Статическая линковка и правки библиотеки усложняют позицию |
| GPL-2 / 3 | Практически нет | Весь производный код при распространении | Производное произведение — ключевой и спорный термин |
| AGPL-3.0 | Зависит от компонентов и способа объединения | Раздел 13: сетевое взаимодействие пользователей с модифицированной программой | Проверить состав соответствующего исходного кода |
Отдельная категория — «доступные исходники» (source-available: SSPL, BSL и собственные лицензии вендоров): код виден, но это не open source, условия коммерческого использования нужно читать целиком.
AGPL: ловушка для SaaS
Если модифицированная программа под AGPL взаимодействует с пользователями по сети, раздел 13 требует предложить этим пользователям соответствующий исходный код модифицированной версии. Объём обязанностей зависит от состава и способа объединения компонентов. Наличие AGPL-компонента требует проверки конкретной лицензии и архитектуры продукта, а не автоматического вывода об обязанности открыть весь сервис.
Типовые ошибки
- Копипаст фрагментов со Stack Overflow и блогов: код в ответах обычно под CC BY-SA — с условием share-alike, которое не дружит с проприетарным продуктом.
- Транзитивные зависимости: ваш пакет под MIT тянет пакет под GPL — карта лицензий собирается по всему дереву, а не по прямым зависимостям.
- Для API-клиентов и SDK проверяют лицензию самого компонента и способ его связи с продуктом; обращение к AGPL-сервису по API само по себе не устанавливает режим всего продукта.
- «Нет лицензии» = «можно всё». Наоборот: код без файла лицензии по умолчанию охраняется — использовать нельзя, пока автор прямо не разрешил.
Список компонентов
Рабочая дисциплина — держать перечень стороннего кода (SBOM): компонент, версия, лицензия, где используется. Генерируется сканерами состава автоматически; юристам достаточно контролировать триггеры: новые GPL/AGPL в дереве, конфликт лицензий, компоненты без лицензии. Для регуляторно чувствительных продуктов список ещё и часть доказательной базы — по аналогии с журналом происхождения данных из статьи «Обучение модели на чужих произведениях».
Open source в сделках
В инвестиционных раундах и M&A список open source — стандартный запрос due diligence: инвестор проверяет, не «заряжен» ли продукт копилефтом, который обесценит актив (подробнее — «Due diligence ИИ-актива»). Если списка нет, его собирают перед сделкой в аварийном порядке — дороже и с находками. Дешевле — политика из трёх строк для команды: пермиссивные — можно; MPL/LGPL — через ревью; GPL/AGPL — только с одобрением.
Аудит лицензий в продукте и политика open source — часть практики прав на технологии.
Источники к отдельным положениям
Подборка относится только к указанным вопросам и не означает полной правовой проверки статьи.