MIT, Apache и GPL: отличия лицензий и коммерческое использование
Что разрешают MIT, Apache-2.0 и GPLv3, какие уведомления сохранять и почему лицензии кода, моделей и данных нужно проверять отдельно.
Лицензии MIT, Apache-2.0 и GPL разрешают коммерческое использование программ, но устанавливают разные условия. MIT и Apache-2.0 относят к разрешительным лицензиям: при соблюдении условий они позволяют распространять производные программы без обязательного раскрытия их исходного кода. GPL использует copyleft: при передаче охватываемой лицензией программы возникают обязательства по сохранению соответствующих прав получателей и предоставлению исходного кода предусмотренным способом.
Поэтому вопрос «можно ли использовать проект с GitHub коммерчески» нужно уточнить. Запуск программы внутри компании, включение библиотеки в распространяемое приложение и предоставление сервиса через сеть представляют разные ситуации. Начните с конкретной версии лицензии и действий, которые вы собираетесь выполнять.
Папки с документами и USB-накопитель на столе.
Где найти условия именно вашей версии
Откройте файл LICENSE, COPYING или аналогичный документ в выбранном теге, метке версии, или коммите, зафиксированном состоянии репозитория. Сопоставьте его с уведомлениями в исходных файлах, файлом уведомлений NOTICE, документацией и списком сторонних компонентов. Значок лицензии на главной странице репозитория помогает сориентироваться, но не заменяет чтение применимых текстов.
Зафиксируйте адрес репозитория, версию, дату проверки и точный идентификатор лицензии. Например, записи GPL-2.0-only и GPL-2.0-or-later задают разные условия выбора версии. Слово «GPL» без номера не решает этот вопрос. Если у компонента есть исключение или альтернативная коммерческая лицензия, сохраните соответствующий документ вместе с основным текстом.
Публичный репозиторий без лицензии не означает свободное разрешение на любое использование. GitHub отдельно объясняет, что при отсутствии лицензии действуют обычные правила авторского права, хотя условия платформы предусматривают просмотр и создание копии репозитория (fork) средствами самой платформы. Документация GitHub разграничивает эти ситуации.
Практически удобно хранить карточку компонента рядом со сборкой. Тогда после обновления зависимости видно, изменились ли условия. Проверка только последней версии на сайте не подтверждает лицензию старого файла готовой программы из вашего продукта.
Схема: версия, действие и обязательства получателя.
MIT: широкие разрешения и сохранение уведомлений
Текст MIT разрешает использование, копирование, изменение, распространение и продажу при соблюдении условия о сохранении уведомления об авторском праве и текста разрешения в копиях либо существенных частях программы. Лицензия также содержит отказ от гарантий и ограничение ответственности.
Для типового процесса это означает, что нельзя удалить лицензионное уведомление только потому, что библиотека небольшая или включена в сборку автоматически. Разместите требуемую информацию в составе дистрибутива, пакета для установки или распространения, либо другом подходящем месте, которое действительно получает пользователь. Способ упаковки должен соответствовать конкретному продукту и тексту условия.
Не переносите разрешение на код на логотип, фотографии или данные автоматически. Они способны иметь собственные условия, даже если лежат в том же репозитории. Разрешительная лицензия одного файла не служит общим разрешением для всех объектов проекта.
Apache-2.0: уведомления, изменения и патентные условия
Apache License 2.0 содержит разрешения на использование и распространение, а также отдельное разрешение на использование определённых патентов участников, с указанными в тексте границами и условиями прекращения. При распространении программы или производной работы, в виде исходного кода или готовой сборки, получатель должен получить копию Apache-2.0. Изменённые файлы нужно явно пометить, а применимые уведомления сохранять в объёме и форме, предусмотренных разделом 4 лицензии. Если исходная поставка содержит NOTICE, применимые атрибуционные уведомления из него также нужно сохранить предусмотренным способом.
Проверка обычно затрагивает больше одного файла. Помимо LICENSE посмотрите NOTICE и сообщения об авторстве в исходниках. Если сборочная система убирает служебные файлы из итогового пакета, добавьте соответствующий шаг упаковки. Тестировать нужно конечный архив или установщик, а не только состояние исходного репозитория.
Apache-2.0 не выдаёт общего права использовать товарные знаки правообладателя. Поэтому разрешённое изменение и распространение кода не означает возможность представить собственный продукт как официальный выпуск исходной организации.
GPL: почему важен способ передачи программы
GPL не запрещает продажу программ. Основной вопрос заключается в условиях передачи охватываемых лицензией копий и связанных с ними исходников. В оригинальном тексте GPLv3 описаны способы передачи исходного кода и объектной, то есть неисходной, формы программы. Термин Corresponding Source обозначает соответствующие исходники и материалы для сборки, установки и работы программы с оговорёнными в лицензии исключениями. Для определённых пользовательских устройств действуют дополнительные условия.
Не сокращайте эти требования до фразы «положить ссылку на GitHub». Важно, какой именно исходный код соответствует переданному бинарному файлу, как получатель его получает и выполнены ли условия выбранного способа распространения. Отдельно оцените изменения, сценарий объединения компонентов и применимые исключения.
Использование и изменение программы внутри организации обычно не равнозначны её передаче третьим лицам. GNU FAQ поясняет, что GPL не обязывает публиковать каждую частную модификацию всему интернету. В то же время распространение изменённой программы создаёт соответствующие обязательства перед получателями. Разъяснения GNU полезны для понимания этой границы.
Сравнение лицензий для первичной проверки
Таблица помогает определить следующий документ для чтения. Она не заменяет полный текст лицензии и анализ состава вашей программы.
| Вопрос | MIT | Apache-2.0 | GPLv3 |
|---|---|---|---|
| Допускает коммерческое использование | Да, с условиями лицензии | Да, с условиями лицензии | Да, с условиями лицензии |
| Требует сохранить предусмотренные уведомления | Да | Да, включая применимые NOTICE | Да |
| Содержит отдельный патентный раздел | Нет отдельного раздела в тексте MIT | Да | Да |
| Требует обозначать изменения предусмотренным способом | Нет отдельного требования отмечать изменения | Да | Да, для охватываемых изменённых версий |
| Создаёт copyleft-обязательства при передаче охватываемой работы | Нет | Нет | Да |
Совместимость лицензий проверяют для конкретного сочетания и способа включения. Нельзя считать любые две открытые лицензии совместимыми только из-за слова open source. Также нельзя утверждать, что запуск отдельной GPL-программы автоматически меняет лицензию всех файлов на компьютере.
Open source и source available: отличия
Открытый просмотр исходного кода описывает доступность текста программы. Open source, открытое программное обеспечение в определении организации Open Source Initiative (OSI), включает требования к разрешённому распространению, изменениям и другим свободам. Например, ограничение применения только некоммерческими задачами не соответствует принципу отсутствия дискриминации по сфере деятельности. Определение OSI перечисляет применимые критерии.
Source available часто обозначает проекты, исходники которых доступны, но права использования ограничены особыми условиями. Поэтому не заменяйте чтение лицензии вопросом «код открыт?». Ищите ограничения на предоставление сетевого сервиса, число пользователей, виды бизнеса, перераспространение и передачу производных материалов.
Для проекта искусственного интеллекта дополнительно разделите код запуска, веса модели (её обученные параметры), набор данных, демонстрационные изображения и внешние программные интерфейсы (API). У каждого элемента бывают собственные условия. Разрешение продавать приложение не отвечает автоматически на вопрос о допустимости обучения модели на конкретных данных.
Практическая карточка перед внедрением
Запишите компонент и точную версию. Затем опишите действие: только запуск, изменение, включение в приложение, передача клиенту или сетевой сервис. После этого перечислите получателей копий и форму поставки. Это помогает увидеть обязательства, которые теряются в общей формулировке «используем библиотеку».
Далее сохраните тексты лицензий и уведомлений. Определите, куда они попадут в готовой поставке. Для copyleft-компонентов проверьте требования к исходникам и установочной информации, если соответствующие положения применимы. Для сетевого сервиса отдельно различайте GPL и AGPLv3. Если вы изменили программу под AGPLv3, её версия должна явно предложить взаимодействующим с ней по сети пользователям бесплатный доступ к соответствующим исходникам. Это предусмотрено разделом 13 AGPLv3.
В сложном случае подготовьте для юридической проверки конкретную архитектуру и способ передачи. Вопрос «разрешена ли GPL» не содержит достаточно данных. Вопрос с перечнем компонентов, схемой взаимодействия и описанием поставки позволяет получить применимый ответ и зафиксировать решение.
Частые вопросы
Бесплатный проект разрешено продавать в составе продукта?
Цена исходного проекта не определяет ваши права. Ответ задают лицензии включённых компонентов и соблюдение их условий. MIT, Apache-2.0 и GPL допускают коммерческие сценарии, но обязательства различаются.
Для GPL всегда требуется выложить исходники всему интернету?
Такое обобщение неверно. Существенны передача копий, выбранный способ предоставления исходников и круг получателей по условиям лицензии. Частное изменение и использование требуют отдельного рассмотрения от распространения.
Достаточно лицензии в корне репозитория?
Она является отправной точкой. Сторонние папки, модели, данные и отдельные файлы иногда имеют другие условия. Проверьте их перед сборкой и распространением.
Заменяет ли значок лицензии на GitHub полный анализ?
Нет. Он помогает найти предполагаемую лицензию, но не подтверждает права на все компоненты и не описывает вашу архитектуру. Сохраняйте тексты применимых условий для выбранной версии.
Перед выпуском откройте готовый установщик или архив и сравните его с карточкой компонентов. Требуемые документы должны попасть к получателю вместе с поставкой, а исходники, когда они требуются, соответствовать передаваемой версии. При обновлении компонента повторите эту проверку: измениться способны и состав программы, и условия лицензирования.