Совещание по лицензиям · 27.05.2026

Лицензионный аудит
в сервисе «РБПО-аудит»

Откуда берутся лицензии, как мы их обобщаем по стандарту SPDX и почему они выглядят именно так. Доказательная база для юристов Общества и регулятора.
Виталий А. Пиков
Специалист по безопасной разработке ПО · АО МНТЦ МИЭТ · vitaliy@pikov.com
27 мая 2026 г.
Совещание по лицензиям
О чём доклад

Содержание

6 блоков · 14 слайдов
01
Зачем централизованный лицензионный аудит
Слайд 3 · постановка задачи и доказательность
02
Откуда берутся лицензии
Слайд 4 · bom.json и реестр sbom-reporter
03
Как строка становится записью каталога
Слайды 5–6 · SPDX и нормализация
04
SPDX и «Custom»: три причины
Слайд 7 · почему часть лицензий без SPDX-кода
05
Обобщение и «повторения»
Слайды 8–10 · что склеиваем, а что нет
06
Юр. вердикт, заключение, роли
Слайды 11–14 · итог и ограничения
Основная аудитория Юристы Общества: фокус доклада — почему каталог лицензий выглядит именно так, что в нём «Custom» и «повторения», как принимать по ним решения и где зафиксирован след вашего решения.
👉 За 14 слайдов — путь одной строки лицензии от ZIP-выгрузки соисполнителя до подписанного юристом заключения.
Блок 1 · Постановка задачи

Зачем централизованный лицензионный аудит

ГОСТ Р 56939-2024 §5.16 · контроль лицензионной чистоты
  1. В продукте проекта — тысячи заимствованных компонентов от головного исполнителя и 7 соисполнителей; у каждого своя лицензия (а иногда несколько).
  2. Лицензия определяет, можно ли использовать компонент в поставке и на каких условиях: копилефт, патенты, атрибуция, исключения.
  3. Нужен единый каталог лицензий + доказательная история решений юриста — кто, когда, на основании какого документа.
Цитата из ТЗ ОКР «Контролировать заимствованные компоненты, их версии, источники, лицензии и уязвимости, а также вести доказательную историю изменений».
1 839
компонентов в едином SBOM проекта
~130
лицензий в каталоге Сервиса
8
организаций: 1 головной + 7 соисполнителей
1
общий каталог лицензий вместо разрозненных таблиц
Альтернатива — то, чего мы избегаем Excel-таблица у каждого соисполнителя, версии расходятся, решения юриста не привязаны к компонентам, доказательность теряется при первой ротации кадров.
👉 Без единого процесса лицензионный аудит распадается на разрозненные таблицы и теряет доказательность.
Блок 2 · Источники

Откуда сервис получает строки лицензий

ADR-0023 · bom.json — первичный источник
Первичный источник
bom.json
CycloneDX-SBOM от cdxgen, генерируется автоматически при сборке у соисполнителя.
  • Машиночитаемый перечень всех зависимостей
  • Имя, версия, PURL, лицензии — «как есть»
  • Источник истины по составу
join по (имя, версия)
Единый
каталог
в сервисе
Дополнение
SBOM-Registry.xlsx
Реестр sbom-reporter — заполняется специалистом РБПО соисполнителя.
  • Лицензии, авторы, метод детектирования
  • Контекст, которого нет в bom.json
  • Точки ручной верификации
Что такое SBOM и CycloneDX SBOM — машиночитаемый перечень компонентов ПО, как «состав» на упаковке. CycloneDX — его открытый формат. cdxgen — инструмент генерации.
Что это значит для нас Сырая строка лицензии — не наш текст. Её записал сканер соисполнителя. Сервис получает её «как есть» и обязан корректно обработать любой вход — даже «Лицензии не найдены.».
👉 Строку лицензии записал сканер соисполнителя — мы получаем её «как есть» и обязаны корректно обработать любой вход.
Блок 3 · Эталон сопоставления

SPDX — международный стандарт идентификации лицензий

Linux Foundation · ~600 идентификаторов
  • SPDX — список канонических коротких идентификаторов лицензий, поддерживаемый Linux Foundation: MIT, Apache-2.0, GPL-3.0-only, BSD-3-Clause.
  • Это «ИНН лицензии»: один код во всём мире = один и тот же текст лицензии, проверяемый по эталону.
  • «Нормальная» лицензия в нашем каталоге — та, чья строка совпала с SPDX-идентификатором.
  • Всё, что к SPDX не сводится, мы помечаем «Custom» — не выбрасываем, не угадываем.
