Неотъемлемой частью жизни каждого человека давно стали персональные компьютеры. Для обеспечения высокой функциональности устройств разработчики создают программное обеспечение (далее – ПО), охватывающее любые потребности индивида, связанные с работой, учебой и развлечениями. Одни из таких ПО пишутся исключительно на коммерческой основе, другие же разработчики предпочитают делать свой продукт общедоступным, при этом цели у таких разработчиков могут быть совершенно разными, будь то просветительские или какие-либо еще [1]. Такое ПО принято называть свободным или открытым, но эти два понятия не эквивалентны.

Так, открытое ПО представляет собой общедоступный продукт с доступом также любого желающего и к исходному коду программы. Этот код может редактироваться, дополняться и распространяться дальше по желанию пользователей. «Открытость» продукта не подразумевает его бесплатность, однако большинство открытого ПО все же распространяется на безвозмездной основе [2].

Что же касается свободного ПО, то для него характерны все те же признаки, что и для открытого, однако автор исходного кода сохраняет за собой авторские права. Таким образом, свободное ПО базируется на так называемых «четырех свободах»: запуск, изучение, распространение и улучшение программного продукта [2].

Как и любой продукт человеческой мысли, программы можно и нужно регистрировать. Например, в работе [3] приведен пример получения свидетельства об официальной регистрации в Федеральном институте промышленной собственности. Как существуют патенты на изобретения, так существуют и лицензии на распространение программного продукта. Создатели могут делиться продуктом своей деятельности практически на любых, необходимых по их мнению, основаниях. Именно из-за вариативности требований разработчиков по ограничению и расширению прав пользователей относительно их программ, существует множество видов лицензий, отличия в некоторых из которых весьма незначительны. Рассмотрим основные из них.

Наиболее популярным видом лицензирования свободного ПО является GNU GPL (General Public License). Данный вид лицензирования преследует цель расширить права пользователей относительно прав, данных им и ограниченных по умолчанию законом об авторском праве. GNU GPL основано на «copyleft» («авторское лево»), которое использует законы об авторском праве [4]. Само понятие подразумевает, что дальнейшее распространение будет происходить на тех же самых основаниях, что и первоначальный продукт. Каждый «последователь», изменивший код программы и поделившись им, обязан по первому требованию предъявить пользователям уже свой код. При этом автор ПО не несет никакой ответственности за то, в каких целях будет использоваться его продукт и к каким последствиям это может привести в дальнейшем.

Еще одним распространенным видом лицензирования является Berkley Software Distribution, BSD («Программная лицензия университета Беркли»). Данное лицензионное соглашение впервые было применено для распространения UNIX-подобных операционных систем BSD [5]. BSD является примером другого вида свободной лицензии на ПО – пермиссивной лицензии. Это подразумевает то, что свобода действий пользователей почти не ограничена, то есть программы, созданные с использованием свободного ПО под пермиссивной лицензией могут лицензироваться под другие лицензии [4]. Также BSD позволяет повторное распространение ПО в виде оригинального кода либо двоичной формы, как с изменениями, так и без. Важно лишь соблюдение условий, где для повторного распространения исходного кода необходимо уведомление о правах автора, список его условий и последующий отказ от гарантий; в то время как для двоичного кода к этим условиям прибавляется также документация или другие материалы, поставляемые при распространении, в виде которых выполнен отказ от гарантий. Для продвижения продукта, основанного на исходном, требуется письменное разрешение организации или лица, его создавшего [5]. Лицензия BSD накладывает на пользователя значительно меньше ограничений, чем другие. Также BSD служит основой для многих других видов лицензий [6].

Lesser General Public License (LGPL) представляет собой «упрощенную» версию GPL. Данная лицензия допускает соединение лицензируемого кода с коммерческим программным кодом, при этом не возникает необходимости распространять готовую программу на условиях LGPL. Эта лицензия работает в отношении библиотек, под которыми понимается совокупность программных функций [7]. Для того, чтобы лицензированную программу можно было распространять, требуется указать на то, что в данной программе используется библиотека, лицензируемая LGPL и приложить копию лицензии, упомянуть автора такой библиотеки и создать условия, при которых пользователь может вносить изменения в библиотеку. Также LGPL не обязывает предоставлять исходный код всей программы [7].

