crank/docs/commercial-boundaries.md

Границы open-core и защита коммерческого кода

1. Назначение документа

Этот документ определяет:

• как разделять открытый и коммерческий функционал;
• какие части должны оставаться в публичном репозитории;
• какие части должны выноситься в private delivery;
• как защищать коммерческий код без ложной ставки на обфускацию и "антидекомпиляцию".

2. Базовый принцип

Коммерческий код нужно защищать не попытками спрятать уже опубликованный исходный код, а правильной границей поставки.

Принцип:

• открытый код остается действительно открытым;
• коммерческий код не попадает в public repository;
• коммерческие сервисы и модули поставляются из приватного контура;
• критичные правила лицензирования, metering и security policy исполняются на серверной стороне.

3. Что считается открытым контуром

В публичном репозитории должны оставаться:

• доменная модель Community;
• admin-api, mcp-server и ui, необходимые для Community;
• REST в открытой редакции;
• секреты, auth profiles, agent publishing, logs и usage;
• статический ключ AI-агента;
• контейнерное развертывание Community;
• optional cache abstraction и Community fallback path без внешнего cache store;
• документация, тесты и демо-сценарии Community.

4. Что считается коммерческим контуром

В приватный контур должны выноситься:

• short-lived token service;
• one-time token service;
• GraphQL и gRPC unary, если они выводятся из Community;
• SSO, 2FA, расширенная RBAC, audit log;
• WebSocket, SOAP, gRPC streaming, если они не включаются в Community;
• advanced streaming execution modes;
• metering и billing;
• cloud control plane;
• managed shared cache layer defaults;
• enterprise licensing and entitlement checks;
• private operational tooling and support tooling.

5. Модель разделения репозиториев

5.1. Public repository

Этот репозиторий должен содержать только:

• Community runtime;
• extension points;
• capability model;
• честные product contracts для открытой редакции.

5.2. Private repositories

Коммерческие возможности должны жить отдельно:

• либо в приватных crates;
• либо в приватных приложениях и сервисах;
• либо в отдельных private repositories с собственной поставкой.

Рекомендуемая схема:

• crank-community — public Community repo;
• crank-enterprise — private self-hosted extensions;
• crank-cloud — private cloud control plane и hosted-only logic.

Важно:

• crank-community, crank-enterprise и crank-cloud уже существуют как отдельные repositories;
• crank-community больше не рассматривается как промежуточный baseline import, а является public source base;
• дальнейшая работа делится на два типа:
  • общие open-core улучшения сначала делаются в crank-community, затем переносятся в private repositories;
  • cleanup и ограничение Community делаются только в crank-community.

6. Техническая стратегия разделения

6.1. Capability-first design

Открытый код должен опираться на capability model:

• edition capabilities;
• protocol capabilities;
• auth capabilities;
• security capabilities.

Это позволяет:

• скрывать недоступные функции в UI;
• не смешивать Community и commercial code paths;
• добавлять private implementations без форка всей архитектуры.

6.2. Extension seams

В public repo должны быть только контракты и точки расширения:

• trait boundaries;
• service contracts;
• edition flags;
• protocol registry abstraction;
• token issuer abstraction;
• cache store abstraction;
• feature availability checks.

Дополнительно для runtime layer:

• premium protocol adapters должны подключаться как feature-gated seams;
• REST-база должна собираться без GraphQL/gRPC/SOAP/WebSocket crates;
• UnsupportedProtocol должен оставаться публичным fallback contract для disabled protocol paths.

Private code должен подключаться как реализация этих контрактов, а не как условные ветки по всему коду Community.

6.3. Server-side enforcement

Критичные коммерческие ограничения должны исполняться только на сервере:

• edition capabilities;
• token issuance policy;
• licensing checks;
• metering;
• protocol availability;
• per-operation security rules.

Фронтенд может только отображать состояние. Он не должен быть единственным местом, где проверяется "можно / нельзя".

7. Что не является реальной защитой

Нельзя считать надежной защитой:

• минификацию frontend-кода;
• обфускацию JavaScript;
• "сложность" Rust binary как основную линию защиты;
• попытку скрыть коммерческую логику в публичном репозитории через feature flags, если исходный код уже доступен.

Все это может немного повысить порог извлечения, но не решает задачу защиты коммерческого IP.

8. Реальная защита коммерческого кода

8.1. Не публиковать исходный код

Основное правило:

• коммерческий исходный код не должен попадать в public repo.

8.2. Поставлять private artifacts

Коммерческий контур должен поставляться как:

• private container images;
• private binary artifacts;
• private Helm charts;
• private configuration bundles.

8.3. Подписывать артефакты

Для коммерческой поставки должны использоваться:

• подписанные контейнерные образы;
• проверяемая provenance metadata;
• versioned private releases.

8.4. Хранить ключевую логику на сервере

Наиболее чувствительные части должны оставаться на серверной стороне:

• licensing;
• token issuance;
• cloud metering;
• enterprise access policy;
• hosted control plane logic.

8.5. Не включать private UI в OSS bundle

Если функция коммерческая, ее UI не должен полноценно поставляться в Community build.

Допустимы:

• capability-driven hiding;
• ограниченный teaser copy.

Недопустимы:

• полностью рабочие commercial screens в open-source bundle;
• наличие private API contracts без server-side gating.

9. Что нужно сделать в кодовой базе

Для подготовки к коммерческой реализации в open-source коде должны появиться:

• edition capability model;
• protocol capability model;
• auth capability model;
• интерфейсы для token issuer и enterprise access services;
• server-side policy checks;
• UI gating по capability flags;
• отдельные delivery manifests для Community.

Первый обязательный шаг на практике:

• canonical public deployment manifest должен жить отдельно от root development convenience files;
• Community release path должен опираться на deploy/community/*;
• private Enterprise и Cloud manifests не должны проектироваться как вариации того же root compose-файла.

Подготовительные bootstrap artifacts уже перестали быть центральной частью Community workflow. Для crank-community source of truth теперь находится в самом репозитории, а не в transitional templates.

10. Связанные документы

• docs/product-editions.md
• docs/community-release-checklist.md
• docs/repository-split-map.md
• docs/agent-auth-model.md
• docs/module-decomposition.md
• docs/frontend-roadmap.md
• docs/refactoring-roadmap.md
• docs/implementation-plan.md