Введение
Двойное (или dual) лицензирование — модель, при которой один и тот же программный продукт (или его существенная часть) распространяется одновременно на двух (или более) различных лицензионных условиях. Классический вариант: бесплатная (или условно-бесплатная) версия под открытой лицензией (часто copyleft, например GPL) + платная коммерческая лицензия с более широкими правами использования, отсутствием copyleft-ограничений и возможностью встраивания в закрытые продукты.
Суть модели проста: один и тот же продукт (или его существенная часть) распространяется одновременно на двух различных условиях. Чаще всего это:
- бесплатная (или условно-бесплатная) версия под открытой лицензией (GPL, AGPL, MPL и т.п.);
- платная коммерческая лицензия с расширенными правами, отсутствием copyleft-ограничений, гарантией и поддержкой.
Модель успешно работает по всему миру уже более 20 лет (классические примеры — MySQL, Qt, ранее MongoDB). В России она полностью соответствует Гражданскому кодексу и становится особенно актуальной после изменений 2025–2026 годов, связанных с реестром российского ПО, налоговыми льготами и требованиями к локализации.
В условиях активного импортозамещения, ужесточения требований к российскому программному обеспечению и роста интереса к open source-моделям всё больше IT-компаний ищут способы совместить открытость кода с коммерческой выгодой. Одним из самых эффективных инструментов для этого является двойное лицензирование (dual licensing).
Материал ориентирован на руководителей IT-компаний, product-менеджеров, юристов in-house и разработчиков, которые хотят выстроить устойчивую лицензионную модель.
Что такое двойное лицензирование и чем оно отличается от других моделей
Эта модель широко используется в мировой практике (MySQL, Qt, MongoDB в определённые периоды, многие библиотеки и СУБД) и полностью укладывается в российское законодательство. Правообладатель, обладая исключительным правом на программу для ЭВМ (ст. 1261, 1229 ГК РФ), вправе распоряжаться им по своему усмотрению, в том числе предоставлять права использования разным лицам на разных условиях (ст. 1233, 1235 ГК РФ).
Ниже — подробный разбор: почему это законно, в каких случаях целесообразно, как правильно оформить, какие изменения законодательства нужно учитывать и типичные ошибки.
Правовые основы двойного лицензирования по ГК РФ
Программа для ЭВМ охраняется как объект авторского права (ст. 1261 ГК РФ). Исключительное право принадлежит правообладателю и включает право использовать программу любыми способами и распоряжаться этим правом (ст. 1229 ГК РФ).
Ключевой инструмент — лицензионный договор (ст. 1235 ГК РФ):
- Лицензиар предоставляет лицензиату право использования в определённых пределах.
- Существенные условия: предмет (конкретная программа/версия), способы использования, территория, срок, вознаграждение (или указание на безвозмездность).
- Вид лицензии (ст. 1236 ГК РФ):
- Простая (неисключительная) — правообладатель сохраняет право выдавать аналогичные лицензии другим лицам.
- Исключительная — правообладатель не вправе выдавать аналогичные лицензии третьим лицам в пределах, указанных в договоре (и по п. 1.1 ст. 1236 ГК РФ обычно не вправе сам использовать в этих пределах, если иное не предусмотрено договором).
Поскольку по умолчанию лицензия считается неисключительной (п. 2 ст. 1236 ГК РФ), правообладатель может параллельно выдавать множество неисключительных лицензий на разных условиях. Именно это и лежит в основе dual licensing.
Открытые лицензии прямо признаны в российском праве (ст. 1286.1 ГК РФ). Акцепт происходит путём начала использования программы на условиях, изложенных правообладателем. Это позволяет без подписания отдельного договора с каждым пользователем распространять ПО под GPL, MIT, Apache 2.0 и т.п.
Таким образом, правообладатель может:
- Опубликовать код/программу под открытой лицензией (публичная оферта).
- Параллельно заключать индивидуальные коммерческие лицензионные договоры с теми, кому нужны более широкие права (отсутствие обязанности раскрывать производные работы, коммерческое использование без ограничений copyleft, сублицензирование, модификация без обязательств и т.д.).
Ограничений на количество и виды лицензий на один объект законодательство не содержит. Можно лицензировать одновременно ПО + ноу-хау, несколько версий или компоненты.
Важные нюансы 2025–2026 годов:
- Компенсация за нарушение исключительных прав на ПО (ст. 1301 ГК РФ) — от 10 тыс. до 5 млн руб. (с учётом изменений 2025 г.).
- Льгота по НДС (пп. 26 п. 2 ст. 149 НК РФ) применяется только к ПО, включённому в Единый реестр российского ПО. Иностранное или не включённое ПО облагается НДС.
- Требования к реестру российского ПО ужесточились (Постановление Правительства № 1236 с изменениями, в т.ч. 2025 г.): подтверждение исключительных прав российского правообладателя, ограничения на выплаты иностранным лицам (как правило, не более 30 % выручки), совместимость с российскими ОС, хранение кода в РФ и др.
- Для open source-компонентов важно отсутствие ограничений на распространение на всей территории РФ и чёткое подтверждение прав.
Двойное лицензирование хорошо сочетается с реестром: коммерческая версия может быть зарегистрирована как российское ПО, а открытая — привлекать сообщество и снижать барьер входа.
Почему двойное лицензирование выгодно и законно
Преимущества для правообладателя:
- Монетизация open source-сообщества без потери контроля.
- Бесплатная версия привлекает пользователей, разработчиков и тестировщиков; коммерческая — генерирует выручку от тех, кому нужны enterprise-функции, поддержка, отсутствие copyleft или возможность закрытого использования.
- Гибкость: можно предлагать разные тарифы (по количеству пользователей, серверов, функционалу, уровню поддержки).
- Снижение рисков «утечки» кода: copyleft-версия защищает от недобросовестного коммерческого использования без оплаты.
- Совместимость с требованиями импортозамещения и реестра Минцифры.
Для лицензиата (пользователя):
- Бесплатная версия — для изучения, некоммерческих проектов, тестирования.
- Коммерческая — юридическая чистота, гарантии, расширенные права, SLA.
Модель полностью соответствует принципу свободы договора (ст. 421 ГК РФ) и диспозитивности норм об интеллектуальной собственности.
В каких случаях применять двойное лицензирование
| Ситуация | Рекомендуемая модель | Почему | |
|---|---|---|---|
| Библиотека / фреймворк / СУБД / middleware | Open source (GPL/AGPL) + коммерческая | Copyleft защищает от конкурентов, коммерческая — для встраивания в закрытые продукты | |
| SaaS / облачный сервис | Source-available или dual + коммерческая подписка | Контроль над серверной частью + монетизация поддержки и расширенных функций | |
| Корпоративное / отраслевое ПО | Проприетарная + ограниченная open source (community edition) | Community привлекает, enterprise продаётся | |
| Продукт для госзакупок / КИИ | Коммерческая (с включением в реестр) + открытая для разработчиков | Соответствие требованиям + сообщество | |
| Стартап на этапе роста | Dual с акцентом на коммерческую | Быстрый охват + выручка | |
| Проект с большим количеством контрибьюторов | Dual + Contributor License Agreement (CLA) | Чёткие права на вклады |
Когда не стоит:
- Если вы планируете полностью передать исключительные права (лучше договор отчуждения).
- Если продукт полностью закрытый и не нуждается в сообществе.
- При сильной зависимости от иностранного open source с несовместимыми лицензиями (риск для реестра).
Как правильно оформить двойное лицензирование
Шаг 1. Закрепить исключительные права
- Договоры с разработчиками (служебное произведение или отчуждение/исключительная лицензия).
- Регистрация в Роспатенте (добровольно, но усиливает позицию) — услуга Solu.
- CLA для внешних контрибьюторов.
Шаг 2. Выбрать пару лицензий
Типичные сочетания:
- GPL v2/v3 / AGPL + коммерческая проприетарная.
- Mozilla Public License / LGPL + коммерческая.
- Реже: MIT/Apache (разрешительные) + коммерческая с дополнительными гарантиями/поддержкой.
Коммерческая лицензия должна быть письменной (ст. 1235 ГК РФ). Открытая — через ст. 1286.1.
Шаг 3. Подготовить тексты
- Публичная открытая лицензия (на сайте, в репозитории, в дистрибутиве).
- Типовой или индивидуальный коммерческий лицензионный договор с чётким описанием способов использования, запретов, территории (РФ или шире), срока, вознаграждения, ответственности, сублицензирования.
- Разграничение версий (Community / Enterprise / Professional).
Шаг 4. Технические и организационные меры
- Разные сборки / репозитории / ключи активации.
- Чёткое указание, какая лицензия применяется к какой версии.
- Учёт в договорах с клиентами: «Право использования предоставляется на условиях коммерческой лицензии №…, а не открытой».
Шаг 5. Налоги и реестр
- Для льготы по НДС — включение коммерческой версии в реестр российского ПО (услуга Solu).
- Контроль выплат иностранным правообладателям компонентов.
- Документирование прав на все зависимости.
Рекомендуется проводить юридический аудит лицензионной модели перед масштабированием (аудит IT-продукта).
Примеры из практики
Пример 1. Классический dual (по аналогии с MySQL / Qt)
Компания выпускает СУБД. Community-версия под GPL — любой может использовать, но обязан открывать исходный код производных работ. Enterprise-версия — коммерческая неисключительная лицензия без copyleft, с правом закрытого использования, поддержкой 24/7 и дополнительными модулями. Правообладатель сохраняет возможность выдавать обе.
Пример 2. Российский разработчик библиотеки
Библиотека для работы с данными распространяется под Apache 2.0 (разрешительная). Параллельно предлагается коммерческая лицензия с гарантией, приоритетной поддержкой и правом на модификации без уведомления. Это снижает барьер входа и генерирует выручку от крупных клиентов.
Пример 3. SaaS-продукт
Основной код под source-available лицензией (можно смотреть, но нельзя запускать конкурентный сервис). Клиенты покупают подписку (лицензия на использование + услуги). При необходимости предоставляется on-premise версия под коммерческой лицензией.
Пример 4. Подготовка к реестру
Разработчик использует dual-модель. Коммерческая версия включается в реестр Минцифры как российское ПО. Открытая версия привлекает разработчиков и позволяет быстрее находить уязвимости. При этом все исключительные права подтверждены, иностранные компоненты — только permissive-лицензии в допустимых пределах.
Риски и как их минимизировать
| Риск | Описание | Минимизация | |
|---|---|---|---|
| Конфликт лицензий | Copyleft «заражает» коммерческую версию | Чёткое разделение кодовых баз / CLA / юридический аудит | |
| Потеря прав на вклады | Контрибьюторы сохраняют права | CLA или Contributor Assignment Agreement | |
| Проблемы с реестром | Иностранный контроль или выплаты более 30 % | Аудит цепочки прав, локализация | |
| НДС | ПО не в реестре | Регистрация в реестре Минцифры | |
| Судебные споры | Неясные условия использования | Письменные договоры, фиксация акцепта открытой лицензии | |
| Налоговые претензии | Неправильное отражение вознаграждения | Разделение лицензионных платежей и платежей за услуги |
Судебная практика в целом поддерживает свободу лицензирования при соблюдении существенных условий договора.
Связь с актуальными требованиями (2025–2026)
- Реестр российского ПО: dual licensing прямо упоминается как благоприятная конструкция, поскольку права остаются чёткими у российского правообладателя.
- Требования совместимости с российскими ОС, хранения кода в РФ, отсутствия иностранного контроля.
- Возможность патентования отдельных технических решений (изменения в ГК РФ, планируемые с 2027 г.) — дополнительный слой защиты поверх авторского права.
- Ужесточение контроля за open source-зависимостями при включении в реестр.
Практические рекомендации от юристов Solu
- Начните с аудита текущих прав и зависимостей.
- Выберите пару лицензий под бизнес-модель (не копируйте слепо западные примеры).
- Оформите все договоры с разработчиками и CLA.
- Подготовьте коммерческий шаблон и публичную открытую лицензию.
- Рассмотрите регистрацию в Роспатенте и включение в реестр Минцифры.
- Разделите в договорах лицензионные платежи и услуги (поддержка, внедрение) — это важно для НДС и учёта.
- Регулярно мониторьте изменения в Постановлении № 1236 и практике Минцифры.
Двойное лицензирование — мощный инструмент, который при грамотном юридическом оформлении позволяет совмещать преимущества open source и коммерческой модели, соответствовать требованиям российского регулирования и масштабировать бизнес.
Если вы разрабатываете или уже распространяете ПО и хотите выстроить или проверить лицензионную модель, специалисты Solu помогут провести аудит, подготовить договоры и сопроводить регистрацию.