Двойное (множественное) лицензирование

Зачем давать одному коду несколько лицензий

Правообладатель может одновременно разрешить использование одного и того же кода на нескольких условиях. Получатель выбирает одну из них и соблюдает её условия. Цели у этого в основном две.

1. Расширить совместимость — чтобы код подходил к разным экосистемам.
2. Бизнес-модель — публиковать код как открытый и при этом продавать отдельные коммерческие лицензии.

Тип 1: две разрешительные лицензии вместе — MIT OR Apache-2.0

Так делают язык Rust и большинство крейтов Rust. Пользователь выбирает удобную: MIT или Apache-2.0.

• Выбравший Apache-2.0 получает явную патентную лицензию.
• Выбравший MIT может включить код и в проекты под GPL-2.0-only (поскольку FSF считает Apache-2.0 несовместимой с GPL-2.0).

Получаются оба преимущества сразу, поэтому модель популярна у авторов библиотек. В репозитории по традиции кладут два файла: LICENSE-MIT и LICENSE-APACHE.

Тип 2: копилефт + коммерческая — «GPL или платите»

Код публикуется под GPL или AGPL, а компаниям, которые не хотят брать на себя обязанность раскрытия исходников, продаётся коммерческая лицензия по отдельному договору. Типичные примеры — MySQL (GPL + коммерческая лицензия Oracle) и Qt (LGPL-3.0/GPL + коммерческая).

Эта модель работает, только если правообладателю принадлежат права на весь код. На код, который внешние участники внесли только под GPL, у правообладателя нет права продавать коммерческую лицензию.

CLA и DCO

• CLA (соглашение участника о лицензии): договор, по которому участник предоставляет владельцу проекта широкие права на свой вклад (включая перелицензирование) или передаёт авторское право. Для коммерческого двойного лицензирования практически необходим. Бывают и формы вроде ICLA фонда Apache, которые дают только право на перелицензирование, оставляя авторское право у участника.
• DCO (Developer Certificate of Origin): участник в каждом коммите подтверждает, что вправе представить этот код под лицензией проекта (git commit -s добавляет строку Signed-off-by:). Его использует ядро Linux. DCO не даёт права на перелицензирование, поэтому для коммерческого двойного лицензирования его недостаточно.

Запись выражениями SPDX

Отношения между несколькими лицензиями записываются выражениями лицензий SPDX.

Если перепутать OR и AND, смысл станет противоположным. Если пользователь может выбирать — OR, если нужно соблюдать всё — AND.

На что обратить внимание

• Уже полученные права сохраняются: даже если позже оставить только коммерческую лицензию, разрешения для версий, ранее распространённых как открытые, как правило, остаются в силе.
• Это не «open core»: модель, где ядро открыто, а дополнительные функции продаются как закрытые коммерческие, — не двойное лицензирование. Двойное лицензирование — это две лицензии на один и тот же код.
• Не путайте с лицензиями с доступным исходным кодом: всё чаще проекты переходят на лицензии вроде BUSL или SSPL, при которых исходники видны, но по критериям OSI ПО не является открытым. Это иная стратегия, чем двойное лицензирование.
• Точно оформляйте файлы уведомлений: при выборе предоставляйте полные тексты всех лицензий и ясно указывайте в README, что можно выбрать одну из них.

Пример применения

Чтобы применить двойное лицензирование в стиле Rust, скачайте в генераторе файлы MIT и Apache-2.0, сохраните их как LICENSE-MIT и LICENSE-APACHE и укажите в метаданных license = "MIT OR Apache-2.0". В заголовке каждого файла пишите SPDX-License-Identifier: MIT OR Apache-2.0.

Эта статья содержит общую информацию и не является юридической консультацией. Важные решения обсуждайте со специалистами.

Источники

• SPDX Specification, License Expressions — https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
• Rust API Guidelines, Licensing — https://rust-lang.github.io/api-guidelines/necessities.html
• Developer Certificate of Origin — https://developercertificate.org/
• Apache ICLA — https://www.apache.org/licenses/contributor-agreements.html