Как добавить лицензию в репозиторий github

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

На GitHub есть возможность указать лицензию для репозитория. Добавить типовую лицензию можно на этапе создания репозитория, как это описано в рецепте «Как создать репозиторий». Для этого необходимо выбрать лицензию из списка.

Если нужно добавить собственную, а не типовую лицензию, или выбрать лицензию уже после этапа создания репозитория, нужно сделать следующее:

1. Перейти на первую вкладку репозитория.
2. Кликнуть на «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;
• условно-бесплатной.

Схема выбора открытой лицензии из числа самых распространённых:

1. Требуется указать имя автора? Если нет, это The Unilicense. Если да, переходите ко второму или третьему пунктам.
2. Изменённые файлы должны быть помечены? Если нет, лицензия на условиях первоначальной? Да → лицензия не определена. Нет → название должно отличаться → нет → это BSD или MIT. Если название не должно отличаться, то это Apache software license.
3. Изменённые файлы должны быть помечены? Если да, то лицензия на условиях первоначальной? В случае нет лицензия не определена. Когда ответ да, указана ли территория распространения? Нет → 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 — лицензия, которая свидетельствует об отказе от авторских прав.

Unity удалила GitHub-репозиторий с историями изменений лицензии. Затем обновила ее так, чтобы она имела обратную силу

На Reddit обратили внимание, что за последние полтора года Unity сильно изменила подход к работе с лицензией на движок. Пользователь под ником Darkfrost написал пост, в котором рассказал о заметных изменениях.

▪️в июне 2022-го Unity без предупреждения удалила свой репозиторий на GitHub, который отслеживал изменения в лицензии на движок;

▪️3 апреля 2023-го Unity обновила Условия использования движка (Terms of service, TOS) до нынешней версии. Компания убрала из лицензии пункт, позволявший разработчикам пользоваться предыдущими TOS на версиях движка, вышедших в течение последнего календарного года;

▪️12 сентября Unity изменила монетизацию. В частности, она объявила, что со следующего года разработчики должны будут платить дополнительный сбор, даже если их проекты вышли на предыдущих версиях движка.

Как считает Darkfrost, своими действиями Unity подорвала доверие к компании. Разработчики больше не могут быть уверены, что она не решит еще раз увеличить сборы или добавить другие невыгодные нововведения без возможности отказаться.

Как подготовить код к 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.

© 2023 ООО «ЛЕРУА МЕРЛЕН ЦИФРОВЫЕ ТЕХНОЛОГИИ»

Юридические аспекты открытого программного кода

Все, что вас когда-либо интересовало о правовой стороне открытого исходного кода, и кое-что, чего вы не знали.

Понимание юридических последствий открытого исходного кода

Поделиться своим творчеством со всем миром может быть захватывающим и полезным опытом. Это также может означать множество юридических аспектов, о которых вы даже не подозревали. К счастью, вам не нужно начинать с нуля. Мы позаботились о ваших юридических потребностях. (Прежде чем углубляться, обязательно прочтите наш отказ от ответственности.)

Почему людей так волнует правовая сторона открытого кода?

Рады, что вы спросили! Когда вы выполняете творческую работу (например, текст, графику или код), эта работа по умолчанию находится под исключительным авторским правом. То есть закон предполагает, что как автор своей работы вы имеете право голоса в отношении того, что другие могут с ней делать.

В общем, это означает, что никто другой не может использовать, копировать, распространять или изменять вашу работу, не подвергаясь риску разбирательства, изъятия или судебного разбирательства.

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

Если вы не примените лицензию для открытого исходного кода, каждый, кто вносит свой вклад в ваш проект, также становится эксклюзивным правообладателем своей работы. Это означает, что никто не может использовать, копировать, распространять или изменять их материалы — и этот «никто» включает вас.

Наконец, ваш проект может иметь зависимости от лицензионных требований, о которых вы не знали. Сообщество вашего проекта или политика вашего работодателя также могут требовать от вашего проекта использования определенных лицензий открытого исходного кода. Мы рассмотрим эти ситуации ниже.

Открыты ли общедоступные проекты GitHub?

Когда вы создаете новый проект на GitHub, у вас есть возможность сделать репозиторий приватным (частным) или публичным (общедоступным).

Сделать ваш проект GitHub публичным — это не то же самое, что лицензировать ваш проект. На общедоступные проекты распространяются Условия использования GitHub, которые позволяют другим просматривать и делать ответвление (fork) вашего проекта. Но в остальном ваша работа не имеет разрешений.

Если вы хотите, чтобы другие могли использовать, распространять, изменять или вносить свой вклад в ваш проект, вам необходимо включить лицензию открытого исходного кода. Например, кто-то не может законно использовать какую-либо часть вашего проекта GitHub в своем коде, даже если он общедоступен, если вы явно не дадите ему на это право.

