Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

Контрольные вопросы

Базовый уровень 1. Чем SPDX License List отличается от SPDX License Expression? Приведите пример выражения с оператором. 2. Что означают операторы OR, AND и WITH в SPDX-выражении? Чем MIT OR Apache-2.0 отличается от MIT AND Apache-2.0 по обязательствам? 3. В чём разница между GPL-2.0-only и GPL-2.0-or-later и почему она влияет на вердикт? 4. Назовите четыре поведенческих класса лицензий и по одному примеру каждого.

Средний уровень 5. Чем permissive-лицензия (MIT, BSD-3-Clause) отличается от Apache-2.0 по объёму обязательств? Что добавляет Apache-2.0? 6. Почему weak copyleft (LGPL, MPL) и strong copyleft (GPL) дают разный вердикт для одного и того же продукта? Что именно «открывается» в каждом случае? 7. Что особенного в AGPL-3.0 по сравнению с GPL-3.0 и при каком сценарии распространения это срабатывает? 8. Почему NOASSERTION (или пустое поле лицензии) — это риск, а не нейтральное состояние? Какой вердикт ему соответствует? 9. Что хранится в evidence.licenses SBOM и зачем держать его рядом с нормализованным expression?

Продвинутый уровень 10. Совместимость лицензий направленная: почему Apache-2.0-код можно включить в GPL-3.0-проект, но не наоборот? Почему Apache-2.0 конфликтует с GPL-2.0-only? 11. Как способ линковки (динамическая / статическая) и архитектура продукта (бинарник / SaaS) меняют вердикт по одному и тому же компоненту? 12. Как сервис аудита/вердиктов реализует цепочку «evidence → нормализация → вердикт → заключение/риск» и где в ней проходит граница между автоматикой и ручным решением юриста?

Кейс-задачи

Кейс 1. Транзитивный AGPL Продукт Организации распространяется как закрытый бинарник для локальной установки у заказчика. В транзитивной зависимости обнаружен компонент AGPL-3.0-only. Через квартал планируется облачная (SaaS) версия того же продукта. Вопросы: есть ли нарушение сейчас? возникнет ли оно после перехода в SaaS? какой вердикт вынести сегодня и с каким сроком пересмотра? куда это записать?

Кейс 2. Dual licensing и неверный выбор В SBOM пришёл компонент с выражением GPL-2.0-only OR MIT. Инженер при сборке указал в документации «компонент под GPL» и приложил исходники всего продукта. Вопросы: была ли у Организации обязанность раскрывать исходники? какую лицензию выгоднее было выбрать и почему? как ошибка выбора превращается в добровольно принятое copyleft-обязательство?

Кейс 3. Неизвестная лицензия от соисполнителя Соисполнитель прислал SBOM, где у 12 из 80 компонентов лицензия — NOASSERTION, а у двух — LicenseRef-vendor-custom с приложенным текстом. Вопросы: можно ли по такому SBOM дать вердикт о готовности? что делать с NOASSERTION и чем LicenseRef-* отличается от обычного SPDX-идентификатора в части обработки? кто и каким артефактом закрывает эти 14 позиций?

Связи

Практики: П26. Лицензионная классификация · П27. Юридическое заключение и реестр лицензий · П30. Исключения и принятие риска. Нормативка: SPDX ISO/IEC 5962 · OpenChain ISO/IEC 5230.