Следующим видом лицензии является Mozilla Public License (MPL). Основная идея этой лицензии заключается в том, что она распространяется на файлы, содержащие исходный код или модификации к нему. И при создании и распространении таких модифицированных файлов, они должны быть тоже лицензированы на условиях MPL. Благодаря этому данная лицензия имеет более узкую сферу применения, позволяя использовать код, лицензируемый на условиях MPL, в классических коммерческих продуктах. То есть готовая программа может распространяться на любых условиях, а измененные файлы на условиях MPL. Стоит понимать, что если файл с исходным кодом просто добавить, то не вводится никаких ограничений [7].

Последним видом лицензий, который мы рассмотрим, является Apache Software License. Данная лицензия чаще всего используется для программ, разрабатываемых в рамках проекта Apache, многие из которых используются в инфраструктуре сети Интернет. Лицензируемые программы можно использовать для любых целей, свободно распространять в первоначальном или модифицированном виде при условии сохранения уведомления об авторском праве и предоставления копии данной лицензии [7]. Также Apache Software License требует выделения произведенных модификаций, что позволяет защищать репутацию первоначальных авторов. К тому же, данная лицензия допускает изменение лицензии распространения ПО и не настаивает на сохранение его открытого и бесплатного статуса [6].

Для наглядности сравнения видов лицензий мы приводим информацию о тех или иных требованиях в табл. 1 [8].

Сравнительная характеристика свободных лицензий

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

Статья будет полезна тем, кто хочет:

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

Первым делом — ссылка на LicenseIT, очень полезный сайт с описанием лицензий и особенностей их применения (в том числе в России), который я умудрился не найти при подготовке статьи. Исправляюсь. Спасибо sensboston за ссылку.

Авторское право

Для начала коротко о том, что вообще такое авторское право и лицензии.

Meanwhile in Russia

Если вы в качестве результата интеллектуальной деятельности создали некое произведение (например, программу), то в этом случае вы — его автор(ы). Вы обладаете имущественными и неимущественными правами на это произведение. Имущественные права на это произведение вы можете передать и кому-то другому, но передать неимущественные, в том числе авторство, у вас уже не получится. Быть автором — это ваше неотчуждаемое и непередаваемое право.

Даже если вы при создании произведения работали «на дядю», то и в этом случае автор вовсе не некое абстрактное ООО. Возможно, когда вы устраивались на работу, то подписывали в том числе и пункт про «отчуждение исключительных прав на результаты вашей интеллектуальной деятельности в пользу работодателя» в договоре или что-то подобное. Возможно, нет (в этом случае гуглите «Служебное произведение»). В обоих случаях автор — вы. И обладаете некоторыми правами.

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

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

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

Свободные лицензии

Определяем определение

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

  • Лицензия на программное обеспечение
  • Определение свободного программного обеспечения
  • Критерии Debian по определению свободного программного обеспечения
  • Свободная лицензия
  • Проприетарное программное обеспечение

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

Свободной лицензией является лицензия, которая соответствует неким критериям свободного ПО. Обычно используют либо определение свободного ПО, данное Ричардом Столлманом, либо критерии Debian по определению свободного программного обеспечения, сформулированные Брюсом Перенсом. Соответственно, те лицензии, которые не являются свободными — несвободные.

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

Читайте так же:  Пребывание в мечтах

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

Основные свободные лицензии
GPLv3 (GNU General Public License Version 3)
GPLv2 (GNU General Public License Version 2)

