# Лицензирование qeli

Это монорепозиторий с **несколькими лицензиями по каталогам**. GitHub в шапке
показывает только одну (корневую — AGPL-3.0); полная карта — здесь.

## Карта лицензий

| Путь | Лицензия | SPDX | Что это |
|---|---|---|---|
| `/` (по умолчанию для всего, что не отмечено ниже) | GNU AGPL v3 | `AGPL-3.0-only` | копилефт, сетевая оговорка §13 |
| `qeli/` (Rust-ядро + сервер + realtls-FFI) | GNU AGPL v3 | `AGPL-3.0-only` | ядро протокола и серверная часть |
| `qeli-android/` | MPL 2.0 | `MPL-2.0` | исходники Android-клиента (UI/glue) |
| `qeli-win/` | MPL 2.0 | `MPL-2.0` | исходники Windows-клиента (UI/glue) |
| `qeli-mac/` | MPL 2.0 | `MPL-2.0` | исходники macOS-клиента (UI/glue) |
| `qeli-ios/` | MPL 2.0 | `MPL-2.0` | исходники iOS-клиента (UI/glue) |
| `native-libs/third-party/` | по upstream | — | сторонние бинари (напр. Wintun) под их лицензиями |

Тексты: корень и `qeli/` — `LICENSE` (AGPL-3.0); каждый клиентский каталог — свой
`LICENSE` (MPL-2.0).

> **Не отмечены отдельно, поэтому наследуют корневой AGPL-3.0:** `qeli-shared/` (общее
> C#-ядро, на которое ссылаются MPL-клиенты Windows и macOS) и `qeli-openwrt/`. Своего
> файла `LICENSE` у них нет. Если для них задумывалась MPL, как у остальных клиентских
> каталогов, нужно положить туда `LICENSE` и добавить строку в таблицу — до этого
> действует правило по умолчанию.

## Важно: общее нативное ядро (FFI) и его влияние на клиенты

Все клиенты бандлят нативную библиотеку **`libqeli`** (`libqeli.so` / `qeli.dll` /
`libqeli.dylib`), собранную из кода `qeli/` под **AGPL-3.0**. Поэтому:

- **Исходники клиента** (UI/платформенный glue в `qeli-*/`) — под **MPL-2.0**: их можно
  переиспользовать пермиссивно, например со СВОИМ backend, **без** ядра `qeli`.
- **Распространяемое приложение целиком** (клиент **вместе с** бандленым `libqeli`)
  для третьих лиц является производной от AGPL-кода и распространяется на условиях
  **AGPL-3.0**. MPL на клиентских исходниках этого не отменяет.

То есть MPL даёт ценность «переиспользуй UI отдельно», но «возьми наш клиент с нашим
ядром и закрой» — нельзя (это AGPL).

## Копирайт и вклады

Правообладатель — владелец репозитория; он сохраняет права на собственный код и
вправе выпускать официальные сборки и **отдельные закрытые компоненты** (например
коммерческий control-plane — это его собственный код, не производный от вкладов).

**Вклады принимаются по модели DCO, без CLA** (см. [CONTRIBUTING.md](CONTRIBUTING.md)):
каждый вклад входит под лицензией своего каталога (AGPL-3.0 для `qeli/`, MPL-2.0 для
клиентов) — «inbound = outbound». Авторские права контрибьюторы сохраняют за собой.

Монетизация не требует продажи ядра под проприетарной лицензией (см. модель: хостинг +
отдельный закрытый control-plane + поддержка), поэтому **двойное лицензирование ядра
не ведётся и CLA не нужен**. Если когда-нибудь понадобится продавать само ядро под
закрытой лицензией — это потребует согласия всех контрибьюторов либо введения CLA на
тот момент (ретроактивно сложнее).

## Сторонние зависимости

Rust-крейты (rustls/ring/ml-kem/…), .NET-пакеты (Avalonia, SkiaSharp, BouncyCastle,
QRCoder, …), Kotlin/Android-библиотеки — каждая под СВОЕЙ лицензией (преим.
MIT/Apache-2.0/ISC). **Автоматической проверки лицензий в CI сегодня нет:** джоба
`security-audit` гоняет `cargo audit`, а это база уязвимостей RUSTSEC, не лицензии;
`cargo-deny`/`cargo-about` в дереве не заведены. Совместимость проверяется вручную при
добавлении зависимости. Завести `cargo deny check licenses` — открытая задача.
Сторонние нативные бинари (Wintun и пр.) — в `native-libs/third-party/` под upstream.

## SPDX-заголовки (план)

При следующем проходе рекомендуется добавить в каждый файл строку
`SPDX-License-Identifier: AGPL-3.0-only` (в `qeli/`) или `MPL-2.0` (в клиентах) и
принять стандарт **REUSE** (`reuse lint` в CI) для машиночитаемой проверки. Выбор
`-only` против `-or-later` для AGPL — на усмотрение правообладателя (FSF рекомендует
`-or-later`; `-only` даёт больше контроля).