Открытое программное обеспечение (open source) стало фундаментом современной разработки. По данным GitHub и других источников, лицензии MIT, Apache 2.0 и семейства GPL занимают лидирующие позиции среди используемых. Правильный выбор и соблюдение условий лицензии определяют, можно ли включать код в коммерческий продукт, нужно ли раскрывать исходники и как защищены патентные права.
Важно: материал носит информационный характер и не является юридической консультацией. Конкретные решения зависят от архитектуры продукта, способа распространения и юрисдикции. Рекомендуем обращаться к специалистам, в том числе юристам компании Solu (bettersolu.ru).
Лицензии делятся на две большие группы:
- Разрешительные (permissive) — MIT, Apache 2.0, BSD. Минимальные требования (в основном атрибуция), разрешают использование в закрытом (proprietary) ПО.
- Копилефт (copyleft) — GPL, AGPL, LGPL. Требуют сохранения «свобод» при распространении производных работ (в разной степени «вирусности»).
Официальные тексты и статус одобрения Open Source Initiative (OSI) доступны на opensource.org.
1. MIT License — максимально простая и разрешительная
История и популярность. Возникла в Массачусетском технологическом институте в конце 1980-х. Одна из самых коротких и популярных лицензий (часто №1 на GitHub). Используется в React, Node.js, jQuery, Ruby on Rails, Angular, .NET Core и тысячах библиотек.
Что даёт (права):
Свободно использовать, копировать, изменять, объединять, публиковать, распространять, сублицензировать и продавать копии ПО (и разрешать это другим). Коммерческое использование, закрытый исходный код производных работ — полностью разрешены. Нет требования открывать свои изменения.
Единственное условие:
Включить оригинальное уведомление об авторском праве и текст лицензии во все копии или существенные части ПО (включая бинарники и документацию).
Ограничения:
ПО предоставляется «как есть» (AS IS). Нет никаких гарантий, авторы не несут ответственности.
Тонкие моменты:
- Нет явного патентного гранта. Теоретически контрибьютор может позже предъявить патентные претензии (хотя на практике риск ниже, чем кажется).
- Высокая совместимость: код под MIT можно включать почти куда угодно, включая GPL-проекты и проприетарное ПО.
- «Substantial portions» — важная формулировка: мелкие фрагменты иногда не требуют полного описания, но безопаснее всегда включать.
- Варианты: классический MIT (Expat), MIT-0 (без атрибуции), X11 и др. Используйте SPDX-идентификатор MIT.
Для бизнеса: Идеальна для библиотек, где нужна максимальная adoption. Риск низкий при правильной атрибуции (LICENSE-файл, About, документация, SBOM).
Официальный текст лицензии: opensource.org/licenses/MIT или choosealicense.com.
2. Apache License 2.0 — разрешительная с патентной защитой
История. Разработана Apache Software Foundation, версия 2.0 утверждена в 2004 году. Стандарт для многих корпоративных и foundation-проектов (Android-компоненты, Kubernetes и др.).
Что даёт:
Широкие права на воспроизведение, создание производных работ, публичный показ/исполнение, сублицензирование и распространение в исходной и объектной форме. Коммерческое и проприетарное использование разрешено.
Ключевые особенности (отличия от MIT):
- Явный патентный грант (раздел 3): каждый контрибьютор предоставляет бессрочную, всемирную, безвозмездную, безотзывную (с оговоркой) патентную лицензию на патентные требования, которые необходимо нарушаются его вкладом (или комбинацией вклада с Work).
- Патентная реталиация (termination): если вы инициируете патентный иск против Work или Contribution, ваш патентный грант прекращается.
- Требования при распространении: копия лицензии; сохранение notices; указание изменений в изменённых файлах; сохранение NOTICE-файла (если есть) с атрибуцией.
- Явно не предоставляются права на товарные знаки.
- Определения Contribution, Derivative Works и т.д. делают лицензию более «юридически проработанной».
Тонкие моменты:
- Длиннее MIT, но даёт больше определённости компаниям.
- Совместима с GPLv3 (можно включать Apache 2.0 код в GPLv3-проект; комбинация становится GPLv3). Несовместима с «GPLv2 only».
- NOTICE-файл — удобный централизованный способ атрибуции.
- Подходит, когда важны патенты (особенно в hardware-связанном или крупном корпоративном коде).
Для бизнеса: Предпочтительнее MIT при наличии патентных рисков или для enterprise-аудитории. Атрибуция чуть сложнее (NOTICE + указание изменений), но управляема.
Официальный текст лицензии: apache.org/licenses/LICENSE-2.0.
3. GNU General Public License (GPL) — сильный copyleft
История. Создана Free Software Foundation (Ричард Столлман). GPLv2 — 1991, GPLv3 — 2007. Используется в Linux kernel (в основном v2), GCC, WordPress (часто «v2 or later»), многих GNU-проектах.
Основная идея (copyleft): свободы пользователей сохраняются. При распространении (convey) производной работы или модифицированной версии вы обязаны предоставить исходный код под той же лицензией.
Права: использовать, изучать, изменять, распространять. Коммерческое использование разрешено (можно продавать), но с выполнением copyleft-условий.
Обязанности при распространении:
- Предоставить полный соответствующий исходный код (Corresponding Source).
- Сохранить notices, лицензию.
- Лицензировать всю работу (в случае сильного copyleft) под GPL.
GPLv2 vs GPLv3 — ключевые различия:
| Аспект | GPLv2 | GPLv3 |
|---|---|---|
| Патентный грант | 20 (фиксированно) | Явный (раздел 11) |
| Совместимость с Apache 2.0 | Нет | Да |
| Anti-tivoization (антитивоизация) | Нет | Да (Installation Information для User Products) |
| DRM / технические меры | Не регулирует явно | Ограничивает использование DRM против свобод |
| Termination / cure (Расторжение/исправления) | Более жёсткий | Есть период «исцеления» кода |
| Международность | Более US-centric (американоцентричный) | Улучшена |
| Совместимость версий | «v2 only» несовместима с v3 | «or later» позволяет |
Тонкие моменты GPL:
- Триггер — распространение (distribution / convey), а не просто использование или внутреннее применение. SaaS без передачи копии обычно не запускает GPLv2/v3 (но запускает AGPL).
- Сильный copyleft: затрагивает производные работы и часто статическое/динамическое линкование (интерпретации различаются, особенно в судах).
- Linux kernel остаётся в основном на GPLv2 only — это создаёт известные ограничения.
- LGPL — слабый copyleft (для библиотек): позволяет линкование с проприетарным кодом при определённых условиях.
- AGPLv3 добавляет network use trigger — критично для SaaS.
- «or any later version» — распространённая практика, даёт гибкость.
- Нарушение может привести к автоматическому прекращению прав (с возможностью восстановления в v3).
Для бизнеса: Высокий риск для закрытых продуктов. Если код распространяется (включая embedded, клиентские приложения), может потребоваться раскрытие всего производного. Часто «красный флаг» при due diligence инвесторов. Внутреннее использование обычно безопасно.
Официальный тексты лицензии и FAQ: gnu.org/licenses.
Сравнительная таблица
| Характеристика | MIT | Apache 2.0 | GPL (v2/v3) |
|---|---|---|---|
| Тип | Разрешительная | Разрешительная | Сильный copyleft |
| Коммерческое / проприетарное использование | Да | Да | Да, но с copyleft |
| Требование открывать исходники производных | Нет | Нет | Да (при распространении) |
| Явный патентный грант | Нет | Да + retaliation | Да в v3 |
| Атрибуция | Copyright + license | License + NOTICE + changes | License + notices + source |
| Совместимость | Очень высокая | Высокая (с GPLv3) | Ограниченная |
| Длина / сложность | Очень короткая | Средняя | Длинная |
| Типичное применение | Библиотеки, max adoption | Enterprise, патенты | Сохранение свободы ПО |
| Риск для закрытого продукта | Низкий | Низкий | Высокий |
Совместимость лицензий
- MIT → почти всё (включая Apache, GPL, проприетарное).
- Apache 2.0 → GPLv3 (да), GPLv2 only (нет).
- GPL-код нельзя просто так включать в проприетарное или MIT/Apache-проект без выполнения copyleft.
- Комбинация разных copyleft часто проблематична.
Рекомендуется вести SBOM (Software Bill of Materials) и проверять транзитивные зависимости.
Практические рекомендации и риски для бизнеса
- Инвентаризация — используйте инструменты (FOSSA, Black Duck, ScanCode, GitHub Dependency Graph) + ручной аудит.
- Политика компании — запрет/ограничение сильного copyleft (GPL/AGPL) в распространяемых продуктах; предпочтение MIT/Apache.
- Атрибуция — централизованный NOTICE/LICENSE, About-диалоги, документация.
- Архитектура — изоляция (процессы, API, динамическая загрузка) иногда помогает с LGPL, но с GPL рискованно.
- SaaS — GPL обычно ок, AGPL — нет.
- Российский контекст — ст. 1286.1 ГК РФ признаёт открытые лицензии. Патентование кода ограничено, но международные патенты и иностранные правообладатели остаются релевантны. При реестре отечественного ПО и госзакупках учитывайте происхождение компонентов.
- Due diligence — инвесторы и покупатели проверяют OSS-комплаенс; нарушения GPL могут снижать оценку или блокировать сделку.
Типичные ошибки: игнорирование транзитивных зависимостей, отсутствие NOTICE при Apache, смешение «GPLv2 only» и Apache/GPLv3, использование AGPL в SaaS без понимания network clause.
Когда какую лицензию выбирать
- Максимальное распространение и простота → MIT.
- Корпоративная среда + патентная определённость → Apache 2.0.
- Защита свобод и обязательная открытость производных → GPLv3 (или AGPLv3 для сетевых сервисов).
- Библиотека с возможностью проприетарного использования → MIT / Apache / LGPL.
Заключение
MIT и Apache 2.0 дают максимальную гибкость для коммерческих продуктов при минимальных обязанностях. GPL защищает экосистему свободного ПО ценой более жёстких требований к производным работам. Выбор лицензии — это стратегическое решение, влияющее на архитектуру, бизнес-модель, привлечение инвестиций и юридические риски.
Юридическая компания Solu помогает проводить аудит open source зависимостей, разрабатывать лицензионные политики, готовить SBOM и сопровождать сделки с IT-активами. Обращайтесь на bettersolu.ru за консультацией.
Полезные ссылки:
Данная статья подготовлена с опорой на официальные тексты лицензий и общедоступные аналитические материалы. Актуальные формулировки всегда проверяйте по первоисточникам.