ADR 0101: Лицензирование и стратегия коммерциализации¶

Статус: Accepted
Дата: 2026-04-26

Связанные ADR¶

ADR	Роль
0009	связанный ADR
0024	связанный ADR
0027	связанный ADR
architecture-policy.md	вне нумерованного ADR

Резюме¶

Матрица лицензий и правила зависимостей (copyleft, коммерциализация).
Guardrails для выбора стека и публикации артефактов.
Governance — рядом с 0100.

1. Контекст¶

CascadeIDE планирует оставаться open source, сохраняя варианты коммерциализации (облачные сервисы, корпоративные сервисы, поддержка, пользовательские интеграции).
Проект также рассматривает зависимости ИИ и времени выполнения с разными лицензионными моделями, включая «сильный» копилефт.

Без явной политики решения по зависимостям могут дрейфовать и создавать будущие IP-конфликты (ограничения распространения, риски при пере-лицензировании, риски для due diligence и неопределённость для контрибьюторов).

2. Решение¶

Принять лицензионную стратегию open source с сохранением коммерческих опций:

Код CascadeIDE в этом репозитории распространяется под MIT (см. корневой LICENSE); коммерческие услуги и публичные контакты — в COMMERCIAL-NOTICE.md.
Базовый путь распространения использует только лицензии из базового разрешённого списка.
Компоненты со «сильным» копилефтом (семейство GPL/AGPL) запрещены в ядре и рантайме без отдельного утверждённого ADR-исключения.
Коммерциализация остаётся открытой через:
управляемые облачные предложения,
корпоративные расширения,
поддержку/консалтинг/обучение.
Каждая новая внешняя зависимость проходит проверку и фиксируется с лицензионными метаданными.

3. Матрица лицензионной политики¶

3.1 Разрешено по умолчанию¶

MIT
Apache-2.0
BSD-2-Clause
BSD-3-Clause

3.2 Разрешено с явной проверкой¶

MPL-2.0
семейство LGPL

Критерии проверки для этой группы: - модель связывания и развёртывания, - обязательства на изменённые файлы/библиотеки, - влияние на распространение пакетированных desktop-сборок.

3.3 Ограничено (требуется ADR-исключение)¶

семейство GPL
семейство AGPL
SSPL
custom non-commercial / source-available условия, ограничивающие бизнес-использование

4. Правила управления зависимостями¶

Для каждого нового пакета или библиотеки:

Фиксировать:
имя пакета,
версию,
URL источника,
заявленную лицензию,
заметные риски по транзитивным лицензиям.
Добавлять и обновлять проектные уведомления в docs/THIRD-PARTY-NOTICES.md.
Обеспечить, что проверки лицензий в CI падают при:
запрещённых лицензиях,
неизвестных/неразрешённых лицензиях.

5. Архитектурный ограничитель для запрещённых лицензий¶

Если рассматривается компонент с запрещённой лицензией:

Начинать с оценки PoC вне пути поставки ядра.
Проводить юридическую и продуктовую проверку (обязательства, модель распространения, политика обновлений).
Разрешать только через отдельное ADR-исключение с планом отката.

Без явной юридической проверки не предполагается «автоматическая безопасность» только из-за процессных границ (например, sidecar/process split).

6. Модель коммерциализации (неисключительная)¶

Open source-ядро совместимо с коммерческими сценариями через:

облачные и управляемые сервисы,
корпоративные дополнения,
платную поддержку/SLA,
консалтинг и внедрение.

Этот ADR не фиксирует единственный путь монетизации; он сохраняет гибкость и при этом поддерживает гигиену зависимостей.

7. Последствия¶

Положительные¶

Ясные правила контрибуций и зависимостей.
Более чистая IP-цепочка для будущего due diligence.
Ниже риск случайной лицензионной блокировки.

Отрицательные¶

Часть технически привлекательных библиотек может быть исключена из ядра.
Больше процессной нагрузки при добавлении зависимостей.

8. План внедрения¶

~~Добавить license-policy.md (краткая политика для разработчиков).~~ Сделано: ../license-policy.md.
~~Добавить/поддерживать THIRD-PARTY-NOTICES.md.~~ Сделано: ../THIRD-PARTY-NOTICES.md (копируется в publish через CascadeIDE.csproj).
Добавить в CI проверку лицензий как обязательный этап.
Провести базовый аудит лицензий зависимостей и устранить находки.
Вести исключения отдельными ADR.