Что нужно знать про лицензии GitHub: как выбрать и добавить

GitHub лицензии — о чем речь?

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

Например, если фирма в своей деятельности будет работать с каким-либо бесплатным офисом (например, LibreOffice), то для проверяющих она должна уметь доказать, что имеет право так делать. Для этого достаточно будет предъявить соответствующую лицензию. Если разработчик забудет её сформулировать, то фирма может оказаться в сложном положении.

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

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

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

Зачем нужно лицензирование Open Source проектов на GitHub

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

1. Условия использования программы. Они могут предусматривать внесение платы или в некоторых, или во всех случаях, разрешать бесплатное использование.
2. Иногда программы создаются для того, чтобы их развивало сообщество. В этом случае важно, чтобы с программными текстами могли ознакомиться все желающие.
3. Когда тексты программы доступны, некоторые могли бы внести изменения, сделав программу функциональной и как можно более надёжнее. Иногда автор может разрешить это делать всем желающим, в других случаях предлагает присылать изменение ему, а вносит коррективы в проект самостоятельно.
4. Нужно решить, могут ли третьи лица вносить изменения в проект и предлагать от своего имени. При этом необходимо указать, с какой лицензией должен быть их продукт.

Решая эти и аналогичные вопросы автор приложения фактически во многом определяет дальнейшую судьбу созданного им программного продукта.

Какие виды лицензий существуют

Лицензия представляет собой договор, в котором одна сторона (лицензиар) устанавливает правило использования другой стороной (лицензиатом) созданного им продукта. На практике речь идёт не о подписании документа сторонами, а об автоматическом согласии с соответствующими правами и обязанностями по факту его использования.

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

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

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

Лицензии, используемые на Git Hub чаще всего:

Программисту предстоит суметь выбрать такую, которая будет соответствовать его планам. Чтобы это сделать правильно, нужно разбираться в том, какие особенности присущи определённым видам.

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

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

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

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

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

1. https://choosealicense.com/. На этом сайте имеются наводящие вопросы для выбора подходящего варианта и подробные консультации, помогающие понять особенности использования.
2. Страница https://opensource.org/licenses посвящена рассмотрению различных свободных решений для программного обеспечения.
3. Сайт https://tldrlegal.com/ можно рассматривать в качестве энциклопедии для различных вариантов лицензий. Здесь имеются как точные юридические формулировки, так и подробные комментарии.

Однако, наиболее продуктивным способом выбора является внимательное чтение соответствующих юридических документов. Хотя речь идёт о трудоёмкой деятельности, тем не менее, изучение текстов даст разработчику все необходимые ответы.

Как добавить лицензию на Github

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

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

1. Нужно перейти на главную страницу своего репозитория.
2. Нужно нажать на кнопку для добавления файла, затем выбрать «Create new file».
3. Далее нужно ввести имя файла. Для лицензии это может быть один из двух вариантов: LICENSE или LICENCE.md. Здесь применение заглавных букв является обязательным.
4. Справа от поля ввода имени файла кликают для выбора шаблона лицензии.
5. В меню в левой части страницы выбирают строку «Add a license to your project». При этом выбирают вариант из уже существующих документов.
6. Затем кликают по строке «Review and submit». После этого вводят свои детали соглашения.
7. После этого необходимо уточнить, в чём состояли сделанные дополнения или изменения. Далее указывают, производилась ли корректировка выбранного документа или речь идёт о создании другого варианта лицензии.

Подтвердив внесённые изменения, разработчик завершает процедуру внесения изменений в список лицензий на сервисе Git Hub.

Choose a license Github — примеры популярных лицензий на Git Hub

Далее будут рассмотрены те варианты, которые являются наиболее популярными. Разобравшись в их сильных и слабых сторонах, программист сможет найти нужный вариант или понять, как эффективно производить поиск.

GPL

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

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

Самой поздней из них является третья. GPL была использована разработчиками таких программ, как система управления веб-контентом Drupal, система управления базами данных MariaDB, векторный графический редактор InkSkape и некоторых других.

Интересно отметить, что SQL использует не только GPL, но и коммерческую лицензию.

LGPL

Это название переводится как «Меньшая стандартная общественная лицензия GNU GPL». Некоторым разработчикам GPL не подходит, так как создаёт для них обязанность распространять модифицированные продукты под той же лицензией.

Особенности применения этого варианта можно проиллюстрировать тем, как происходит процесс лицензирования применения библиотек созданных программистом. При этом принято рассматривать следующие три варианта:

1. Когда библиотека обеспечивает выполнение новых функций, причём никакие коммерческие библиотеки не могут выполнить аналогичную задачу, то в этом случае оптимальным является применение GPL.
2. Разработчик в свободной библиотеке уже реализовал существующий стандарт. В этой сфере имеются коммерческие варианты с аналогичными функциями. Для этого случае будет удобно выбрать LGPL.
3. Когда речь идёт о новом стандарте, который фактически находится в конкуренции с коммерческим, здесь подойдёт применение лицензии Apache.

В этом стандарте допускается коммерческое использование библиотек. Если производятся модификации, необходимо для распространения использовать такие же условия. Однако простое использование кода допускает изменение условий.

Eclipse Public License

Этот документ разрешает распространение под другими лицензиями, в том числе и коммерческими.

Основным условием является то, что в модифицированных работах нововведения будут вынесены в отдельный модуль. Эта лицензия приобрела популярность при разработке продуктов на Java. В качестве примера можно привести язык программирования Clojure, фреймворк для тестирования приложений на java.

Mozilla Public License

Некоторые рассматривают этот документ как компромисс между GPL и коммерческими лицензиями. Требованием MPL является наличие открытого доступа к определённым файлам. В программном продукте могут быть одни файлы под этой лицензией, а другие — без неё.

После модификации разрешается поставить ту лицензию, которая нужна (например, речь может идти о коммерческой), однако это возможно только при условии, что доступ к файлам, выпущенным под MPL будет по-прежнему открытым.

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

Apache License Github

AL принято называть либеральной свободной лицензией. Эта особенность связана с тем, что здесь отсутствует требование выпускать производный продукт под теми же условиями, что и раньше. Этим документом активно пользуется компания Apache Software Foundation.

При её применении разрешено следующее:

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

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

Это можно продемонстрировать, перечислив известные программные продукты, которые выпускаются под этим видом лицензии: операционная система Android, фреймворк, с помощью которого создаются корпоративные приложения на Java, веб-сервер Apache.

MIT Licence

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

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

Программными продуктами, которые используют этот документ являются: библиотека JavaScript под названием JQuiery, текстовый редактор Atom, AngularJS – фреймворк для разработки на JavaSсript.

Подводные камни

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

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

При распространении под MPL те, кто вносил изменения в код, не могут файлы под MPL предлагать под другой лицензией. Использование нового документа будет относиться к другим программным модулям.

Если вам понравилась статья, то подписывайтесь на мой телеграм канал.