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