Как применять лицензии GNU со своими программами
Практическое руководство по соответствию GPL, спасибо Indexator за ссылку.
Как резонно заметил wholeman в комментариях, не хватает описания GNU GPL версии 2. О различиях между этими двумя версиями GPL можно почитать, например, в этой статье. Также, из комментария wholeman:
GPLv3 заметно строже и может создать некоторые проблемы автору. Например, одно из требований состоит в том, что должна быть предоставлена инструкция по установке изменённого приложения на устройство. Для приложений под iOS или WindowsPhone, где нет штатной возможности установить пакет не из магазина, выполнить такое требование проблематично. Кроме того, стоит заметить, что большинство программ, выпущенных, под GNU GPLv2, позволяют использование на условиях более поздней версии лицензии.

LGPLv3 (GNU Lesser General Public License Version 3, в девичестве GNU Library General Public License)
GNU AGPLv3 (GNU Affero, GNU Affero General Public License Version 3)

Как применять лицензии GNU со своими программами
Спасибо coh и lorus за то, что о ней вспомнили. Это копилефтная лицензия.

Цитируя Различные лицензии и комментарии к ним: Ее условия фактически состоят из условий GPLv3 с дополнительным параграфом в разделе 13, который позволяет пользователям, взаимодействующим с лицензируемой программой по сети, получать исходный текст этой программы. Мы рекомендуем разработчикам подумать о применении GNU AGPL для любых программ, которые обычно выполняются в сети. Есть определенные нюансы совместимости с другими версиями GPL: Обратите внимание, что GNU AGPL не совместима с GPLv2. Она также формально не совместима с GPLv3 в узком смысле: вы не можете взять исходные тексты, выпущенные на условиях GNU AGPL, и передавать или изменять их, как вам угодно, на условиях GPLv3, и наоборот. Однако вам позволено комбинировать раздельные модули или файлы исходного текста, выпущенные под обеими этими лицензиями, в едином проекте, что предоставит многим программистам разрешение на все действия, нужные им для того, чтобы делать какие им угодно программы.

MPL v2.0 (Mozilla Public License
Version 2.0)

Комментарий от lorus
Для проекта open source стоит ещё рассмотреть MPL 2.0. Своеобразная лицензия, что-то среднее между LGPL и BSD. От LGPL отличается отсутствием заморочек со статическим связыванием. Это может оказаться важным для программ на ЯП, в которых динамическое связывание не предусмотрено. В случае использования неизмененной библиотеки под MPL 2.0, как части большего проекта, нужно всего лишь указывать, где можно получить исходники этой библиотеки. Но если вы все же меняете код, то обязаны предоставить доступ к измененному вами коду под все той же MPL 2.0. То есть, лицензия копилефтная. Здесь небольшое уточнение от Athari:
Лицензией MPL заражаются файлы, а не проекты, в отличие от (L)GPL. Если изменить файл, он должен остаться под MPL. Если добавить — ограничений нет. В случае, если проект под GNU GPL, то необходимо сделать используемый в нем код под MPL 2.0 доступным сразу под обеими лицензиями.

Для использования этой лицензии в вашем проекте нужно добавить текст из Exhibit A лицензии
в качестве шапки в каждый файл исходного кода. Лицензия не требует указывать copyright в каждом файле, но и не запрещает этого. Также не забудьте добавить в проект файл LICENSE с текстом лицензии.

EPL-1.0 (Eclipse Public License Version 1.0)

По просьбе kidar2 добавляю лицензию EPL. Это копилефтная лицензия, но она не совместима с GNU GPL.

При распространении в форме исходного кода программа должна быть доступна под лицензией EPL.

Автору разрешается распространять программу в форме объектного кода под собственной лицензией, при условии, что: эта лицензия соблюдает условия EPL, явно отказывается от любых гарантий и ответственности от лица всех авторов, указывает, что исходные коды программы доступны у этого автора и объясняет, как их получить.

Применение к своему проекту: копия лицензии должна быть включена во все копии программы

Ms-PL (Microsoft Public License)

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

Обладает даже более слабым копилефтом, чем EPL: если вы распространяете исходные коды проекта, содержащие код под Ms-PL, то все исходные коды проекта должны распространяться под Ms-PL. При этом, распространение в форме объектного кода или бинарной форме позволяется под любой лицензией, не нарушающей Ms-PL. Кроме того, вы обязаны сохранять все копирайты, патенты, торговые марки и указания авторства оригинального кода. Да, лицензия регулирует патентные отношения.