Просто дайте мне ЧтоБыТоНиБыло, что нужно для защиты моего проекта.

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

MIT, Apache 2.0 и GPLv3 — самые популярные лицензии открытого исходного кода, но на выбор есть и другие варианты. Вы можете найти полный текст этих лицензий и инструкции по их использованию на сайте choosealicense.com.

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

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

Какая лицензия открытого исходного кода подходит для моего проекта?

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

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

Ваш проект, скорее всего, имеет (или будет иметь) зависимости. Например, если вы откроете исходный код проекта Node.js, вы, вероятно, будете использовать библиотеки из Node Package Manager (npm). Каждая из этих библиотек, от которых вы зависите, будет иметь собственную лицензию открытого исходного кода. Если каждая из их лицензий является «разрешающей» (дает общедоступное разрешение на использование, изменение и совместное использование без каких-либо условий для последующего лицензирования), вы можете использовать любую лицензию, которую хотите. Общие разрешительные лицензии включают MIT, Apache 2.0, ISC и BSD.

С другой стороны, если какая-либо из лицензий ваших зависимостей является «строгим авторским левом» (strong copyleft) (также дает такие же общедоступные разрешения при условии использования той же лицензии в дальнейшем), тогда ваш проект должен будет использовать ту же лицензию. Общие лицензии со строгим авторским левом включают GPLv2, GPLv3 и AGPLv3.

Вы также можете рассмотреть сообщества, которые, как вы надеетесь, будут использовать и вносить свой вклад в ваш проект:

• Вы хотите, чтобы ваш проект использовался в качестве зависимости другими проектами? Вероятно, лучше всего использовать самую популярную лицензию в вашем соответствующем сообществе. Например, MIT — самая популярная лицензия для библиотек npm.
• Вы хотите, чтобы ваш проект понравился крупным предприятиям? Крупному бизнесу, скорее всего, потребуется явная патентная лицензия от всех участников. В этом случае Apache 2.0 поможет вам (и им).
• Вы хотите, чтобы ваш проект привлек участников, которые не хотят, чтобы их вклад использовался в программном обеспечении с закрытым исходным кодом?GPLv3 или (если они также не хотят участвовать в службах с закрытым исходным кодом) AGPLv3 подойдет.

Ваша компания может иметь особые лицензионные требования для проектов с открытым исходным кодом. Например, может потребоваться разрешительная лицензия, чтобы компания могла использовать ваш проект в продукте компании с закрытым исходным кодом. Или ваша компания может потребовать строгую лицензию с авторским левом и дополнительное соглашение с участниками (см. ниже), чтобы только ваша компания и никто другой могли использовать ваш проект в программном обеспечении с закрытым исходным кодом. Или у вашей компании могут быть определенные потребности, связанные со стандартами, социальной ответственностью или прозрачностью, любая из которых может потребовать определенной стратегии лицензирования. Поговорите с юридическим отделом вашей компании.

Когда вы создаете новый проект на GitHub, вам предоставляется возможность выбрать лицензию. Включение одной из упомянутых выше лицензий сделает ваш проект на GitHub открытым. Если вы хотите увидеть другие варианты, посетите choosealicense.com, чтобы найти подходящую лицензию для своего проекта, даже если это не программное обеспечение.

Что, если я хочу изменить лицензию своего проекта?

Большинству проектов не потребуется менять лицензии. Но иногда обстоятельства меняются.

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

Это сложно. Определение совместимости и соответствия лицензий, а также обладателей авторских прав может очень быстро стать сложным и запутанным. Переход на новую, но совместимую лицензию для новых выпусков и дополнений отличается от перелицензирования всех существующих дополнений. Привлекайте свою команду юристов при первом намеке на желание сменить лицензию. Даже если у вас есть или вы можете получить разрешение от правообладателей вашего проекта на изменение лицензии, учитывайте влияние этого изменения на других пользователей и участников вашего проекта. Думайте о смене лицензии как об «управленческом событии» для вашего проекта, которое, скорее всего, пройдет гладко при четком общении и консультациях с заинтересованными сторонами вашего проекта. Еще одна причина выбрать и использовать соответствующую лицензию для вашего проекта с самого начала!

Существующая лицензия вашего проекта. Если существующая лицензия вашего проекта совместима с лицензией, на которую вы хотите перейти, вы можете просто начать использовать новую лицензию. Это потому, что если лицензия A совместима с лицензией B, вы будете соблюдать условия A, соблюдая условия B (но не обязательно наоборот). Поэтому, если вы в настоящее время используете разрешительную лицензию (например, MIT), вы можете перейти на лицензию с дополнительными условиями, при условии, что вы сохраняете копию лицензии MIT и любые связанные уведомления об авторских правах (т.е. продолжаете соблюдать минимальные условия лицензии MIT). Но если ваша текущая лицензия не разрешающая (например, авторское лево или у вас нет лицензии) и вы не являетесь единственным владельцем авторских прав, вы не можете просто изменить лицензию вашего проекта на MIT. По сути, с разрешающей лицензией правообладатели проекта заранее дали разрешение на изменение лицензий.

