Генератор лицензий

Не существует универсальной «лучшей» лицензии для программного обеспечения с открытым исходным кодом. Выбор зависит от того, что вы хотите, чтобы пользователи могли делать, а что, нет.

Три практические вопросы

1. Хотите форки с закрытым исходным кодом? Позволительные лицензии (MIT, Apache, BSD), да; лицензии с условием copyleft (GPL, AGPL), нет.

2. Заботитесь ли вы о репрессиях в связи с патентами? В проектах Apache-2.0, GPLv3 и MPL-2.0 предусмотрены явные патентные ограничения, которые прекращаются в случае судебного разбирательства; в проектах MIT и BSD-2/3 таких ограничений нет.

3. Работает ли ваш код как сетевой сервис? AGPL-3.0 устраняет «пропуск в стандарте SaaS»: пользователи сервиса считаются участниками распространения программного обеспечения. Если это важно, выбирайте этот вариант; в противном случае GPLv3 более прост в применении.

Частые ошибки, которых стоит избегать

– Не изменяйте текст лицензии. Лицензия типа «MIT с моими поправками» является новой и несовместимой лицензией; суды отвергают любые произвольные изменения. – Не используйте две лицензии, не понимая их совместимости: Apache-2.0 и GPLv2 несовместимы, тогда как Apache-2.0 и GPLv3 совместимы. – Не забывайте указать идентификатор SPDX в заголовках исходного кода: значение SPDX-License-Identifier: MIT в первой строке позволяет инструментам определить ваш выбор. – Не используйте лицензию Creative Commons для программного обеспечения. Лицензии CC предназначены для творческих произведений; применяйте их к документации и изображениям, а не к коду.

Двойная лицензия

Некоторые проекты распространяются под двумя лицензиями, обычно одной с условиями копиправа и одной коммерческой, чтобы компании могли выбирать лицензионные условия по своему усмотрению. Такой подход широко используется в проектах Qt и MySQL. Однако это создаёт юридические сложности: если вы не планируете получать доход от проекта, рекомендуется использовать только одну лицензию, одобренную OSI.