Аналогия для юристов SPDX — это как ИНН организации. У ООО «Ромашка» может быть много адресов, печатей и сокращений, но ИНН один. SPDX-id играет ту же роль для текста лицензии.
Примеры сопоставления
MIT License
The MIT License · Expat · MIT/X11
→
MIT
Apache License, Version 2.0
Apache 2 · ASLv2
→
Apache-2.0
GNU General Public License v3
GPLv3 · GPL v3 only
→
GPL-3.0-only
BSD 3-Clause
New BSD · Modified BSD
→
BSD-3-Clause
👉 SPDX — наш эталон сопоставления. Всё, что к нему не сводится, мы намеренно помечаем «Custom» и оставляем юристу для ручной проверки.
Блок 3 · Нормализация

Путь строки лицензии: от текста до записи каталога

ADR-0004 · ключи лицензий
сырая строка из SBOM │ очистка: URL-хвосты, скобки, пробелы ▼ поиск в таблице синонимов │ «the mit license», «expat», «mit» → канон «MIT» ▼ канон найден? ├─ нет ───────────────────────► CUSTOM │ license_key = исходная строка, spdx_id = NULL └─ да: канон — валидный SPDX? ├─ да ──────────────► ОБЫЧНАЯ │ spdx_id присвоен, license_key = SPDX └─ нет ─────────────► CUSTOM license_key = канон, spdx_id = NULL
Что делает модуль
  • Таблица синонимов сводит сотни вариантов написания к одному канону: mit, the mit license, expat → канон MIT.
  • Канон проверяется по официальному списку SPDX — это и есть граница между «обычной» и «Custom»-лицензией.
  • Сервис не угадывает: если строка не свелась к SPDX — она становится Custom, исходный текст сохраняется.
Определение признака «Custom» Custom = у лицензии нет SPDX-идентификатора. Не «плохая» и не «незаконная» — просто требует ручной оценки юриста.
👉 Признак «Custom» — это не дефект, а пометка «нужна ручная проверка юриста»: автоматика не нашла однозначного эталона.
Блок 3 · Нормализация

Почему часть лицензий — «Custom»: три причины

Анализ каталога на 27.05.2026
ПричинаПримеры из нашего каталога
1. Составное SPDX-выражение
комбинация лицензий через OR / AND / WITH		 (MIT OR CC0-1.0) (Apache-2.0 AND BSD-3-Clause) (MPL-2.0 OR Apache-2.0) Каждая часть валидна по SPDX, но выражение в целом — нет; юрист решает, на каких условиях используем компонент.
2. Вольное написание имени
человеческое название, не совпавшее с SPDX-эталоном		 Apache License, 2.0 GPLv3 CC0 The Apache Software License, Version 2.0 По смыслу — известная лицензия. Свести автоматически без риска ошибки нельзя — юрист подтверждает соответствие SPDX-канону.
3. Вендорная или нестандартная метка
фирменные названия, кастомные тексты, пустые значения		 BSD3_Google Caramel Лицензии не найдены. Это и есть случаи, ради которых «Custom» существует: требуется прочитать сам текст лицензии и принять юридическое решение.
👉 Сервис не угадывает и не выбрасывает непонятную лицензию — он сохраняет исходную строку как «Custom» для ручной проверки юристом.
Блок 4 · Обобщение

Как сервис сводит лицензии в одну запись каталога

ADR-0004 · UPSERT по spdx_id → license_key
Сырые строки из 10 компонентов
"MIT"
"MIT License"
"The MIT License"
"Expat"
"MIT/X11"
"the mit license"
… 4 ещё
→
Одна запись каталога
MIT
SPDX · ОБЫЧНАЯ
канон совпал с SPDX-эталоном
→
Связь с компонентами
lodash 4.17
express 4.19
react 18.3
axios 1.7
chalk 5.3
moment 2.30
+ 4 компонента
всего: 10
Каталог общий Каталог лицензий не заводится заново на каждую выгрузку. Все строки, сошедшиеся к одному SPDX-id, становятся одной записью — независимо от того, какой соисполнитель её прислал.
Видимость для юриста По каждой лицензии видно, в каких компонентах она встречается и у каких соисполнителей — одно решение юриста покрывает все случаи этой лицензии в проекте.
👉 Обобщение = объединение достоверно одинаковых лицензий, без потери связи с компонентами.
Блок 4 · Обобщение

