Как сравнить лицензии открытого кода для мобильного приложения: MIT, Apache и GPL
Сравнить лицензии открытого кода для мобильного приложения — значит разобраться, какие обязательства накладывает каждая из трёх основных лицензий (MIT, Apache 2.0, GPL) на разработчика коммерческого продукта.
Что разрешает и запрещает MIT, Apache 2.0 и GPL
MIT License
MIT — самая короткая и лояльная лицензия из трёх. Она разрешает использовать, изменять и распространять код без каких-либо ограничений, кроме одного: сохранить уведомление о авторских правах в исходном коде. Для мобильного приложения это означает, что вы можете взять библиотеку на MIT, встроить её в закрытое приложение и продавать без обязательства раскрывать исходный код.
Единственное требование — не удалять файл лицензии из дистрибутива. Всё остальное свободно.
Apache License 2.0
Apache 2.0 похожа на MIT, но добавляет несколько важных условий:
1. Необходимо сохранить уведомление о авторских правах во всех копиях кода.
2. При внесении изменений нужно явно указать, что вы модифицировали исходный файл.
3. Если файл содержит блок «NOTICE», его содержимое нужно включить в дистрибутив.
4. Вы не получаете права на использование товарных знаков авторов.
Ключевое отличие от MIT — патентная лицензия. Apache 2.0 явно предоставляет вам право использовать запатентованные технологии автора. Это значит, что автор не сможет подать на вас в суд за использование его кода в рамках лицензии. Для коммерческого продукта это существенная защита.
GNU General Public License (GPL v3)
GPL — самая жёсткая из трёх лицензий. Она требует, чтобы любой производный продукт распространялся под той же лицензией. Если вы включили GPL-компонент в мобильное приложение и распространяете его среди пользователей, вы обязаны предоставить исходный код всего приложения.
Для закрытого коммерческого продукта это означает одно: GPL-зависимость делает невозможным сохранение исходного кода в тайне. Существует также LGPL (Lesser GPL), которая допускает статическую линковку при условии, что пользователь сможет заменить LGPL-компонент на свою версию. Но LGPL — это отдельная лицензия со своими нюансами.
«The GNU General Public License is intended to guarantee your freedom to share and change all versions of a program — to make sure it remains free software for all its users.» — Free Software Foundation, gnu.org/licenses/gpl-3.0
Таблица проверки: обязательства каждой лицензии
| Параметр | MIT | Apache 2.0 | GPL v3 |
|---|---|---|---|
| Указание авторства | Сохранить файл LICENSE | Сохранить LICENSE + блок NOTICE | Сохранить файл LICENSE |
| Уведомление об изменениях | Не требуется | Обязательно указать модификации | Не требуется (но код открыт) |
| Патентная лицензия | Формально не предусмотрена | Явно предоставлена | Явно предоставлена |
| Распространение исходного кода | Не требуется | Не требуется | Обязательно для производных продуктов |
| Совместимость с закрытым кодом | Полная | Полная | Нет |
| Совместимость с Apache 2.0 | Да | — | Нет |
| Совместимость с MIT | — | Да | Нет |
Мы рекомендуем проверять каждую зависимость через инструменты автоматического анализа лицензий — например, FOSSA, License Finder или встроенные сканеры в Gradle (Android) и CocoaPods (iOS). По нашему опыту, именно пропущенные транзитивные зависимости становятся источником юридических проблем: библиотека A лицензирована под MIT, но внутри использует библиотеку B под GPL.
Также проверьте лицензию в файле LICENSE корневой директории библиотеки и в секции метаданных пакетного менеджера — pubspec.yaml для Flutter, build.gradle для Android, Podfile для iOS. Это стандартная процедура верификации, которая занимает несколько минут, но может предотвратить серьёзные юридические последствия.
Риски для коммерческого мобильного продукта
Несовместимость лицензий
Самый серьёзный риск — смешение лицензий с взаимоисключающими условиями. Если одна библиотека лицензирована под MIT, а другая — под GPL, и обе встроены в один модуль, GPL-требование может распространиться на весь продукт. В 2025 году суды в ряде юрисдикций начали рассматривать такие случаи как нарушение авторских прав, и штрафы могут достигать десятков тысяч долларов.
Патентные ловушки
MIT-лицензия не содержит явного патентного гранта. Если автор библиотеки обладает патентом на алгоритм, он теоретически может потребовать лицензионное вознаграждение. Apache 2.0 защищает от этого: патентная лицензия включена в текст документа. Проверьте, есть ли в репозитории библиотеки упоминание патентов — это можно найти в файле LICENSE или в документации проекта.
Нарушение требований уведомления
Каждая лицензия требует сохранить определённые уведомления. Если вы удалили файл LICENSE или блок NOTICE из дистрибутива, это нарушение, даже если код использован правильно. Проверьте, что сборочный скрипт (build pipeline) копирует все лицензионные файлы в финальный APK или IPA.
Влияние на оценку стартапа
Инвесторы и покупатели проверяют open-source зависимости во время due diligence. Наличие GPL-компонентов в закрытом продукте может снизить оценку или стать причиной отказа от сделки. Мы видели случаи, когда due diligence выявлял GPL-зависимости, и покупатель требовал полной замены перед закрытием сделки.
выбор мобильного приложения для бизнеса
Когда какая лицензия подходит
MIT — максимальная свобода
Выбирайте MIT, когда:
1. Нужна максимальная гибкость: код можно использовать в любом контексте без отчётов и уведомлений.
2. Патентный риск минимален — автор известный открытый проект без патентов.
3. Важна скорость интеграции: нет дополнительных требований к документации.
Apache 2.0 — защита для корпоративных проектов
Выбирайте Apache 2.0, когда:
1. Нужна патентная защита: вы хотите быть уверены, что автор не подаст в суд за использование кода.
2. Проект используется в корпоративной среде, где юристы требуют явных условий лицензирования.
3. Вы планируете вносить изменения и хотите, чтобы они были задокументированы в блоке NOTICE.
GPL — только для открытых проектов
GPL подходит, когда:
1. Ваш продукт и так является открытым — open-source приложение для сообщества.
2. Вы хотите, чтобы все производные продукты тоже были открытыми под GPL.
3. Вы строите экосистему вокруг открытого кода и хотите гарантировать свободу для разработчиков.
Что будет, если случайно использовать GPL-компонент в закрытом приложении?
Юридически это нарушение авторских прав автора GPL-библиотеки. На практике автор может потребовать прекратить распространение приложения или предоставить исходный код. В редких случаях это приводит к судебным искам, но чаще стороны договариваются о лицензировании или замене компонента.
Можно ли комбинировать MIT и Apache 2.0 в одном приложении?
Да, эти лицензии совместимы. Apache 2.0 совместима с MIT: код на MIT можно включать в Apache-проект без ограничений. Обратная совместимость тоже работает, но при добавлении Apache-кода в MIT-проект нужно соблюдать все условия Apache — включая уведомление об изменениях и блок NOTICE.
Как проверить лицензии всех зависимостей в проекте?
Используйте инструменты автоматического анализа: FOSSA, Snyk, Black Duck или встроенные сканеры в Gradle (для Android) и CocoaPods (для iOS). Регулярно запускайте проверку в CI/CD и перед каждым релизом. Особое внимание уделяйте транзитивным зависимостям — библиотекам, которые используют ваши библиотеки.
Проверка первоисточников
Где сверить правила и документы
Ссылки помогают быстро перейти от советов в статье к официальным реестрам, правилам или справочным сервисам. Перед оплатой или претензией сохраняйте дату проверки.