В современной разработке программного обеспечения практически невозможно обойтись без сторонних компонентов. Библиотеки, фреймворки, утилиты — большинство из них распространяются под open source-лицензиями. При этом многие компании до сих пор относятся к вопросу лицензирования формально: «раз бесплатно — можно брать». Такой подход часто приводит к серьёзным юридическим и бизнес-рискам: от претензий правообладателей до невозможности включить продукт в реестр российского ПО или продать его инвестору.
В этой статье разберём основные виды лицензий на программное обеспечение, подробно остановимся на open source-лицензиях, объясним, что они реально означают на практике, и расскажем, какие решения предлагает юридическая компания Solu.
Зачем вообще нужны лицензии на ПО
Программное обеспечение — это объект авторского права (ст. 1259, 1261 ГК РФ). По умолчанию все права принадлежат автору (или работодателю/заказчику, если права правильно оформлены). Лицензия — это разрешение правообладателя использовать программу определённым образом.
Лицензия решает несколько ключевых задач:
- Определяет, кто и как может использовать, копировать, изменять и распространять код.
- Защищает правообладателя от несанкционированного использования.
- Даёт пользователям понятные правила и снижает риски претензий.
- Позволяет коммерциализировать продукт (продавать лицензии, SaaS-доступ, подписки).
- Влияет на возможность включения ПО в Единый реестр российского ПО Минцифры и получения государственных преференций.
Без чёткой лицензионной модели продукт становится юридически уязвимым.
Основные виды лицензий на программное обеспечение
Все лицензии условно делятся на две большие группы:
1. Проприетарные (закрытые, proprietary) лицензии
Правообладатель сохраняет максимальный контроль. Пользователь получает только ограниченное право использования (часто без доступа к исходному коду). Типичные примеры — лицензионные договоры Microsoft, Oracle, большинства российских вендоров. Такие лицензии почти всегда платные и содержат жёсткие ограничения.
2. Open Source (открытые) лицензии
Дают широкие права на использование, изучение, изменение и распространение исходного кода. Однако «открытость» не означает отсутствие условий. Именно условия open source-лицензий чаще всего становятся источником проблем.
Open source-лицензии, в свою очередь, делятся на:
- Разрешительные (permissive) — минимальные требования.
- Копилефтные (copyleft) — требуют сохранения «открытости» производных работ.
Разрешительные лицензии (Permissive)
Это самые «дружелюбные» к коммерческому использованию лицензии.
MIT License
Одна из самых популярных и простых. Разрешает почти всё: использование в коммерческих продуктах, модификацию, закрытие кода. Единственное обязательное условие — сохранение уведомления об авторских правах и текста лицензии.
Apache License 2.0
Похожа на MIT, но более подробная. Содержит явную патентную лицензию (важно для проектов, где могут быть патенты), требует указания изменений и сохранения NOTICE-файла. Считается одной из самых безопасных для коммерческого использования.
BSD-лицензии (2-Clause и 3-Clause)
Близки к MIT. 3-Clause добавляет запрет использовать имена авторов для продвижения производных продуктов без разрешения.
Плюсы разрешительных лицензий:
Можно свободно включать в проприетарные продукты, не раскрывая свой код. Идеально подходят для большинства коммерческих проектов и подготовки к реестру российского ПО.
Минусы:
Практически не защищают от «присвоения» кода крупными игроками.
Копилефтные лицензии (Copyleft)
Главная идея копилефта — «свобода должна распространяться дальше». Если вы используете и распространяете код под такой лицензией, то и ваш производный продукт (или его часть) должен оставаться открытым на тех же условиях.
GNU General Public License (GPL v2 / v3)
Сильный копилефт. Если вы включаете GPL-код в свой продукт и распространяете его, весь продукт (или существенная часть) должен распространяться под GPL с предоставлением исходного кода. Это главный риск для коммерческих продуктов.
GNU Lesser General Public License (LGPL)
«Слабый» копилефт. Обычно применяется к библиотекам. Позволяет линковать LGPL-библиотеку с проприетарным кодом, не открывая весь продукт (при соблюдении определённых условий динамической линковки).
GNU Affero General Public License (AGPL)
Самый строгий вариант. Распространяет требования GPL даже на использование через сеть (SaaS, веб-сервисы). Если пользователь взаимодействует с модифицированной AGPL-программой через интернет, он должен получить доступ к исходному коду.
Mozilla Public License (MPL 2.0)
Файловый копилефт. Требует открывать только изменённые файлы, распространяемые под MPL. Более мягкий вариант.
Что это означает на практике для IT-компаний
Использование open source — это не просто «взял и подключил». Нужно понимать последствия:
- Риск «вирусного» заражения. GPL/AGPL-компонент может потребовать раскрытия исходного кода всего продукта.
- Проблемы с реестром российского ПО. Минцифры внимательно смотрит на происхождение компонентов и возможность контролировать развитие продукта. Сильные копилефтные лицензии и иностранные зависимости повышают риски отказа.
- Сложности при продаже компании или привлечении инвестиций. Полная проверка компании всегда включает аудит лицензий (Open Source Compliance / Software Composition Analysis).
- Претензии правообладателей. Даже если риск кажется низким, крупные проекты (или конкуренты) могут использовать нарушение лицензии как инструмент давления.
- Двойное лицензирование. Многие проекты (например, некоторые СУБД и библиотеки) предлагают open source + коммерческую лицензию. Нужно правильно выбрать и оформить.
Рекомендация: для коммерческих продуктов и проектов, которые планируют идти в реестр Минцифры, предпочтительнее разрешительные лицензии (MIT, Apache 2.0, BSD). Копилефтные компоненты требуют отдельного юридического и архитектурного анализа.
Какие варианты работы с лицензиями предлагает Solu
Юридическая компания Solu специализируется на IT-праве и сопровождении разработчиков программного обеспечения. Мы предлагаем комплексные решения:
1. Аудит open source-компонентов (Open Source Compliance Audit)
Полный анализ зависимостей проекта: какие библиотеки используются, под какими лицензиями, какие риски они несут для коммерциализации и включения в реестр российского ПО. Формируем SBOM (Software Bill of Materials) и карту рисков.
2. Разработка лицензионных договоров и пользовательских соглашений
- Простая (неисключительная) и исключительная лицензия
- SaaS-оферта / лицензионная оферта
- Корпоративные и OEM-лицензии
- Сублицензионные договоры
- Договоры с учётом требований маркетплейсов и иностранных юрисдикций
3. Разработка собственной лицензионной модели продукта
Помогаем выбрать и оформить:
- Полностью проприетарную модель
- Dual licensing (open source + коммерческая лицензия)
- Source-available (открытый исходный код) модели
- Кастомные лицензии под специфику продукта
4. Сопровождение при подготовке к реестру российского ПО
Анализируем состав компонентов на соответствие требованиям Минцифры, помогаем минимизировать риски, связанные с иностранными open source-зависимостями, готовим необходимые пояснения и документы.
5. Оформление прав внутри команды и с подрядчиками
Договоры с разработчиками, CLA (Contributor License Agreement), трудовые договоры и ГПХ с чётким закреплением исключительных прав на код.
6. Сопровождение споров и претензий
Если уже возникли вопросы по использованию чужого кода или ваши права нарушены — помогаем выстроить защиту.
Мы не просто пишем документы «по шаблону». Каждый проект анализируем с точки зрения бизнес-модели, планов по монетизации, выхода на госзаказ и международных рынков.
Заключение
Лицензии на программное обеспечение — это не формальность, а инструмент управления рисками и активами компании. Особенно критично это в условиях активного использования open source и требований реестра российского ПО.
Правильный выбор и оформление лицензионной модели позволяет:
- спокойно развивать и продавать продукт
- проходить due diligence инвесторов
- минимизировать юридические риски
- успешно включать ПО в реестр Минцифры
Если вы разрабатываете коммерческое ПО, используете open source-компоненты или готовитесь к регистрации в реестре Минцифры — обратитесь в Solu. Мы проведём аудит, поможем выбрать оптимальную модель и подготовим все необходимые документы.