Для применения к своему проекту: скопируйте текст лицензии в ваш проект (например, в файл LICENSE) и распространяйте его вместе с ним.

Существует миф, что лицензия MIT существует. Дело в том, что MIT (Massachusetts Institute of Technology) использовал много разных лицензий. Тот текст, который сейчас называют лицензией MIT, в оригинале являлся лицензией Expat, а еще ранее составлял большую часть лицензии X11. Эта лицензия — разрешительная, без копилефта. Она разрешает использование и изменение кода практически любым образом, при условии, что текст самой лицензии и указание авторства никуда не исчезнут, даже если вы разобьете изначальный проект на части. Также неоспоримое достоинство этой лицензии — небольшой размер. В качестве недостатка отмечают отсутствие регулирования патентных отношений. Из-за этого вместо нее GNU рекомендуют использовать другую разрешительную лицензию — Apache 2.0, а MIT предлагают использовать лишь для небольших проектов. Тем не менее, из разрешительных лицензий эта, пожалуй, самая известная.

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

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

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

Но при этом сама лицензия выдвигает следующие требования: made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below) copyright notice — это как раз строка, указывающая правообладателя. А «made available under the License, as indicated» означает, что еще должна быть явно указана лицензия. То есть, допустимо что-то вида:

Причем, совсем необязательно в исходном коде — Apache 2.0 позволяет для этого использовать файл NOTICE («or attached to the work»).

И еще о файле NOTICE: если в вашей работе вы используете чужой проект под лицензией Apache 2.0, содержащий свой файл NOTICE, то в этом случае вы обязаны копировать в производную работу содержимое файла NOTICE, в одно из трех мест: либо в аналогичный файл NOTICE, либо в исходные коды или документацию, распространяемую вместе с производной работой, либо в вывод производной работы (например в about-диалог); все согласно пункту 4 (d) лицензии. Заметьте, что, вопреки расхожему мнению, обязательного наличия файла NOTICE лицензия не требует.

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

Это разрешительная лицензия, схожая по смыслу с лицензией MIT. Оригинальная лицензия BSD состояла из 4-х пунктов, но, впоследствии, 3-й пункт, требовавший включать уведомление об авторстве во все рекламные материалы, был исключен. Кроме того, существует и двухпунктовая лицензия BSD, о которой напомнил Athari, в ней удален третий пункт, и эта версия практически совпадает по функциональности с лицензией MIT. GNU советуют вместо лицензии BSD использовать MIT, чтобы исключить путаницу с тем, какая именно версия лицензии BSD используется.

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

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

WTFPL Version 2

Как оказалось, весьма популярная на Хабре лицензия (спасибо Komzpa, Stasik0 и плюсовавшим). Кроме того, она присутствует в списке лицензий GNU, хотя они и постеснялись разместить ее текст на своем сайте.

Читайте так же:  Как оформить карту скидок

GNU классифицируют ее как разрешительную некопилефтную лицензию и не рекомендуют ее использовать без каких-либо объяснений. Вместо нее предлагаются MIT или Apache 2.0.

Могу предположить причины:

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

Чтобы применить ее к своему проекту — просто добавьте файл с лицензией в проект и не забудьте поменять в лицензии строку с копирайтом. Можно также добавить лицензию в шапку ко всем исходникам проекта.

wrote this file. As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
* — */

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

Как известно, «чрезмерное употребление пива вредит вашему здоровью». Но беда этой лицензии не в пиве. Обратите внимание на фразу

wrote this file. As long as you retain this notice. Теперь представьте, что вы изменили код этого файла. Или вы взяли код из этого файла, чтобы добавить в свой. Теперь фраза