Существующие правообладатели вашего проекта. Если вы являетесь единственным участником своего проекта, то вы или ваша компания являетесь единственным правообладателем проекта. Вы можете добавить или изменить любую лицензию, которую захотите вы или ваша компания. В противном случае могут быть другие правообладатели, с которыми вам потребуется согласие для изменения лицензий. Кто они? Люди, у которых есть коммиты в вашем проекте, — хорошее место для начала. Но в некоторых случаях авторские права принадлежат работодателям этих людей. В некоторых случаях люди будут вносить только минимальный вклад, но не существует жесткого правила, согласно которому вклады с использованием определенного количества строк кода не подлежат авторскому праву. Что делать? Это зависит. Для относительно небольшого и молодого проекта может оказаться целесообразным убедить всех существующих участников согласиться на изменение лицензии в ишью или пул-реквесте. Для крупных и долгоживущих проектов вам, возможно, придется искать множество участников и даже их наследников. Mozilla потребовались годы (2001-2006), чтобы перелицензировать Firefox, Thunderbird и сопутствующее программное обеспечение.

В качестве альтернативы вы можете попросить участников заранее согласиться (посредством дополнительного соглашения с участниками — см. Ниже) на определенные изменения лицензии при определенных условиях, помимо тех, которые разрешены вашей существующей лицензией с открытым исходным кодом. Это немного меняет сложность изменения лицензий. Вам заранее понадобится дополнительная помощь юристов, и вы все равно захотите четко общаться с заинтересованными сторонами вашего проекта при изменении лицензии.

Требуется ли для моего проекта дополнительное соглашение с участниками?

Возможно нет. Для подавляющего большинства проектов лицензия для открытого исходного кода неявно служит как входящей (от участников), так и исходящей (для других участников и пользователей) лицензией. Если ваш проект размещен на GitHub, то Условия использования GitHub делают “inbound = outbound” явным значением по умолчанию.

Дополнительное соглашение с участником, часто называемое лицензионным соглашением участника (CLA), может создавать административную работу для сопровождающих проект. Сколько работы добавляет соглашение, зависит от проекта и реализации. Простое соглашение может требовать, чтобы участники подтвердили одним щелчком мыши, что у них есть права, необходимые для внесения вклада в соответствии с лицензией проекта с открытым исходным кодом. Более сложное соглашение может потребовать юридической проверки и подписи со стороны работодателей участников.

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

Мы удалили CLA для Node.js. Это снижает барьер для входа в Node.js, тем самым расширяя базу участников.

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

• Ваши юристы хотят, чтобы все участники явным образом приняли (подписать, онлайн или офлайн) условия вклада, возможно, потому, что они считают, что самой лицензии с открытым исходным кодом недостаточно (даже если это так!). Если это единственная проблема, должно быть достаточно соглашения с участником, подтверждающего лицензию проекта с открытым исходным кодом. Лицензионное соглашение с индивидуальным участником jQuery является хорошим примером облегченного соглашения с дополнительным участником.
• Вы или ваши юристы хотите, чтобы разработчики доказали, что каждое совершаемое ими действие санкционировано. Требование Сертификата разработчика — это количество проектов, которые это обеспечивают. Например, сообщество Node.js использует DCO вместо их предыдущего CLA. Простым вариантом автоматизации принудительного применения DCO в вашем репозитории является DCO Probot.
• В вашем проекте используется лицензия с открытым исходным кодом, которая не включает прямую выдачу патента (например, MIT), и вам нужен патент от всех участников, некоторые из которых могут работать в компаниях с большими портфелями патентов, которые могут быть использованы для вашего таргетинга. или других участников и пользователей проекта. Лицензионное соглашение с индивидуальным участником Apache является часто используемым соглашением с дополнительным участником, в котором выдача патента является копией той, которая содержится в лицензии Apache License 2.0.
• Ваш проект находится под лицензией с авторским левом, но вам также необходимо распространять проприетарную версию проекта. Вам потребуется, чтобы каждый участник назначил вам авторские права или предоставил вам (но не общественности) разрешительную лицензию. Соглашение с участником MongoDB является примером такого типа соглашения.
• Вы думаете, что вашему проекту может потребоваться изменить лицензии в течение его срока службы, и хотите, чтобы участники заранее согласились на такие изменения.

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

Что нужно знать юридическому отделу моей компании?

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

