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, GraphQL и gRPC unary в открытой редакции;
• секреты, auth profiles, agent publishing, logs и usage;
• статический ключ AI-агента;
• контейнерное развертывание Community;
• документация, тесты и демо-сценарии Community.

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

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

• short-lived token service;
• one-time token service;
• SSO, 2FA, расширенная RBAC, audit log;
• WebSocket, SOAP, gRPC streaming, если они не включаются в Community;
• advanced streaming execution modes;
• metering и billing;
• cloud control plane;
• 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 — public Community repo;
• crank-enterprise — private self-hosted extensions;
• crank-cloud — private cloud control plane и hosted-only logic.

Важно:

• создание crank-enterprise и crank-cloud должно быть отдельным осознанным шагом;
• до этого момента в public repo нужно завершить capability model, extension seams и public contracts;
• физическое вынесение private code нельзя начинать раньше, чем эти два private repositories созданы и для них определены delivery boundaries.

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;
• feature availability checks.

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.

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

• docs/product-editions.md
• docs/agent-auth-model.md
• docs/module-decomposition.md
• docs/frontend-roadmap.md
• docs/refactoring-roadmap.md
• docs/implementation-plan.md