wrote this file. является неверной, но вы обязаны ее сохранить! То есть, лицензия пытается отобрать у вас право указывать авторство произведения. А, например, в России автор имеет неимущественные и неотчуждаемые право авторства и право автора на имя. Получается, что такая лицензия, разрешая изменения и использование кода и запрещая указывать новых авторов, является незаконной (по-хорошему, нужно уточнить у юриста).

Общественное достояние (Public Domain)
CC0 (Creative Commons CC0)

Creative Commons CC0 — лицензия, которая пытается перевести проект в общественное достояние в максимальной форме, разрешенной законом. А если закон не позволяет это совершить, автоматически применяет положения разрешительной лицензии. GNU рекомендует применять CC0 в том случае, если вы хотите перевести вашу работу в общественное достояние.

Про применение CC0 к проекту можно прочитать в этой статье.

Про лицензию напомнил Athari. Эта лицензия появилась путем копипасты текста о передаче в общественное достояние и отказа от прав (waiver) проекта SQLite и отказа от гарантий из лицензии MIT. Аналогично лицензии CC0, Unlicense пытается перевести работу в общественное достояние и послужить в виде лицензионного договора на случай, если этого не произошло. Однако, эта лицензия менее проработана, чем CC0, из-за чего может являться нелегальной. Вот в этом вопросе на stackexchange подробнее. Вкратце, там указано, что лицензия явно нелегальна, например, в Германии, так как там, похоже, нет понятия общественного достояния. А Unlicense, в отличие от CC0, не отказывается от перевода в общественное достояние для случая, когда это противоречит закону. Кроме того лицензия как минимум нелогична (или даже противоречива), так как передача в общественное достояние, заявленная в первой строке, в случае успеха делает невалидными параграфы, следующие за ней.

Для применения Unlicense нужно добавить файл с текстом лицензии к вашему проекту. Авторы лицензии рекомендуют назвать файл UNLICENSE.

Copyright в исходниках

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

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

Но все же такой заголовок лучше иметь. Основные причины следующие:

  • Он четко показывает, что права на код кому-то принадлежат. Отмазки вида «я не знал, там не написано, не смог найти, не заметил» уже не прокатят. Иначе говоря, наличие такого заголовка предотвращает случайное неправомерное использование кода, а также может увеличить ответственность за намеренное.
  • Дает возможность идентифицировать владельца прав на код, чтобы связаться с ним в том числе и по вопросам правомерности использования этого кода.

Между прочим, это имеет смысл не только для open-source проекта. Указание владельца прав и авторства может помочь и проприетарному коду в том случае, если он каким-либо образом утечет в сеть.

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

  • Copyright — так как в некоторых странах одного символа копирайта недостаточно для юридической значимости уведомления.
  • © — символ копирайта, в большинстве стран он необходим и достаточен для придания юридической значимости уведомлению. Простой буквы c в скобках ( c ) для этого может быть недостаточно. Используйте уже Unicode!
  • 2007, 2009, 2010 – 2012 — «годы жизни» кода, первое число — год, когда продукт был впервые опубликован, далее — годы, когда код обновлялся. Если годы, когда код в файле правился, идут не подряд, то их нужно указывать через запятую.
  • John Doe — имя владельца авторских прав. Не автора, это могут быть разные лица! Может быть именем человека, названием компании, или именами нескольких человек. Правда, в последнем случае лучше сделать отдельную строчку на каждого человека.
  • All rights reserved — «все права защищены», означает, что указанные лица обладают всеми правами на код. Дополнительное усиление уведомления копирайта, в случае обладания исключительными правами.
  • Если возможно, то дать ссылку на лицензионный договор или указание, где его искать.
  • Указать контактные данные.

Обратите внимание, что имя автора в уведомление не входит. Автора/авторов можно указать отдельно, например, на следующей строке, в свободной форме (например Author: Jane Doe).

Ну и, на всякий случай, примеры

Разместить ваш проект в интернете и написать «пользуйтесь все!» еще недостаточно для того, чтобы им действительно начали пользоваться. И речь не о рекламе или полезности конкретного проекта. Часто необходимо четкое понимание, как можно и как нельзя использовать проект, особенно, если цели использования — коммерческие. В том числе, слова «пользуйтесь все» вряд ли удастся представить договором с правообладателем в случае каких-либо проблем.

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

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

