Сначала определите цель
Выбор лицензии — вопрос не вкуса, а того, чего вы хотите добиться. Большинство находится где-то между двумя целями.
- Хочу, чтобы код использовали как можно шире — если нужно, чтобы код без препятствий попадал в корпоративные продукты, другие открытые проекты и закрытые приложения, выгоднее разрешительная лицензия.
- Хочу, чтобы улучшения возвращались открытыми — если вы хотите, чтобы при распространении изменённой версии вашего кода эти изменения тоже раскрывались, подходит копилефт.
Разрешительные: широкое принятие, мало трения
MIT, BSD, ISC и Apache-2.0 требуют немногим больше, чем сохранение уведомлений. У большинства юридических отделов компаний они в списке заранее одобренных лицензий, поэтому внедрение идёт быстро. Зато нельзя помешать тому, чтобы кто-то изменил код и включил его в закрытый продукт.
Выбор внутри разрешительных лицензий сводится в основном к двум вопросам.
- Патенты: если нужны явная патентная лицензия и положение о возмездии — Apache-2.0, иначе MIT.
- Совместимость с GPL-2.0: по позиции FSF код Apache-2.0 нельзя включать в проекты GPL-2.0-only, поэтому в экосистеме вокруг ядра Linux удобнее MIT или BSD.
Копилефт: цепочка открытости
GPL распространяет обязанность раскрытия на всю объединённую программу, LGPL — на библиотеку, MPL — на отдельные файлы. Для ПО, работающего на серверах, пробел GPL закрывает AGPL. При копилефте некоторые компании могут избегать использования или участия, особенно AGPL, которую многие компании ограничивают внутренними политиками. Это может быть как задуманным эффектом, так и нежелательным побочным.
Нельзя игнорировать традиции экосистемы
Лицензия, соответствующая обычаям сообщества, вызывает меньше трения.
| Экосистема | Распространённые лицензии | Примечание |
|---|---|---|
| JavaScript (npm) | MIT, ISC | Много мелких пакетов, предпочитают короткие разрешительные |
| Rust (crates.io) | MIT OR Apache-2.0 | Сам Rust использует эту двойную схему |
| Python (PyPI) | MIT, BSD-3-Clause, Apache-2.0 | В научных вычислениях часто BSD-3 |
| Go | BSD-3-Clause, MIT, Apache-2.0 | Стандартная библиотека Go — под BSD-3 |
| Модули ядра Linux | GPL-2.0-only | Для объединения с ядром практически обязательно |
| Настольные утилиты GNU | GPL-3.0-or-later | Стандарт проекта GNU |
| Библиотеки C/C++ | LGPL, MIT, BSL-1.0 | На выбор влияет способ компоновки |
Контрольный список для решения
- Проверьте зависимости: убедитесь, что лицензии уже используемых библиотек не ограничивают выбор. Если вы распространяете программу, объединённую с библиотекой GPL, выбор сужается до лицензий, совместимых с GPL.
- Проверьте принадлежность: у кода, написанного по работе, правообладатель обычно компания. Узнайте, не задаёт ли политика открытого ПО вашей компании конкретную лицензию.
- Форма использования: действие копилефта зависит от того, устанавливаемое ли это ПО, библиотека или сервис.
- Порядок участия: если планируете принимать внешние вклады, учтите, что потом сменить лицензию будет трудно, потому что смешаются авторские права многих людей.
- Модель дохода: если планируете отдельно продавать коммерческие лицензии, рассмотрите двойное лицензирование копилефт + коммерческая вместе с соглашением участника о лицензии (CLA).
Коротко
- Главное — широкое распространение → MIT (если беспокоят патенты — Apache-2.0)
- Улучшения библиотеки хочется получать обратно, но пользователей не ограничивать → MPL-2.0 или LGPL-3.0
- Все производные программы должны быть открытыми → GPL-3.0
- Открытыми должны быть даже изменённые версии серверного ПО → AGPL-3.0
- Не хочу никаких условий → 0BSD, Unlicense, CC0
В мастере выбора можно ответить на эти критерии в виде вопросов и получить варианты с объяснением.
Эта статья содержит общую информацию и не является юридической консультацией. Важные решения обсуждайте со специалистами.
Источники
- choosealicense.com — https://choosealicense.com/
- FSF, Various Licenses and Comments about Them — https://www.gnu.org/licenses/license-list.html
- Лицензия Rust (MIT OR Apache-2.0) — https://github.com/rust-lang/rust