Что такое лицензия GitHub?
Лицензия GitHub — это юридическая декларация, которая определяет, как другие могут использовать ваше программное обеспечение или код. По сути, это набор разрешений и ограничений, которые определяют, как ваш код может распространяться, изменяться и повторно использоваться.
Кроме того, лицензии играют основополагающую роль в сообществе разработчиков ПО с открытым исходным кодом, поскольку они помогают поддерживать баланс между развитием сотрудничества и защитой интересов разработчиков.
При создании репозитория GitHub вы можете выбрать лицензию для своего проекта. Вы можете выбрать из множества лицензий с открытым исходным кодом, каждая из которых имеет свои собственные положения и условия.
Крайне важно принять обоснованное решение при выборе лицензии, поскольку этот выбор может оказать существенное влияние на будущее проекта и то, как его смогут использовать другие.
Ниже в нескольких пунктах представлена дополнительная информация с нескольких разных сайтов, которая, возможно будет полезна для общего понимания лицензирования ПО.
Во второй части статьи представлен обзор типов лицензий GitHub.
Отказ от ответственности со стороны GitHub
Целью усилий GitHub по лицензированию открытого исходного кода является предоставление отправной точки для помощи вам в принятии обоснованного выбора. GitHub отображает информацию о лицензиях, чтобы помочь пользователям получить информацию о лицензиях открытого исходного кода и проектах, которые их используют. Мы надеемся, что это поможет, но, пожалуйста, помните, что мы не юристы и что мы совершаем ошибки, как и все остальные. По этой причине GitHub предоставляет информацию на условиях «как есть» и не дает никаких гарантий относительно любой информации или лицензий, предоставленных на нем или через него, и отказывается от ответственности за ущерб, возникший в результате использования информации о лицензии. Если у вас есть какие-либо вопросы относительно правильной лицензии для вашего кода или любые другие юридические проблемы, связанные с ним, всегда лучше проконсультироваться со специалистом.
Какая лицензия с открытым исходным кодом подойдет для вашего проекта?
Трудно ошибиться с лицензией MIT, если вы начинаете с чистого листа. Она короткая, понятная и позволяет кому угодно делать что угодно, пока он сохраняет копию лицензии, включая ваше уведомление об авторских правах. Вы сможете выпустить проект под другой лицензией, если вам когда-нибудь понадобится.
В противном случае выбор подходящей лицензии с открытым исходным кодом для вашего проекта зависит от ваших целей.
Ваш проект, скорее всего, имеет (или будет иметь) зависимости , каждая из которых будет иметь свою собственную лицензию с открытым исходным кодом с условиями, которые вы должны соблюдать. Например, если вы открываете исходный код проекта Node.js, вы, вероятно, будете использовать библиотеки из Node Package Manager (npm).
Зависимости с разрешительными лицензиями, такими как MIT , Apache 2.0 , ISC и BSD, позволяют вам лицензировать свой проект так, как вам удобно.
Зависимости с лицензиями copyleft требуют более пристального внимания. Включение любой библиотеки с «сильной» лицензией copyleft, такой как GPLv2 , GPLv3 или AGPLv3, требует от вас выбора идентичной или совместимой лицензии для вашего проекта. Библиотеки с «ограниченной» или «слабой» лицензией copyleft, такой как MPL 2.0 и LGPL, могут быть включены в проекты с любой лицензией, при условии соблюдения дополнительных правил, которые они указывают.
Вы также можете рассмотреть сообщества, которые , как вы надеетесь, будут использовать ваш проект и вносить в него свой вклад:
- Хотите ли вы, чтобы ваш проект использовался как зависимость другими проектами? Вероятно, лучше всего использовать самую популярную лицензию в вашем соответствующем сообществе. Например, MIT — самая популярная лицензия для библиотек npm .
Хотите, чтобы ваш проект был интересен крупному бизнесу? Крупный бизнес может быть удовлетворен патентной лицензией от всех участников. В этом случае Apache 2.0 охватывает вас (и их). - Хотите ли вы, чтобы ваш проект понравился участникам, которые не хотят, чтобы их вклад использовался в программном обеспечении с закрытым исходным кодом? GPLv3 или (если они также не хотят вносить вклад в службы с закрытым исходным кодом) AGPLv3 подойдут хорошо.
- В вашей компании могут быть политики лицензирования проектов с открытым исходным кодом. Некоторые компании требуют, чтобы ваши проекты имели разрешительную лицензию для разрешения интеграции с фирменными продуктами компании. Другие политики предусматривают сильную лицензию copyleft и дополнительное соглашение с участником (см. ниже), поэтому только ваша компания может использовать проект в программном обеспечении с закрытым исходным кодом. Организации также могут иметь определенные стандарты, цели социальной ответственности или потребности в прозрачности, которые могут потребовать определенной стратегии лицензирования. Обратитесь в юридический отдел вашей компании за рекомендациями.
Когда вы создаете новый проект на GitHub, вам предоставляется возможность выбрать лицензию. Включение одной из лицензий, упомянутых выше, сделает ваш проект GitHub проектом с открытым исходным кодом. Если вы хотите увидеть другие варианты, посетите choosealicense.com, чтобы найти правильную лицензию для вашего проекта, даже если это не программное обеспечение.
Что необходимо знать юридическому отделу моей компании?
Если вы как сотрудник компании выпускаете проект с открытым исходным кодом, в первую очередь ваша юридическая команда должна знать, что вы выпускаете проект с открытым исходным кодом.
Хорошо это или плохо, подумайте о том, чтобы дать им знать, даже если это личный проект. У вас, вероятно, есть «соглашение об интеллектуальной собственности сотрудников» с вашей компанией, которое дает им некоторый контроль над вашими проектами, особенно если они вообще связаны с бизнесом компании или вы используете какие-либо ресурсы компании для разработки проекта. Ваша компания должна легко дать вам разрешение, и, возможно, уже сделала это через дружественное сотрудникам соглашение об интеллектуальной собственности или политику компании. Если нет, вы можете договориться (например, объяснить, что ваш проект служит целям профессионального обучения и развития компании для вас) или не работать над своим проектом, пока не найдете лучшую компанию.
Если вы открываете исходный код проекта для своей компании, то обязательно дайте им знать. У вашей юридической команды, вероятно, уже есть политики относительно того, какую лицензию с открытым исходным кодом (и, возможно, дополнительное соглашение с участником) использовать на основе бизнес-требований компании и опыта в обеспечении соответствия вашего проекта лицензиям его зависимостей. Если нет, вам и им повезло! Ваша юридическая команда должна быть готова работать с вами, чтобы разобраться в этом вопросе. Вот о чем стоит подумать:
- Материалы третьих лиц: есть ли в вашем проекте зависимости, созданные другими, или иным образом включает или использует ли он чужой код? Если это материалы с открытым исходным кодом, вам необходимо будет соблюдать лицензии на открытый исходный код материалов. Это начинается с выбора лицензии, которая работает со сторонними лицензиями на открытый исходный код. Если ваш проект изменяет или распространяет материалы с открытым исходным кодом третьих лиц, то ваша юридическая группа также захочет узнать, соблюдаете ли вы другие условия лицензий на открытый исходный код третьих лиц, такие как сохранение уведомлений об авторских правах. Если в вашем проекте используется чужой код, не имеющий лицензии на открытый исходный код, вам, вероятно, придется попросить сторонних сопровождающих добавить лицензию на открытый исходный код, и если вы не можете ее получить, прекратите использовать их код в своем проекте.
- Коммерческие секреты: подумайте, есть ли в проекте что-то, что компания не хочет делать доступным для широкой публики. Если это так, вы можете открыть исходный код остальной части вашего проекта, предварительно извлекая материал, который вы хотите сохранить в тайне.
- Патенты: Ваша компания подает заявку на патент, открытый исходный код которого будет означать публичное раскрытие ? К сожалению, вас могут попросить подождать (или, возможно, компания пересмотрит целесообразность заявки). Если вы ожидаете вклад в ваш проект от сотрудников компаний с большими патентными портфелями, ваша юридическая команда может потребовать, чтобы вы использовали лицензию с явным патентным предоставлением от участников (например, Apache 2.0 или GPLv3) или дополнительное соглашение участника ( см. выше ).
- Торговые марки: Дважды проверьте, что название вашего проекта не конфликтует с существующими торговыми марками . Если вы используете в проекте торговые марки вашей компании, проверьте, что это не вызывает никаких конфликтов. FOSSmarks — это практическое руководство по пониманию торговых марок в контексте свободных и открытых проектов.
- Конфиденциальность: Собирает ли ваш проект данные о пользователях? «Звоните домой» на серверы компании? Ваша юридическая команда может помочь вам соблюдать политику компании и внешние правила.
Если вы выпускаете первый проект с открытым исходным кодом вашей компании, вышеперечисленного более чем достаточно, чтобы справиться (но не волнуйтесь, большинство проектов не должны вызывать серьезных опасений).
В долгосрочной перспективе ваша юридическая команда может сделать больше, чтобы помочь компании извлечь больше пользы из своего участия в открытом исходном коде и обеспечить безопасность:
- Политика вклада сотрудников: Рассмотрите возможность разработки корпоративной политики, которая определяет, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им вносить вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках их работы или в свободное время. Хорошим примером является Модель IP и политика вклада Open Source компании Rackspace.
Краткое описание типов лицензий GitHub для разработчиков
Permissive (разрешающие) лицензии
Эти лицензии позволяют свободно использовать, изменять и распространять ПО с минимальными ограничениями.
- MIT (MIT License) – Одна из самых популярных. Лицензия MIT — одна из самых разрешительных лицензий с открытым исходным кодом. Она позволяет другим использовать, изменять и распространять ваш код как в коммерческих, так и в некоммерческих целях. От них требуется только включить оригинальную лицензию и уведомление об авторских правах (указание авторства и отказа от ответственности). Эта лицензия — отличный выбор для разработчиков, которые хотят способствовать широкому внедрению своего программного обеспечения.
- BSD (например, 3-пунктовая BSD, 2-пунктовая BSD): эти лицензии являются разрешительными, как и лицензия MIT, но могут иметь небольшие различия в своих условиях. Обычно они позволяют свободно использовать код, но требуется включение оригинального уведомления об авторских правах.
- BSD 2-Clause (BSD-2-Clause) – Позволяет использовать код с указанием авторства и отказом от ответственности. Не требует открытого распространения исходников.
- BSD 3-Clause (BSD-3-Clause) – Аналогична BSD-2-Clause, но добавляет запрет на использование имени автора для продвижения производных продуктов.
- BSD 4-Clause (BSD-4-Clause) – Дополнительно требует упоминания автора в рекламных материалах.
- BSD Zero-Clause (0BSD) – Вообще не содержит ограничений, код полностью в общественном достоянии.
- Apache License 2.0 (Apache-2.0) – Разрешающая лицензия с требованием сохранения уведомлений о патентах.
Apache License — это еще одна разрешительная лицензия, которая позволяет использовать, изменять и распространять ваш код. Она обеспечивает патентную защиту и более полный отказ от ответственности по сравнению с MIT License. Это предпочтительный выбор для крупных проектов, управляемых сообществом. - ISC (ISC License) – Практически идентична MIT и BSD-2-Clause.
- Boost Software License 1.0 (BSL-1.0) – Похожа на MIT, но имеет особые условия для юридической ответственности.
- University of Illinois/NCSA Open Source License (NCSA) – Аналог MIT, но использовалась в научных и образовательных проектах.
- PostgreSQL License (PostgreSQL) – Очень схожа с BSD-2-Clause.
Copyleft (лицензии с требованиями распространения изменений)
Эти лицензии требуют, чтобы производные работы распространялись на тех же условиях.
- GNU General Public License (GPL-2.0, GPL-3.0) – Обязывает открывать исходный код производных проектов под той же лицензией.
Существует несколько версий GPL, но все они имеют общий принцип: если вы используете, изменяете или распространяете код под GPL, ваша производная работа также должна быть лицензирована под GPL. Эта лицензия часто используется для проектов, в которых приоритетом является сохранение исходного кода открытым и предотвращение использования в коммерческих целях. - GNU Lesser General Public License (LGPL-2.1, LGPL-3.0) – Позволяет использовать код в проприетарных проектах, но требует открытого распространения модификаций.
LGPL похожа на GPL, но она менее ограничительна в плане того, как код может использоваться в проприетарном программном обеспечении. Она допускает более разрешительную комбинацию открытого и проприетарного кода. - GNU Affero General Public License (AGPL-3.0) – Аналог GPL, но с требованием распространения исходного кода даже при использовании через веб-сервис.
AGPL похожа на GPL, но добавляет условие, что если программное обеспечение доступно по сети, любые изменения должны быть предоставлены как открытый исходный код. Это делает ее пригодной для веб-приложений и сервисов.
Weak Copyleft (лицензии с более мягкими требованиями)
Позволяют использовать код в закрытых проектах, но требуют открытого распространения изменений.
- Mozilla Public License 2.0 (MPL-2.0) – Разрешает использование в закрытых проектах, но изменения в лицензируемых файлах должны быть открыты.
- Eclipse Public License (EPL-1.0, EPL-2.0) – Аналогична MPL, но совместима с коммерческими продуктами.
Creative Commons (CC)
Используется в основном для контента (текста, изображений, музыки).
- CC0-1.0 – Полное освобождение от авторских прав (аналог общественного достояния).
- CC-BY-4.0 – Разрешает использование при указании авторства.
- CC-BY-SA-4.0 – Требует распространения производных работ на тех же условиях.
Другие лицензии
- Artistic License 2.0 (Artistic-2.0) – Позволяет использовать код свободно, но с ограничениями на его распространение в измененном виде.
- Academic Free License (AFL-3.0) – Похожая на Apache 2.0, но с четкими юридическими формулировками.
- Microsoft Public License (MS-PL) – Разрешает использование кода, но не совместима с GPL.
- Open Software License (OSL-3.0) – Требует распространения изменений под той же лицензией.
- The Unlicense (Unlicense) – Полный отказ от авторских прав (аналог CC0-1.0).
- Do What The F*ck You Want To Public License (WTFPL) – Самая свободная лицензия, без ограничений.
Если ты работаешь с коммерческим ПО, безопаснее всего использовать MIT, Apache-2.0 или BSD. Если хочешь, чтобы твой код оставался открытым, лучше выбрать GPL или AGPL.
Apache License 2.0: Что нужно знать разработчику
Apache License 2.0 (Apache-2.0) — одна из самых популярных открытых лицензий, широко применяемая в сфере программного обеспечения. Она была разработана Apache Software Foundation (ASF) и принята в 2004 году, заменив собой предыдущую версию Apache License 1.1. Данная лицензия предоставляет пользователям значительную свободу в использовании, изменении и распространении программного кода, при этом обеспечивая защиту авторов и пользователей.
Основные особенности Apache License 2.0
Apache License 2.0 относится к категории «разрешительных» (permissive) лицензий. Это означает, что разработчики могут свободно использовать, модифицировать и распространять программный код, даже в коммерческих проектах, при соблюдении определённых условий.
Ключевые положения лицензии:
- Свободное использование – Лицензия позволяет свободно использовать программное обеспечение в любых целях, включая коммерческое и частное использование.
- Изменение и распространение – Код можно изменять и распространять в исходном или скомпилированном виде.
- Указание авторства – В изменённом или перераспространённом коде необходимо сохранять оригинальные файлы лицензии и уведомления об авторстве.
- Отказ от ответственности – Лицензия снимает юридическую ответственность с авторов за возможные дефекты в коде.
- Патентные права – Apache 2.0 предоставляет пользователям лицензии на патенты, которые могут быть связаны с программным обеспечением. Однако, если кто-то начинает судебное разбирательство по поводу нарушения патента, его права по лицензии автоматически прекращаются.
Ограничения и условия использования
Хотя Apache License 2.0 даёт значительную свободу пользователям, она накладывает некоторые ограничения:
- Сохранение уведомлений – При распространении кода необходимо оставлять в нём оригинальные уведомления об авторских правах и лицензионное соглашение.
- Запрет на использование товарных знаков – Лицензия не предоставляет право использовать товарные знаки (trademarks) ASF или других авторов проекта.
- Совместимость с другими лицензиями – Код, лицензированный под Apache 2.0, можно включать в проекты с лицензиями GPL версии 3, но несовместимость с GPL-2.0 требует осторожности при интеграции.
Отличия Apache License 2.0 от других лицензий
Apache License 2.0 отличается от других популярных лицензий рядом аспектов:
- vs MIT и BSD – Apache License 2.0 добавляет защиту от патентных споров, чего нет в MIT и BSD.
- vs GPL – В отличие от GPL, Apache License 2.0 не требует, чтобы производные работы распространялись под той же лицензией (отсутствие эффекта «вирусности» GPL).
Когда стоит выбирать Apache License 2.0?
Apache License 2.0 идеально подходит для разработчиков, которые хотят:
- Сделать код открытым и доступным для широкого круга пользователей.
- Позволить коммерческое использование своего кода без строгих ограничений.
- Защитить себя и пользователей от патентных претензий.
- Обеспечить юридическую прозрачность и совместимость с другими проектами.
Apache License 2.0 — мощная и гибкая лицензия, которая предоставляет разработчикам свободу в использовании программного кода, обеспечивая при этом защиту интеллектуальной собственности и патентные гарантии. Она широко применяется в open-source проектах, включая Apache HTTP Server, Android и многие другие. Если вы хотите выпустить своё программное обеспечение с открытым кодом и предоставить пользователям гибкость в его использовании, Apache License 2.0 — один из лучших вариантов.
MIT License: Простота, Свобода и Популярность
MIT License (Massachusetts Institute of Technology License) — одна из самых популярных и простых в использовании открытых лицензий. Она широко применяется в мире open-source и используется множеством крупных проектов, включая React, Ruby on Rails и jQuery.
Лицензия MIT предоставляет разработчикам максимальную свободу при использовании программного кода, что делает её привлекательной как для коммерческих, так и для некоммерческих проектов.
Основные особенности MIT License
MIT License относится к категории «разрешительных» (permissive) лицензий, что означает минимальные ограничения на использование кода. Она позволяет:
- Свободно использовать код – Можно использовать программное обеспечение в любых целях, включая коммерческое применение.
- Изменять и распространять – Разрешено модифицировать код и распространять его, как в оригинальном, так и в изменённом виде.
- Лицензия минимально обременительна – Единственное требование — сохранение оригинального текста лицензии и упоминания авторов в распространяемом коде.
- Отказ от ответственности – Лицензия снимает с автора ответственность за возможные дефекты или ущерб, вызванный использованием кода.
Ограничения и условия использования
Хотя MIT License максимально свободна, она всё же накладывает несколько требований:
- Сохранение уведомлений – При распространении исходного или изменённого кода необходимо включать оригинальный текст лицензии и указание авторства.
- Отказ от ответственности – Лицензия не даёт никаких гарантий, и разработчик не несёт ответственности за возможные проблемы с программным обеспечением.
- Совместимость с коммерческими проектами – MIT License позволяет использовать её в закрытых (проприетарных) продуктах, что делает её удобной для бизнеса.
Отличия MIT License от других лицензий
- vs Apache License 2.0 – MIT проще и не содержит положений о патентах, в отличие от Apache License 2.0, которая включает защиту от патентных претензий.
- vs GPL (General Public License) – MIT License не требует, чтобы производные проекты также распространялись под той же лицензией, в отличие от GPL, которая обязывает распространять код с открытым исходным кодом.
- vs BSD-2-Clause, BSD-3-Clause – MIT очень похожа на BSD-лицензии, но BSD-3-Clause содержит дополнительный запрет на использование имени автора в рекламе.
Когда стоит выбирать MIT License?
MIT License идеально подходит для разработчиков, которые хотят:
- Открыть исходный код, но не накладывать строгих ограничений на его использование.
- Позволить коммерческое использование без требований к раскрытию исходного кода.
- Минимизировать юридические барьеры при использовании кода.
MIT License — это гибкая, простая и популярная лицензия, предоставляющая разработчикам и компаниям свободу в использовании программного кода. Благодаря своей краткости и ясности, она является одним из лучших выборов для open-source проектов. Если вы хотите максимально упростить распространение своего программного обеспечения и не накладывать лишних обязательств на пользователей, MIT License — отличный вариант.