Хорошо это или плохо, пусть они знают, даже если это личный проект. У вас, вероятно, есть «соглашение об интеллектуальной собственности сотрудников» с вашей компанией, которое дает им некоторый контроль над вашими проектами, особенно если они вообще связаны с бизнесом компании или вы используете какие-либо ресурсы компании для разработки проекта. Ваша компания должна легко дать вам разрешение, и, возможно, оно уже было получено в рамках благоприятного для сотрудников соглашения об интеллектуальной собственности или политики компании. В противном случае вы можете вести переговоры (например, объяснить, что ваш проект служит целям профессионального обучения и вашего развития в целях компании) или не работать над своим проектом, пока не найдете лучшую компанию.

Если вы открываете исходный код проекта своей компании, обязательно сообщите им об этом. У вашей юридической группы, вероятно, уже есть политика в отношении того, какую лицензию с открытым исходным кодом (и, возможно, дополнительное соглашение с участником) использовать, в зависимости от бизнес-требований и опыта компании в отношении обеспечения соответствия вашего проекта лицензиям зависимостей. Если нет, то вам с ними повезло! Ваша юридическая команда должна быть готова работать с вами, чтобы разобраться в этом вопросе. Некоторые вещи для размышления:

• Сторонние материалы: Содержит ли ваш проект зависимости, созданные другими, или иным образом включает или использует чужой код? Если это открытый исходный код, вам необходимо соблюдать лицензии на открытый исходный код материалов. Это начинается с выбора лицензии, которая работает со сторонними лицензиями с открытым исходным кодом (см. Выше). Если ваш проект изменяет или распространяет сторонние материалы с открытым исходным кодом, то ваша юридическая группа также захочет знать, что вы выполняете другие условия сторонних лицензий с открытым исходным кодом, такие как сохранение уведомлений об авторских правах. Если в вашем проекте используется чужой код, не имеющий лицензии с открытым исходным кодом, вам, вероятно, придется попросить сторонних разработчиков добавить лицензию с открытым исходным кодом, а если вы не можете его получить, прекратите использовать их код в своем проекте.
• Коммерческая тайна: Подумайте, есть ли в проекте что-то, что компания не хочет делать доступным для широкой публики. Если это так, вы можете открыть исходный код остальной части вашего проекта после извлечения материала, который хотите сохранить конфиденциальным.
• Патенты: Подает ли ваша компания заявку на патент, открытый исходный код которого ваш проект будет представлять собой публичное раскрытие? К сожалению, вас могут попросить подождать (или, возможно, компания пересмотрит мудрость приложения). Если вы ожидаете участия в своем проекте сотрудников компаний с большим портфелем патентов, ваша группа юристов может пожелать, чтобы вы использовали лицензию с явным предоставлением патента от участников (например, Apache 2.0 или GPLv3) или дополнительное соглашение с участником (см. выше).
• Торговые марки: Дважды проверьте, что название вашего проекта не конфликтует с существующими торговыми марками. Если вы используете в проекте товарные знаки собственной компании, убедитесь, что это не вызывает конфликтов. FOSSmarks — это практическое руководство по пониманию товарных знаков в контексте проектов с бесплатным и открытым исходным кодом.
• Конфиденциальность: Собирает ли ваш проект данные о пользователях? «Звонит домой» на серверы компании? Ваш юридическая команда может помочь вам в соблюдении политики компании и внешних нормативных требований.

Если вы выпускаете первый проект своей компании с открытым исходным кодом, вышеуказанного более чем достаточно для выполнения (но не волнуйтесь, большинство проектов не должны вызывать серьезных проблем).

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

• Политики участия сотрудников: Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace Типовая политика в отношении интеллектуальной собственности и открытого исходного кода.

Предоставление IP-адреса, связанного с патчем, создает базу знаний и репутацию сотрудника. Это показывает, что компания инвестирует в развитие этого сотрудника, и создает ощущение полномочий и автономии. Все эти преимущества также приводят к повышению морального духа и лучшему удержанию сотрудников.

• Что выпустить:(Почти) все? Если ваша юридическая команда понимает и вкладывается в стратегию открытого исходного кода вашей компании, они смогут намного лучше помочь, чем препятствовать вашим усилиям.
• Соответствие: Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. Осведомленность и процесс могут предотвратить головные боли, задержки продукта и судебные иски.

Организации должны иметь лицензию и стратегию соответствия, которая подходит как для категорий [“разрешающий”, так и “авторское лево”]. Это начинается с записи условий лицензирования, которые применяются к программному обеспечению с открытым исходным кодом, которое вы используете, включая субкомпоненты и зависимости.

• Патенты: Ваша компания может пожелать присоединиться к Открытой сети изобретений, общему защищенному пулу патентов, чтобы защитить использование участниками крупных проектов с открытым исходным кодом, или изучить другое альтернативное лицензирование патентов.
• Управление: Когда имеет смысл передать проект юридическому лицу за пределами компании.