Как выбрать лицензию на GitHub
На GitHub есть возможность указать лицензию для репозитория. Добавить типовую лицензию можно на этапе создания репозитория, как это описано в рецепте «Как создать репозиторий». Для этого необходимо выбрать лицензию из списка.
Если нужно добавить собственную, а не типовую лицензию, или выбрать лицензию уже после этапа создания репозитория, нужно сделать следующее:
- Перейти на первую вкладку репозитория.
- Кликнуть на «Add file», который находится в верхней части репозитория рядом с кнопкой «Code», и выбрать пункт «Create new file» в выпадающем списке.
На открывшейся странице введите имя файла LICENSE.md в специальное поле над блоком с его содержимым. После этого рядом с переключателем для редактирования и превью появится кнопка «Choose a license template». На этом этапе можете выбрать одну из типовых лицензий или написать собственную.
После нажатия на кнопку «Choose a license template» вас спросят, уверены ли вы, что хотите покинуть страницу. Подтвердите, что согласны. В открывшемся окне в боковом меню слева можно выбрать одну из типовых лицензий GitHub. Например, MIT License или Apache License 2.0. В верхнем блоке есть подсказка по авторскому праву, которое защищает выбранная лицензия. В ней описаны разрешения, ограничения и условия.
После того, как определились с типом, нажмите кнопку «Review and submit». Она находится в боковом меню справа рядом с полями «Year» и «Full name».
Снова откроется окно из предыдущего пункта. Можете отредактировать типовую лицензию или просто оставить всё как есть. Если вы уверены, нажмите кнопку «Commit changes…». Во всплывающем окне выберите комментарий к коммиту, его расширенное описание, если нужно, почту, а также в какую ветку хотите сделать коммит — основную или создать новую. Затем нажмите кнопку «Commit changes».
После этого в репозитории добавится новый файл с лицензией, и на основной странице репозитория в блоке с информацией о репозитории справа появится выбранная лицензия. Например, MIT license.
Разбор решения
Скопировать ссылку «Разбор решения» Скопировано
Лицензия позволит защитить авторские права и опишет условия использования репозитория другими людьми или компаниями. Схема выбора типа лицензии:
Свободное использование? Если да, то лицензия свободная и может быть:
- условно-бесплатной — ShareWare, TrialWare, Demoware;
- открытой — Open Source;
- бесплатной — Nagware/Begware, Postcardware, Adware, Denationware, Freeware, GPL.
Если нет, то лицензия проприетарная и может быть:
- платной — Commercial;
- условно-бесплатной.
Схема выбора открытой лицензии из числа самых распространённых:
- Требуется указать имя автора? Если нет, это The Unilicense. Если да, переходите ко второму или третьему пунктам.
- Изменённые файлы должны быть помечены? Если нет, лицензия на условиях первоначальной? Да → лицензия не определена. Нет → название должно отличаться → нет → это BSD или MIT. Если название не должно отличаться, то это Apache software license.
- Изменённые файлы должны быть помечены? Если да, то лицензия на условиях первоначальной? В случае нет лицензия не определена. Когда ответ да, указана ли территория распространения? Нет → GPL, да → Mozilla public license.
Поскольку GitHub, в основном, используется для хранения кода программного обеспечения, список типовых лицензий состоит из следующих:
- Apache License 2.0;
- GNU General Public License v3.0;
- MIT License;
- BSD 2-Clause «Simplified» License;
- BSD 3-Clause «New» or «Revised» License;
- Boost Software License 1.0;
- Creative Commons Zero v1.0 Universal;
- Eclipse Public License 2.0;
- GNU Affero General Public License v3.0;
- GNU General Public License v2.0;
- GNU Lesser General Public License v2.1;
- Mozilla Public License 2.0;
- The Unlicense — лицензия, которая свидетельствует об отказе от авторских прав.
Лицензирование репозитория
Общедоступные репозитории в GitHub часто применяются для совместного использования ПО с открытым кодом. Чтобы репозиторий действительно был репозиторием с открытым кодом, вам потребуется лицензировать его, чтобы другие пользователи могли использовать, изменять и распространять программное обеспечение.
Choosing the right license
We created choosealicense.com, to help you understand how to license your code. A software license tells others what they can and can’t do with your source code, so it’s important to make an informed decision.
You’re under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you’re creating an open source project, we strongly encourage you to include an open source license. The Open Source Guide provides additional guidance on choosing the correct license for your project.
Note: If you publish your source code in a public repository on GitHub, according to the Terms of Service, other users of GitHub.com have the right to view and fork your repository. If you have already created a repository and no longer want users to have access to the repository, you can make the repository private. When you change the visibility of a repository to private, existing forks or local copies created by other users will still exist. For more information, see «Setting repository visibility.»
Determining the location of your license
Most people place their license text in a file named LICENSE.txt (or LICENSE.md or LICENSE.rst ) in the root of the repository; here’s an example from Hubot.
Some projects include information about their license in their README. For example, a project’s README may include a note saying «This project is licensed under the terms of the MIT license.»
As a best practice, we encourage you to include the license file with your project.
Searching GitHub by license type
You can filter repositories based on their license or license family using the license qualifier and the exact license keyword.
| License | License keyword |
|---|---|
| Academic Free License v3.0 | AFL-3.0 |
| Apache license 2.0 | Apache-2.0 |
| Artistic license 2.0 | Artistic-2.0 |
| Boost Software License 1.0 | BSL-1.0 |
| BSD 2-clause «Simplified» license | BSD-2-Clause |
| BSD 3-clause «New» or «Revised» license | BSD-3-Clause |
| BSD 3-clause Clear license | BSD-3-Clause-Clear |
| BSD 4-clause «Original» or «Old» license | BSD-4-Clause |
| BSD Zero-Clause license | 0BSD |
| Creative Commons license family | CC |
| Creative Commons Zero v1.0 Universal | CC0-1.0 |
| Creative Commons Attribution 4.0 | CC-BY-4.0 |
| Creative Commons Attribution ShareAlike 4.0 | CC-BY-SA-4.0 |
| Do What The F*ck You Want To Public License | WTFPL |
| Educational Community License v2.0 | ECL-2.0 |
| Eclipse Public License 1.0 | EPL-1.0 |
| Eclipse Public License 2.0 | EPL-2.0 |
| European Union Public License 1.1 | EUPL-1.1 |
| GNU Affero General Public License v3.0 | AGPL-3.0 |
| GNU General Public License family | GPL |
| GNU General Public License v2.0 | GPL-2.0 |
| GNU General Public License v3.0 | GPL-3.0 |
| GNU Lesser General Public License family | LGPL |
| GNU Lesser General Public License v2.1 | LGPL-2.1 |
| GNU Lesser General Public License v3.0 | LGPL-3.0 |
| ISC | ISC |
| LaTeX Project Public License v1.3c | LPPL-1.3c |
| Microsoft Public License | MS-PL |
| MIT | MIT |
| Mozilla Public License 2.0 | MPL-2.0 |
| Open Software License 3.0 | OSL-3.0 |
| PostgreSQL License | PostgreSQL |
| SIL Open Font License 1.1 | OFL-1.1 |
| University of Illinois/NCSA Open Source License | NCSA |
| The Unlicense | Unlicense |
| zLib License | Zlib |
When you search by a family license, your results will include all licenses in that family. For example, when you use the query license:gpl , your results will include repositories licensed under GNU General Public License v2.0 and GNU General Public License v3.0. For more information, see «Searching for repositories.»
Detecting a license
The open source Ruby gem Licensee compares the repository’s LICENSE file to a short list of known licenses. Licensee also provides the Licenses API and gives us insight into how repositories on GitHub are licensed. If your repository is using a license that isn’t listed on the Choose a License website, you can request including the license.
If your repository is using a license that is listed on the Choose a License website and it’s not displaying clearly at the top of the repository page, it may contain multiple licenses or other complexity. To have your license detected, simplify your LICENSE file and note the complexity somewhere else, such as your repository’s README file.
Applying a license to a repository with an existing license
The license picker is only available when you create a new project on GitHub.
You can manually add a license using the browser. For more information on adding a license to a repository, see «Adding a license to a repository.»
Disclaimer
The goal of GitHub’s open source licensing efforts is to provide a starting point to help you make an informed choice. GitHub displays license information to help users get information about open source licenses and the projects that use them. We hope it helps, but please keep in mind that we’re not lawyers and that we make mistakes like everyone else. For that reason, GitHub provides the information on an «as-is» basis and makes no warranties regarding any information or licenses provided on or through it, and disclaims liability for damages resulting from using the license information. If you have any questions regarding the right license for your code or any other legal issues relating to it, it’s always best to consult with a professional.
Further reading
- The Open Source Guides’ section «The Legal Side of Open Source»
- GitHub Skills
Как подготовить код к open source?
Мы активно используем продукты open source. А ещё хотим контрибутить, чтобы поддерживать сообщество и участвовать в разработке. Поэтому сделали эту инструкцию — здесь описано, как заопенсорсить код.
Шаг 1. Проверяем указание авторства и оригинальность кода
Необходимо зафиксировать список участников проекта. Для каждого участника определить:
- Имя и фамилию – Pavel Griboedov
- Компанию — LLC «Leroy Merlin Vostok»
- Контактную почту – pavel.griboedov@leroymerlin.ru
Указание правильной информации в git
Обязательно отправлять корректную мета-информацию с каждым коммитом.
По этой информации определяется авторство кода.
git config --global user.name "Pavel Griboedov" git config --global user.email "pavel.griboedov@leroymerlin.ru" Нельзя привлекать временных работников или практикантов к разработке собственных продуктов, которые мы будем выкладывать в open source, а также к работе над внешними open source-проектами.
Если для нас пишет код внешняя компания, нужно составить контракт с отчуждением прав, а также дополнительно указывать принадлежность кода в исходниках и в документации.
Проверка оригинальности
Оригинальность — это важный юридический термин. Мы обладаем юридическими правами, только если код оригинальный. На практике оригинальность кода можно определить, выделив design decision.
Design Decision
Персональная интеллектуальная контрибуция разработчика — доказывает, что другой разработчик решил бы похожую проблему иначе.
Не Design Decision
Автоматически сгенерированный код или код, который можно написать единственным образом.
Шаг 2. Выбираем лицензию
Лицензии copyleft
Допустим, ты пишешь код и используешь для этого чужой, который защищен Copyleft лицензией. Тогда, чтобы распространять свой, тебе придётся выбрать лицензию похожего типа. Это значит, что если ты захочешь использовать библиотеку с copyleft-лицензией, то распространять ПО нужно тоже по свободной copyleft-лицензии.
Самая популярная лицензия этого типа — GNU GPLv3. Даёт возможность делать с проектом всё что угодно, за исключением дистрибуции с закрытым кодом.
Лицензии copyright
Этот тип лицензий разрешает всем использовать и распространять продукты, которые содержат твой код. Даже в закрытых проприетарных решениях.
- BSD — есть две основные редакции. Оригинальная версия обязывает добавлять рекламу библиотеки во всех продуктах, где есть твой код, например такую: «Продукт использует программу, разработанную в компании Рога и копыта». Изменённая и укороченная версия не включает это обязательство. Обе версии называются одинаково, поэтому мы советуем не использовать их совсем, чтобы не запутаться. А ещё эта лицензия полностью игнорирует патентные права, о которых чуть дальше.
- MIT — короткая лицензия в несколько параграфов. Нравится разработчикам за свою простоту и отлично подходит небольшим проектам. Единственное но — её изобрели раньше, чем патентные права стали часто применяться. Как следствие — лицензия никак не покрывает эту тему.
Разница между правами копирайта и патентными правами
Копирайт защищает идеи и вступает в силу автоматически после написания кода. В этом случае копировать или изменять код можно только автору, другим — с разрешения автора по лицензии.
Патент защищает изобретения. Если кто-то создаст похожее ПО, владелец патента сможет запретить использовать его или предложит купить патент. У владельца копирайта таких прав нет: если ты и другой разработчик напишете похожий код, каждый из них будет охраняться копирайтом.
- Apache 2.0 — популярная open source лицензия, которую используют в CNCF и Apache Foundation. Длиннее чем MIT, но покрывает ещё и вопрос с патентами.
Рекомендованный выбор лицензии для большинства случаев
По умолчанию мы предлагаем использовать сopyright open source лицензию — Apache 2.0
Apache License 2.0
Основное требование — сохранение информации о копирайте и лицензии. Разрешает патентное использование. Лицензированный код, модификации и работы на его основе могут распространяться под другой, даже закрытой лицензией и не включать исходный код.
Указание лицензии в проекте
В каждом файле с кодом в шапке должна быть указана лицензия.
/* * Copyright 2020 LLC Leroy Merlin Vostok. * * 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 * * https://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. */ README.md должен упоминать лицензию.
## License
This repository is released under version 2.0 of the
[Apache License](https://www.apache.org/licenses/LICENSE-2.0).
LICENSE-файл в корне должен иметь полный текст лицензии.
Шаг 3. Проверяем совместимость сторонних зависимостей
Лицензии сторонних компонентов могут требовать использование определённой лицензии в твоём проекте. Это значит, что нужно проверять совместимости между сторонними компонентами, а также между компонентами и лицензией проекта.
| Тип лицензии зависимости | Пример | Требуемые действия |
|---|---|---|
| Разрешающие | Apache BSD MIT | None |
| Copyleft | GPL LGPL AGPL | None |
| Без лицензии | Проверить совместимость | |
| Проприетарные | Commercial | Удалить или заменить компонент |
| Требующая принятие стороннего соглашения вместе с open source лицензией | CLA CAA | Принять соглашение, удалить или заменить компонент |
Все шаги пройдены
Можно выкладывать проект в open source. Для этого нужно анонсировать предложение в CI/CD канале в Слаке — дальше репозиторий добавят в список исключений в специальном боте, который закрывает открытые по ошибке репозитории.
После этого можно смело идти в настройки репозитория и выставить его видимость в public.
© 2024 ООО «ЛЕРУА МЕРЛЕН ЦИФРОВЫЕ ТЕХНОЛОГИИ»
Как выложить свой проект на GitHub?
Если вы, как и я, решили освоить git, то скорее всего у вас возникнет желание разместить свой проект на GitHub.com для публичного доступа.
Как новичку мне было сложно понять, каким образом создать связь между репозиториями. То есть локально у нас есть набор файлов проекта. Нужно каким-то образом выложить их на гитхаб. По сути это обычное копирование, но в git это работает не так очевидно. Пробившись несколько дней, я написал свою пошаговую инструкцию для новичков.
Два способа
Существует два способа для связи с гитхабом. Они далеко не так очевидны для новичков. Основной нюанс заключается в том, какой именно будет использован гитхабовский репозиторий: совершенно пустой (не инициализированный) или уже рабочий. Именно это будет определять два разных варианта работы.
Первый способ подходит для уже инициализированных удаленных репозиториев. Для связи GitHub с локальной копией, вначале следует клонировать гитхабовский репозиторий как локальный. Только после этого можно изменить локальный и отправить его на удалённый.
Второй способ используется для совершенно пустого гитхабовского репозитория. Если уже есть локальный репозиторий, то можно вручную связать его с гитхабом без клонирования.
Регистрация на GitHub.com
Вначале нужно зарегистрироваться на GitHub.com. Процедура простая, не будем на ней останавливаться. После этого нужно создать репозиторий. В поле «Repository name» следует указать имя, которое в будущем будет совпадать с каталогом проекта. Это удобно, хотя, локальный каталог может быть любым. Пусть проект называется «demo».
Здесь очень важнный момент. Если вы отметите любые опции (добавить .gitignore, лицензию и/или readme), то фактически это будет означать инициализацию репозитория. То есть это уже не пустой репозиторий, а наполненный и инициализировнный. В этом случае для связки придётся вначале клонировать удаленный. Это первый способ.
Если же вы не отметили ни одной опции, то гитхаб создаст совершенно пустой репозиторий без инициализации. И вот такой репозиторий можно связать с уже существующим локальным. Это второй способ.
После создания репозиторий получит уникальную ссылку, например: https://github.com/USER/demo.git — где USER — ваш логин в гитхабе. Эта ссылка потребуется для работы.
Установка Git
Я всё ставил с официального сайта Git. Там же на сайте есть руководство Book, где описаны все начальне шаги. Поэтому будем считать, что git установлен и настроен.
Рассмотрим два способа отдельно.
Первый способ
Наш проект размещается в каталоге /demo/ . Было бы неплохо сохранить этот каталог и для дальнейшей работы. Для того, чтобы обезопасить себя, переименуем его /demo-temp/ любым файловым менеджером. То есть теперь каталога /demo/ у нас нет.
Запускаем git-bash и клонируем удаленный репозиторий на локальную машину:
git clone https://github.com/USER/demo.git
— где USER — ваше имя на гитхабе. Ссылку также можно скопировать со страницы репозитория в поле «HTTPS clone URL».
Появится каталог /demo/ который создал git. Он должен быть пустой, кроме подкаталога «.git» — это служебный каталог, и его трогать не нужно.
Теперь копируем в каталог /demo/ содержимое нашего проекта, которое мы сохранили в /demo-temp/ . Всё, что мы сюда скопируем, будет вылождено на GitHub, поэтому желательно удалить все ненужные файлы. Если какие-то служебные файлы требуются для проекта, то их можно указать в файле .gitignore.
git add .
Это добавит все файлы для отслеживания git’ом. Проверить состояние (до и после add) можно командой
git status
Теперь делаем коммит (сообщение любое):
git commit -m "Add project"
Пока мы работаем с локальным репозиторием. То есть нужно настроить его так, чтобы он оказался в том виде, который отправится на гитхаб.
Для удобства можно сразу выставить метку версии (опять же любой вариант):
git tag v1.0
Теперь можно отправить изменения на гитхаб.
git push
Git может выдать сообщение, что команда push не настроена по-умолчанию. Пока не обращайте внимания на это сообщение. Нужно будет внести изменения в конфигурацию позже.
Git потребует ввести логин и пароль для GitHub.com. Учитывайте, что пароль полностью скрывается, поэтому не будет видно даже «звездочек». После ввода нажимаем Enter и git выполнит обновление удаленного репозитория.
Теперь нужно обновить метки на удаленном репозитории (если вы их задали).
git push --tags
Здесь также нужно будет ввести логин и пароль.
Всё, синхронизация выполнена! Временный каталог /demo-temp/ можно удалить или сохранить как старый резервный вариант.
Если мы зайдем на страницу репозитория на гитхабе, то увидим свой проект.
Для настройки push, если требуется, пишем:
git config --global push.default simple
Второй способ
Наш проект может размещатся в любом каталоге. Для него нужно инициализировать git. Это стандартная процедура:
git init git add . git commit -m "Init"
Теперь для проекта git работает и его можно использовать по своему усмотрению: добавлять версии, смотреть логи, делать ветки и т.п.
Для связи с GitHub’ом следует указать удаленный репозиторий:
git remote add origin https://github.com/USER/demo.git git push -u origin master
Этот код указывает адрес удаленного и отправляет все изменения на гитхабовский сервер. Если мы зайдем на страницу репозитория на гитхабе, то также увидим свой проект.