Как добавить лицензию с открытым исходным кодом в проект на GitHub

.jpg?w=1600&h=900&fit=crop)

Почему лицензия важна

Лицензия — это юридический файл, который явно задаёт права и ограничения для пользователей вашего проекта. Без лицензии права остаются неочевидными: формально все права авторов сохраняются, и другие люди не имеют явного разрешения на использование или распространение кода.

Коротко:

• Лицензия защищает вас и пользователей проекта.
• Она определяет, коммерческое ли использование, нужны ли упоминания автора и обязаны ли правки оставаться открытыми.
• Размещение файла LICENSE в корне репозитория облегчает обнаружение правовых условий.

Как выбрать лицензию

Выбор зависит от целей проекта и ожидаемых способов использования.

Простейшая методология выбора (минимальная проверка):

1. Определите цель: хотите ли вы максимального распространения или строгой открытости модификаций?
2. Нужна ли вам защита от патентных претензий?
3. Допускаете ли вы закрытые производные (например, коммерческие продукты без раскрытия кода)?
4. Требуете ли вы указания авторства в продуктах?

Если кратко:

• Для максимально свободного использования — MIT.
• Для защиты от патентов и явного указания авторства — Apache 2.0.
• Для обязательного раскрытия производных — GPL (строгая копилефт-лицензия).

MIT

MIT разрешает использование, изменение и распространение при минимальных ограничениях. Требуется включать копию лицензии при распространении. Используется в Babel, .NET, Rails и многих npm-проектах.

Ключевая идея: свобода использования без требования открывать свои изменения.

Apache 2.0

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

GNU General Public License (GPL)

GPL требует, чтобы при распространении изменённого ПО оно распространялось под той же лицензией (копилефт). Это эффективно гарантирует, что производные останутся открытыми.

Существуют разные версии: GPLv2, GPLv3, LGPL и др. Выбирайте с учётом требований к совместимости и патентным положениям.

Примеры, когда лицензия не решит проблем

Важно понимать границы лицензий:

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

Шаг 1: Решите, какая лицензия вам подходит

Совет: если не уверены и хотите максимальной простоты — MIT или Apache 2.0. Если цель — чтобы все производные оставались открытыми — рассматривайте GPL.

Инструменты, которые помогут: choosealicense.com, SPDX-идентификаторы и консультация с юристом при необходимости.

Шаг 2: Добавление лицензии в проект на GitHub

1. Откройте главную страницу репозитория на GitHub.
2. Нажмите кнопку Add file и выберите Create new file.

3. Введите в поле имя файла LICENSE или LICENSE.md.
4. Нажмите Choose a license template и выберите шаблон из списка.

5. Просмотрите доступные лицензии и выберите подходящую.

6. Нажмите Review and submit.

7. Напишите сообщение коммита и выберите: коммитнуть в main или создать ветку и pull request. Нажмите Commit new file.

8. Если вы использовали pull request — слейте его. После этого файл LICENSE будет отображаться в корне репозитория.

Дополнения: где ещё указывать лицензию

• Добавьте краткую строку о лицензии в README, например: “Лицензия: MIT — подробности в файле LICENSE”.
• Укажите лицензию на странице релиза (Release notes) при публикации версий.
• В пакетных манифестах (package.json, setup.py, Cargo.toml и т.д.) указывайте SPDX-идентификатор лицензии.

Шаблоны заголовков файлов и заметок для кода

Добавьте в начало исходных файлов короткую заметку. Примеры:

MIT header:

Copyright (c) 2025 <Ваше имя или организация>

This source code is licensed under the MIT license found in the
LICENSE file in the root directory of this source tree.

Apache 2.0 header:

Copyright (c) 2025 <Ваше имя или организация>

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

GPL short header:

This file is part of .

 is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

Примечание: адаптируйте год и владельца авторских прав.

Чек-листы по ролям

Чек-лист для владельца проекта (Maintainer):

• Определить цели лицензирования.
• Выбрать лицензию и добавить файл LICENSE в корень.
• Добавить краткое упоминание лицензии в README и релизы.
• Обновить файлы лицензий в пакетных манифестах.
• Сообщить участникам и уточнить политику contribution.

Чек-лист для сотрудника юридического отдела или администратора OSS-политик:

• Проверить совместимость лицензий с зависимостями.
• Оценить риски патентов и товарных знаков.
• Подготовить CLA или DCO при необходимости.

Чек-лист для контрибьюторов:

• Ознакомиться с лицензией проекта перед внесением вклада.
• Подписать DCO/CLA, если это необходимо.

Дерево решений для выбора лицензии

flowchart TD
  A[Нужна ли вам обязательная открытость производных?] -->|Да| B[Использовать GPL]
  A -->|Нет| C[Нужна ли защита от патентов и указание авторства?]
  C -->|Да| D[Использовать Apache 2.0]
  C -->|Нет| E[Хотите максимально простую и распространённую лицензию?]
  E -->|Да| F[Использовать MIT]
  E -->|Нет| G[Рассмотреть BSD, MPL или комбинированные подходы]

Когда стоит рассмотреть альтернативы

• Если проект использует множество зависимостей с разной лицензией, рассмотрите совместимость лицензий и возможное смешение условий.
• Для библиотек, которые будут интегрированы в проприетарное ПО, MIT или Apache обычно удобнее.
• Если вы работаете в корпоративной среде — согласуйте выбор с отделом безопасности и юридическим отделом.

Критерии приёмки

1. Файл LICENSE присутствует в корне репозитория.
2. В README указана лицензия и ссылка на файл LICENSE.
3. SPDX-идентификатор лицензии добавлен в манифесты пакетов (если применимо).
4. Для публичных релизов лицензионная информация указана в описании релиза.
5. Команда уведомлена о политике contribution и требованиях (DCO/CLA).

Риски и смягчения

Риск: несовместимость лицензий зависимостей. Митигация: провести аудит зависимостей, при необходимости заменить библиотеки или использовать двоичную/интерфейсную инкапсуляцию.

Риск: патентные претензии. Митигация: выбирать лицензии с патентными положениями (например, Apache 2.0) или консультироваться с юристами.

Риск: отсутствие согласия всех авторов на смену лицензии. Митигация: сохранить историю и получить явные согласия от всех существенных контрибьюторов.

Небольшая методология для крупных проектов

1. Сформируйте рабочую группу: разработчики, менеджер продукта, юрист.
2. Оцените цели и ожидаемые сценарии использования.
3. Проведите аудит зависимостей и укажите потенциальные конфликты.
4. Выберите лицензию и подготовьте шаблоны заголовков и CONTRIBUTING.md.
5. Внедрите процесс проверки лицензий для новых зависимостей.

Краткое резюме

Добавление лицензии — простой и важный шаг для любого открытого проекта. Он делает права и обязанности прозрачными для пользователей и контрибьюторов, снижает юридические риски и улучшает доверие к проекту. Выберите лицензию, отражающую ваши цели, добавьте файл LICENSE в корень репозитория и укажите лицензионную информацию в README и релизах.

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

Внешние ресурсы для выбора лицензии:

• https://choosealicense.com
• https://spdx.org