Лицензия, даже свободная, является договором между правообладателем и пользователем. Старайтесь рассматривать это именно так.

В чём разница между популярными Open Source лицензиями? Объясняет Github

В сентябре Github добавила на страницы проектов, которые используют стандартные Open Source лицензии, секцию, в которой эта лицензия указывается:

После переработки условий использования сервиса, которые прояснили (наконец-то) правовой статус GitHub относительно проектов, которые он хранит, компания решила пойти дальше в том, чтобы помочь пользователям разобраться, на что они имеют право, а на что — нет. С этой целью на страницу просмотра файла LICENSE из корневой директории проекта были добавлены краткие сведения о лицензии с сайта Choose A License:

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

  1. Первая содержит информацию о том, что лицензия вам разрешает делать с проектом (авторское право или закрытые лицензии обычно, напротив, запрещают делать это);
  2. Вторая — о том, какие ограничения лицензия накладывает на тех, кто модифицирует или распространяет работу;
  3. Последняя – о том, чего лицензия не гарантирует и чего не разрешает.

Пояснения некоторых значений таблиц

Разрешения * распространять, * использовать в коммерческих целях или * изменять работу значат ровно то, что написано — вы можете пользоваться этими правами, но лишь до тех пор, пока соблюдаете условия, указанные в секциях * «Требует» и * «Запрещает».

Пункт * «Разрешает личное использование» (англ. private use) означает, что если вы изменяете работу, вы не обязаны её распространять — на своей машине вы можете делать с кодом всё, что захотите.

Пункт * «Предоставление патентных прав» означает что соавторы работы (контрибьюторы) отказываются от патентных прав (если они есть) на те части кода, которые они добавили; это гарантирует безопасность при использовании работы — иск на вас точно не подадут.

Читайте так же:  Госпошлина за паспорт в 2018 году образец

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

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

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

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

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

Mozilla Public License 2.0

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

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

The MIT License

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

Apache License 2.0

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

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

А как же остальные лицензии? Как же BSD?

Этого набора более чем достаточно, если вы хотите выбрать лицензию для своего Open Source проекта — не надо писать свою лицензию или использовать что-то более специфическое. Путаница, которая возникает из-за обилия лицензий и их совместимости друг с другом — актуальная проблема Open Source. Лицензия BSD достаточно популярна, но её сокращённый вариант полностью совпадает по смыслу с лицензией MIT, и GNU советуют использовать именно последнюю. Если же вы столкнулись с проектом, который использует какую-то нестандартную лицензию, и хотите узнать, что она вам разрешает, вы можете подсмотреть в шпаргалке на сайте Choose A License.

Пётр Соковых, транслятор двоичного кода в русский язык

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

Характеристики лицензий:
1. Apache Software License
2. Лицензия BSD
3. GNU General Public License
4. Лицензии MIT
5. Mozilla Public License
6. Консорциум Всемирной паутины

Apache Software License

Apache Software License — лицензия на свободное программное обеспечение Apache Software Foundation.

«плюсы»
— право использовать программное обеспечение для любых целей, свободно распространять, изменять, и распространять изменённые копии
— не ставит условием неизменность лицензии распространения программного обеспечения
— не настаивает даже на сохранении его бесплатного и открытого статуса
— совместимость с GPL

«минусы»
— информировать Apache о факте использования исходного кода, лицензированного под лицензией Apache
— при распространении программного обеспечения необходимо поместить файлы LICENSE и NOTICE в корневую директорию (в каждом лицензируемом файле должна быть сохранена вся исходная информация о копирайтах или патентах, в каждый изменённый файл должна добавляться информация о проведённых изменениях)

Лицензия BSD

Лицензия BSD, Программная лицензия университета Беркли (англ. BSD license) — это лицензионное соглашение, впервые применённое для распространения UNIX-подобных операционных систем BSD.