Почему встречаются «повторения» — и почему это правильно

Сознательная юридическая точность
Причина 1 · строки не сошлись к SPDX
Разные написания «про Apache»
  • Apache-2.0 — обычная (SPDX)
  • Apache License, 2.0 — Custom (вольная запись)
  • (MPL-2.0 OR Apache-2.0) — Custom (выражение)
Три разные строки. Сервис не сливает их «по догадке» — каждая остаётся отдельной записью до решения юриста.
Причина 2 · лицензии с исключениями
Намеренно держим отдельно
  • MIT ≠ MIT-with-embedded-exception
  • Apache-2.0 ≠ Apache-2.0-with-LLVM-exception
  • GPL-2.0-only ≠ GPL-2.0-with-classpath-exception
Исключение меняет юридические обязательства — это другая лицензия, даже если базовая та же.
Принципиальная позиция «Исключение или оговорка меняет юридические обязательства. Свести вариант с исключением в базовую лицензию — значит принять решение не по тому тексту, который действительно сопровождает компонент».
👉 Лишняя запись здесь — это сознательная юридическая точность, а не ошибка обобщения.
Блок 4 · Обобщение

«А мы ничего не потеряли?» — нет

ADR-0022 · immutability выгрузок
  • Сырая строка лицензии всегда сохраняется — даже если опознать её автоматически не удалось, исходный текст остаётся на месте (как «Custom»).
  • Ничего не сливается «по догадке» — только достоверно одинаковое (совпадение SPDX-id после нормализации).
  • Каждая выгрузка — неизменяемый снимок (immutability, ADR-0022): история не переписывается; оценки юриста за прошлый период не затираются новой выгрузкой.
  • Привязка лицензия ↔ компонент сохраняется полностью: видно, у каких соисполнителей и в каких версиях встречается каждая лицензия.
Принцип Полнота важнее догадок. Лучше лишняя запись на проверку юристу, чем потерянная или неверно объединённая лицензия в поставке регулятору.
Иммутабельность на практике Если 27.05.2026 юрист утвердил вердикт по лицензии (MPL-2.0 OR Apache-2.0), а соисполнитель потом перевыпускает SBOM с другой формулировкой — старая запись и старое заключение не исчезают и не «исправляются». Это и есть доказательная история.
Если объединить нужно Сведение Custom-дублей, которые по сути одна лицензия, делается осознанно вручную через интерфейс — с фиксацией, кто и когда принял это решение.
👉 Полнота важнее догадок: лучше лишняя запись на проверку, чем потерянная или неверно объединённая лицензия.
Блок 5 · Юридический контур

Юридический вердикт, заключение, история

ADR-0003 · lifecycle заключения
Четыре возможных вердикта юриста по лицензии
🟢 Безопасно
можно использовать в поставке
🟡 Риск
с условиями / атрибуцией
🔴 Небезопасно
в поставку нельзя
⚪ Не оценено
ждёт решения юриста
Жизненный цикл заключения по одной лицензии
Шаг 1
Черновик
Юрист готовит оценку, заполняет комментарий, прикладывает материалы. В каталоге — предварительный вердикт.
→
Шаг 2 · финальный
Утверждено
Обязателен PDF подписанного заключения. С этого момента вердикт — финальный и используется в отчётах.
→
Шаг 3 · опц.
Устарело
Используется, когда выходит новая версия лицензии или меняются обстоятельства. Старая запись и PDF не удаляются — остаются в истории.
Комментарий и история изменений Комментарий к вердикту — постоянное редактируемое поле. Каждая правка сохраняется отдельной записью истории: кто, когда, что было до. Это и есть доказательная база.
Worst-verdict-wins Вердикт компонента = худший из вердиктов его лицензий. Один 🔴 у любой из лицензий компонента делает 🔴 весь компонент — это страхует от ситуации «забыли посмотреть вторую лицензию».
👉 Решение юриста фиксируется с документом и историей — это и есть доказательная лицензионная чистота.
Блок 5 · Юридический контур

Навигация: семейства, фильтры, подсветка по вердикту

