GPL vs MIT — какую лицензию выбрать?

Всем привет! Готовлюсь выложить свою библиотеку на GitHub — это набор утилит для работы с API. Стою перед выбором лицензии.

Основные кандидаты: GPL v3 и MIT. Понимаю разницу на поверхностном уровне, но хотелось бы разобраться глубже:

• Какие реальные юридические последствия выбора GPL vs MIT?
• Что лучше для привлечения контрибьюторов?
• Можно ли потом сменить лицензию?

В перспективе планирую монетизировать через SaaS, но хочу, чтобы сама библиотека была open source.

Кирилл, ключевое различие — это понятие copyleft.

MIT License:

• Permissive лицензия — минимальные ограничения
• Можно использовать в проприетарном софте без раскрытия исходного кода
• Единственное требование — сохранить текст лицензии и copyright notice
• Никаких обязательств по открытию производных работ

GPL v3:

• Strong copyleft — все производные работы должны также распространяться под GPL
• Если кто-то использует ваш GPL-код в своём проекте, весь проект должен быть GPL
• Обязательное раскрытие исходного кода при распространении
• Дополнительные защиты v3: anti-tivoization, patent grant, compatibility с Apache 2.0

С юридической точки зрения, GPL создаёт гораздо более сильные обязательства для пользователей вашего кода.

В перспективе планирую монетизировать через SaaS

Кирилл, если ты планируешь SaaS — обрати внимание на важный нюанс. GPL v3 требует раскрытия кода только при распространении (distribution). Предоставление доступа через SaaS технически не является распространением.

Именно поэтому появилась AGPL v3 (Affero GPL) — она закрывает эту «лазейку» и требует раскрытия кода даже при использовании через сеть.

Многие компании (MongoDB, Elastic) столкнулись с проблемой, когда AWS и другие облачные провайдеры использовали их GPL-код для SaaS без раскрытия модификаций. Это привело к появлению таких лицензий как SSPL.

Насчёт привлечения контрибьюторов — вот мой опыт:

MIT привлекает больше корпоративных пользователей и контрибьюторов. Юридические отделы компаний часто запрещают использовать GPL-код, потому что боятся «вирусного» эффекта copyleft. Даже если страхи иногда преувеличены.

GPL привлекает идеологических контрибьюторов, которые верят в свободный софт. Но количество таких людей объективно меньше.

Статистика GitHub это подтверждает: MIT — самая популярная лицензия (~30% проектов), за ней Apache 2.0, и только потом GPL.

Для библиотеки утилит я бы однозначно рекомендовал MIT или Apache 2.0. GPL для библиотеки — это серьёзный барьер для adoption.

Спасибо за разъяснения! А вот по поводу dual licensing — это реальная стратегия? Могу я выпустить библиотеку под GPL для open source сообщества, а для коммерческого использования продавать отдельную лицензию?

И второй вопрос: если я выберу MIT сейчас, могу ли потом переключиться на GPL? Или наоборот?

Dual licensing — абсолютно рабочая модель. Её используют Qt, MySQL (до поглощения Oracle), и многие другие. Схема такая:

• Код доступен под GPL — бесплатно для open source проектов
• Для компаний, которые не хотят GPL-обязательств — коммерческая лицензия за деньги

Но для этого вам нужно быть единственным правообладателем всего кода. Если принимаете контрибуции, нужен CLA (Contributor License Agreement), по которому контрибьюторы передают вам права или предоставляют достаточно широкую лицензию.

Смена лицензии:

• Вы можете добавлять новые лицензии к новым версиям, если вы единственный правообладатель
• MIT → GPL: можно, но уже выпущенные версии под MIT остаются под MIT навсегда
• GPL → MIT: можно для ваших новых версий, если вы единственный правообладатель
• Если есть контрибуции от других авторов — нужно их согласие (если нет CLA)

Добавлю про ещё один вариант, который часто упускают: Apache License 2.0. Она permissive как MIT, но с важным дополнением — patent grant.

Это значит, что контрибьюторы автоматически предоставляют патентную лицензию на свои вклады. MIT такой защиты не даёт.

Для библиотеки утилит это может быть важно, если в перспективе проект вырастет и привлечёт контрибуции от крупных компаний. React (Facebook) использует MIT, но раньше использовали BSD + Patents, и это вызвало скандал. Rust и Swift используют Apache 2.0 / MIT dual licensing.

Также стоит посмотреть на LGPL — это «лёгкая» версия GPL, которая позволяет линковать библиотеку с проприетарным кодом без заражения. Для библиотеки это может быть хорошим компромиссом.

Отличная дискуссия! Подытожу для себя:

Для моей ситуации (библиотека утилит + планы на SaaS) оптимальный вариант:

1. MIT или Apache 2.0 для самой библиотеки — максимальный adoption
2. CLA для контрибьюторов с первого дня — чтобы сохранить гибкость
3. SaaS-часть — проприетарная, использует библиотеку как зависимость
4. При необходимости можно потом добавить dual licensing для enterprise фичей

Склоняюсь к Apache 2.0 из-за patent grant. Спасибо Павлу за юридическое разъяснение и всем за практический опыт!