«плюсы»
— одна из самых популярных лицензий для свободного программного обеспечения и используются для многих программ
— разрешается повторное распространение и использование как в виде исходного кода, так и в двоичной форме, с изменениями или без (при некоторых условиях, которые можно найти в «модифицированной» лицензии BSD)
— по сравнению с другими распространёнными лицензиями на свободное программное обеспечение (например, GNU General Public License) лицензия BSD налагает меньше ограничений на пользователя
— BSD допускает проприетарное коммерческое использование ПО
— много лицензий произошли от BSD или они аналогичны ей

«минусы»
— права на исходный дистрибутив BSD официально принадлежат «попечителям университета Калифорнии»

GNU General Public License

GNU General Public License (иногда переводят, как, например, Универсальная общественная лицензия GNU, Универсальная общедоступная лицензия GNU или Открытое лицензионное соглашение GNU) — лицензия на свободное программное обеспечение, созданная в рамках проекта GNU в 1988 г.

«плюсы»
— лицензируя работу на условиях GNU GPL, автор не отказывается от права считаться её автором
— свободу запуска программы, с любой целью
— свободу изучения того, как программа работает, и её модификации (предварительным условием для этого является доступ к исходному коду)
— свободу распространения копий
— свободу улучшения программы, и выпуска улучшений в публичный доступ (предварительным условием для этого является доступ к исходному коду)

«минусы»
— GNU GPL требует распространения с двоичными файлами (в том числе неизменными) исходного кода или письменного обязательства его предоставить

Лицензии MIT

Лицензия MIT (англ. MIT License) — группа лицензий, разработанных Массачусетсским технологическим институтом для распространения свободного программного обеспечения.

«плюсы»
— лицензии не являются «копилефтом»
— поскольку копирайт на данную лицензию отсутствует, другие группы имеют право использовать и изменять её для удовлетворения своих целей
— явно говорит о правах конечного пользователя, включая права использования, копирования, изменения, включения в другой исходный код, публикации, распространения, сублицензировании и/или продажи лицензированного ПО
— лицензия считается академической лицензией, то есть признана годной к использованию в сфере научных разработок

«минусы»
— лицензия MIT более всего соответствует трёхпунктной Лицензии BSD

Mozilla Public License

Mozilla Public License (сокращенно MPL) — одна из лицензий на свободное программное обеспечение. Версия 1.0 была разработана Митчел Бэйкер (Mitchell Baker), во время её работы адвокатом в Netscape Communications Corporation. Версия 1.1 была разработана в рамках Mozilla Foundation. MPL содержит в себе черты модифицированной лицензии BSD и GNU General Public License.

«плюсы»
— MPL одобрена в качестве открытой лицензии Open Source Initiative
— лицензия MPL обеспечивает слабый копилефт
— адаптирована другими разработчиками, в особенности Sun Microsystems

«минусы»
— исходный код, скопированный или изменённый под лицензией MPL, должен быть лицензирован по правилам MPL
— Фонд свободного программного обеспечения не рекомендует использовать MPL в чистом виде, то есть без использования множественного лицензирования совместно с GPL или совместимой с ней лицензией
— код под лицензией MPL может быть объединен в одной программе с проприетарными файлами (например, Netscape 6 и 7 представляли собой проприетарные версии Mozilla Suite, а начиная с версии 8 — Mozilla Firefox. Таким образом, AOL Time Warner обладает эксклюзивными правами на эти проприетарные версии Netscape)

Консорциум Всемирной паутины

Консо́рциум Всеми́рной паути́ны (англ. World Wide Web Consortium, W3C) — организация, разрабатывающая и внедряющая технологические стандарты для Всемирной паутины. Консорциум возглавляет Тим Бернерс-Ли — автор множества разработок в области информационных технологий.

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

«минусы»
— любой стандарт W3C проходит 4 стадии согласования (рабочий проект, последний созыв, возможная рекомендации и предлагаемая рекомендация)

upd: Спасибо за дополнения whitedragon: