Практическое руководство по применению лицензии

1. Файл LICENSE — в корень репозитория

Первым делом поместите текст лицензии в файл LICENSE (или LICENSE.txt, LICENSE.md) в корне репозитория. GitHub, GitLab и менеджеры пакетов ищут этот файл, чтобы определить лицензию. В генераторе выберите лицензию, введите год и правообладателя — и файл можно сразу скачать.

• Не меняйте текст: заполняйте только заполнители вроде [year] и [fullname] в MIT, BSD и ISC, а остальные фразы оставляйте как есть. Изменённый текст перестаёт распознаваться как стандартная лицензия и может породить проблемы толкования.
• Лицензии GNU — полностью без изменений: в текстах GPL, LGPL и AGPL нет мест для заполнения. Правообладателя и условие о версии указывают в уведомлении в файлах.

2. Год и правообладатель

• Год: обычно указывают год первой публикации. Пишут и диапазон, например 2019-2026. Юридической обязанности ежегодно обновлять год нет.
• Правообладатель: для кода, написанного вами лично, — ваше имя; для кода, созданного по работе, как правило, работодатель (зависит от страны и договора). В проектах с многими участниками часто пишут, например, The Example Project Authors и ведут список в файле AUTHORS.
• Уведомление об авторском праве не создаёт право, а сообщает о нём. Авторское право существует и без уведомления.

3. Сопутствующие файлы для разных лицензий

NOTICE в Apache-2.0 не обязателен, но тот, кто повторно распространяет код, где NOTICE уже есть, обязан сохранить его содержимое. ASF рекомендует помещать в NOTICE только юридически необходимые сведения об авторстве, без благодарностей и текстов лицензий.

4. Заголовки исходных файлов

Если в каждом файле есть короткий заголовок, сведения о лицензии сохраняются, даже когда файл копируют отдельно.

# SPDX-FileCopyrightText: 2026 Example Inc.
# SPDX-License-Identifier: Apache-2.0

GNU, Apache и MPL рекомендуют и официальные уведомления, но всё больше проектов заменяют их двумя строками SPDX. Подробнее — в руководстве по SPDX.

5. Метаданные пакета и README

• Укажите идентификатор SPDX в поле license файлов package.json, Cargo.toml, pyproject.toml и т. д.
• В конце README добавьте раздел «Лицензия» с кратким описанием в одну-две строки (например, «This project is licensed under the MIT License — see LICENSE»).

6. Уведомления о стороннем коде

Если вы распространяете чужой код в составе своего, нужно соблюдать и его лицензионные обязанности.

• В скопированном коде сохраняйте исходное уведомление об авторском праве и лицензию в соответствующем файле.
• При распространении в виде бинарных файлов или приложения соберите список использованного открытого ПО и полные тексты лицензий в файле THIRD_PARTY_NOTICES или на экране «Лицензии открытого ПО» приложения.
• При большом числе зависимостей формируйте список автоматически с помощью инструментов SBOM или функции отчёта о лицензиях менеджера пакетов.

7. Приём вкладов: DCO или CLA

С внешними вкладами авторские права распределяются между многими людьми. Есть два способа с этим управляться.

• DCO: участник добавляет в коммит Signed-off-by:, подтверждая, что вправе представить этот код под лицензией проекта. Лёгкий способ; его использует ядро Linux.
• CLA: договор, по которому участник предоставляет проекту широкие права, включая перелицензирование. Нужен для коммерческого двойного лицензирования или если вы хотите оставить возможность сменить лицензию позже.

Правила участия изложите в CONTRIBUTING.md.

8. Если вы меняете лицензию

• Правообладатель может применить другую лицензию к будущим версиям. Разрешения для уже распространённых версий, как правило, не отзываются.
• Если в проекте есть код других участников, нужно их согласие (кроме случаев, когда право на перелицензирование получено по CLA).
• Смена разрешительной лицензии на копилефт сравнительно проста (разрешительный код можно включать в проекты с копилефтом), а смена копилефта на разрешительную без согласия всех правообладателей практически невозможна.
• Чётко зафиксируйте момент, причину и затронутые версии смены в CHANGELOG и README.

Контрольный список

1. Текст LICENSE (заполнены только заполнители)
2. Сопутствующие файлы (NOTICE, COPYING.LESSER и т. д.)
3. Заголовки файлов (две строки SPDX)
4. Метаданные пакета и README
5. Уведомления о стороннем коде
6. Правила участия (DCO или CLA)

Эта статья содержит общую информацию и не является юридической консультацией. Важные решения обсуждайте со специалистами.

Источники

• GitHub Docs, Adding a license to a repository — https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
• Apache, Applying the Apache License · Assembling LICENSE and NOTICE — https://www.apache.org/legal/apply-license.html
• GNU, How to Use GNU Licenses for Your Own Software — https://www.gnu.org/licenses/gpl-howto.html
• REUSE Specification — https://reuse.software/spec/
• Developer Certificate of Origin — https://developercertificate.org/