Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

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

П27. Юридическое заключение и реестр лицензий

Зачем эта практика Машинная находка живёт в JSON и ни за что не отвечает. Юридическое решение должно быть привязано к компоненту, обосновано уликой, подписано человеком и записано в реестр, который переживёт смену сотрудников. Эта практика — финал цепочки модуля: вы берёте разобранный copyleft- или unknown-кейс и оформляете его как карточку заключения (evidence → обязательства → вердикт) и запись в реестре лицензий, пригодную для аудита. Без инструментов: работа идёт в сервисе аудита/вердиктов либо в табличном реестре по шаблону.

Цель

Оформить карточку юридического заключения по одному компоненту: исходное evidence, нормализованное SPDX-выражение, перечень обязательств, контекст распространения (линковка/сеть), итоговый вердикт и ответственный с датой и сроком пересмотра. Завершить — внести компонент в реестр лицензий со статусом. Проверяемый результат — заполненная карточка + строка в реестре, привязанные к purl компонента.

Команда или действие

Аналитическая практика, артефакт — карточка заключения. Структура (заполняется по шаблону или в сервисе аудита/вердиктов):

# Карточка юридического заключения по компоненту
component:
  purl: "pkg:npm/somelib@2.4.1"        # привязка к опознанному компоненту (М04)
  name: "somelib"
  version: "2.4.1"
evidence:
  declared: "MIT"                       # из метаданных пакета
  detected: "GPL-2.0-only"             # находка ScanCode/FOSSology (П11/П13)
  source_file: "vendor/somelib/parser.c:3-18"
  raw_text: "This program is free software; you can redistribute..."
license:
  spdx_expression: "GPL-2.0-only"       # нормализованное выражение
  class: "strong copyleft"
distribution_context:
  linking: "static"                     # static | dynamic | none
  network_use: false                    # релевантно для AGPL
obligations:
  - "Открыть исходный код производного произведения при распространении бинарника"
  - "Сохранить уведомления об авторских правах и текст лицензии"
verdict:
  decision: "blocker"                   # allowed | conditional | blocker | needs-opinion
  rationale: "strong copyleft в проприетарной поставке при статической линковке"
  decided_by: "роль: юрист (не ФИО)"
  decided_at: "2026-06-17"
  review_by: "2026-12-17"

Строка в реестре лицензий (CSV/таблица), привязанная к компоненту:

purl,license,class,verdict,decided_at,review_by,opinion_ref
pkg:npm/somelib@2.4.1,GPL-2.0-only,strong-copyleft,blocker,2026-06-17,2026-12-17,OP-2026-014

Вердикт без контекста распространения неполон Один и тот же purl даёт разный вердикт: LGPL при динамической линковке — conditional, при статической — ближе к blocker; AGPL в закрытом контуре безвреден, но «выстреливает» при превращении продукта в сетевой сервис. Поэтому поля linking и network_use в карточке обязательны — без них заключение нельзя ни проверить, ни переиспользовать при смене архитектуры.

Что вы должны увидеть

В сервисе аудита/вердиктов компонент после внесения заключения переходит из статуса «нет вердикта» в конкретный статус, и у него появляется история: кто, когда, на каком основании. Проверяемый минимум:

Минимальный набор «было/стало» Было (П11/П26): pkg:npm/somelib@2.4.1 — detected GPL-2.0-only, статус «нет вердикта». Стало (П27): тот же purl — вердикт blocker, обоснование «strong copyleft при статической линковке в проприетарной поставке», ответственный — роль «юрист», пересмотр через 6 месяцев, ссылка на заключение OP-2026-014. Аудитор по строке реестра восстанавливает всю цепочку решения.

Если не получилось

Типичные ошибки - Вердикт без evidence — записано «GPL, блокер», но не указано, в каком файле и какой текст это породил. При споре нечем доказать; заключение нефальсифицируемо. - Привязка к имени без версии — somelib вместо pkg:npm/somelib@2.4.1. Лицензия и обязательства могут отличаться между версиями; вердикт должен висеть на конкретном purl. - Нет срока пересмотра — review_by пуст. Лицензия компонента может смениться при обновлении; бессрочный «allowed» превращается в дыру. - needs-opinion оставлен как финальный статус — это промежуточное состояние, а не вердикт. Компонент с ним не готов к выпуску; его нужно довести до allowed/conditional/blocker.

Критерий зачёта

Показать преподавателю: (1) карточку заключения с обеими частями (evidence + verdict), заполненными полями class, distribution_context, obligations; (2) строку в реестре лицензий, привязанную к purl с ответственным, датой и сроком пересмотра; (3) объяснение, как этот же purl получил бы другой вердикт при изменении линковки или при сетевом использовании. Карточка-«заглушка» без улики или без ответственного не засчитывается — практика проверяет именно доказуемость и подотчётность решения.

Нормативная связка