Экран «Лицензии»
РБПО-аудит · Каталог лицензий проекта
/licenses
🔍 поиск: SPDX-id / название / синоним …
Семейство ▾
Вердикт ▾
Только без заключения
SPDX-ID / название Вердикт Утверждено Семейство Комп. PDF
MIT 🟢 Безопасно 2026-04-12 MIT 312 📄 verdict-MIT.pdf
Apache-2.0 🟢 Безопасно 2026-04-12 Apache 248 📄 verdict-Apache-2.pdf
LGPL-2.1-only 🟡 Риск 2026-05-08 LGPL 31 📄 verdict-LGPL-21.pdf
AGPL-3.0-only 🔴 Небезопасно 2026-03-21 AGPL 2 📄 verdict-AGPL-3.pdf
Custom · (MPL-2.0 OR Apache-2.0) 🟡 Риск 2026-05-19 Custom 7 📄 verdict-MPL-Apache.pdf
Custom · BSD3_Google ⚪ Не оценено — Custom 3 не приложен
Custom · Лицензии не найдены. ⚪ Не оценено — Custom 14 не приложен
Что делает экран «Лицензии»
  • Семейство лицензии определяется автоматически — для группировки и фильтрации каталога.
  • Подсветка строки по вердикту — опасные лицензии видны с одного взгляда.
  • Фильтры: по вердикту, семейству, наличию заключения; поиск по SPDX-id и синонимам.
  • PDF заключения скачивается прямо из списка — для регулятора и внутренних проверок.
Поддерживаемые семейства
MIT · 1 Apache · 1 BSD · 4 GPL · 3 LGPL · 3 MPL · 2 AGPL · 1 Proprietary Custom
👉 Юрист быстро находит, что ждёт оценки, и видит, что финально утверждено и приложено.
Блок 5 · Юридический контур

Кто что видит: четыре роли в Сервисе

RBAC + row-level изоляция
основная аудитория
Юрист Общества
Работает только с лицензиями.
  • Каталог лицензий — общий, видит все
  • Выносит вердикт, загружает PDF
  • Ведёт комментарии и историю
  • Не видит код и сборочные данные
Общество
Специалист РБПО Общества
Видит весь проект.
  • Компоненты, лицензии, выгрузки
  • С админ-флагом — управление
  • Отвечает за единый SBOM проекта
  • Сводит данные соисполнителей
Управление
Руководитель проекта
Решения по рискам, эскалация.
  • Светофор по компонентам и лицензиям
  • Решения RiskDecision
  • Лицензии — только просмотр
  • Доступ к сводкам и трендам
соисполнитель
Специалист РБПО соисполнителя
Только свои компоненты.
  • Изоляция данных по организации
  • Каталог лицензий открыт всем
  • «Свои» лицензии подсвечены
  • Загружает SBOM своей организации
Принцип изоляции Компоненты и сборочные данные изолированы по организации (row-level). Каталог лицензий — общий проектный ресурс: лицензия одна на весь проект независимо от того, кто её принёс.
👉 Каждый видит ровно своё; каталог лицензий — общий и открытый, чтобы решение юриста работало на весь проект сразу.
Блок 6 · Итог

Ограничения, развитие и итог

Честно · на 27.05.2026
⚠ Ограничения сейчас
  • Custom-дубли, которые по сути одна лицензия, сводятся пока вручную юристом.
  • Версия лицензии иногда не указана в SBOM (Apache без версии) — запрашиваем у соисполнителя.
  • Для редких вендорных меток требуется чтение исходного текста лицензии вручную.
→ Дорожная карта
  • Инструмент-алиас для безопасного объединения Custom-дублей (с фиксацией решения).
  • Обогащение уязвимостями (CVE / БДУ ФСТЭК) — отдельный контур Dependency Track.
  • Шаблоны заключений и массовая подпись однотипных вердиктов.
✅ Итог Лицензии собираются автоматически, обобщаются по стандарту SPDX, ничего не теряется, а решения юриста фиксируются с документом и историей.
Контакт докладчика Виталий А. Пиков · специалист по безопасной разработке ПО · АО МНТЦ МИЭТ · vitaliy@pikov.com
Связанные документы licenses-catalog-explained.md · ADR-0023 (bom.json) · ADR-0004 (ключи лицензий) · ADR-0013 (модель лицензии) · ADR-0003 (lifecycle заключения) · ADR-0022 (immutability)
👉 Сервис превращает разрозненные строки лицензий в доказательную, проверяемую картину лицензионной чистоты проекта.