Как подготовить код к 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](/images/design_decision.jpg)
Не Design Decision
Автоматически сгенерированный код или код, который можно написать единственным образом.
![Это не Design Decision](/images/not_design_decision.jpg)
Шаг 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.
*/
package ru.leroymerlin.delivery.tariff.convert;
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.