Меню Закрыть

Лицензия gplv2 что это

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Более
5500 человек являются участниками сообщества Смартсорсинг на данный момент

Войти с помощью:

Новым пользователям

Что такое лицензии на открытое программное обеспечение: GPL и все остальные

Компания использует открытое программное обеспечение — значит, не требуется его учитывать и управлять лицензиями? Как бы не так! Среди открытого программного обеспечения существует множество разновидностей лицензий. Самая популярная лицензия — GPLv2 закрывает всего чуть больше 45% программного обеспечения. Различные лицензии могут оговаривать необходимость оплаты за коммерческое использование продуктов, а также содержать другие существенные ограничения.

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

Впрочем, проблема еще и в разнообразии открытых лицензий.

Лицензия gplv2 что это

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

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

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

Первым делом — ссылка на 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).

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

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

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

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

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

Лицензия gplv2 что это


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

UPD: опубликован перевод небольшого куска официального GPL FAQ habrahabr.ru/blogs/Dura_Lex/45878
UPD2: скорректирован и переформулирован список совместимых лицензий

Если касаться мира «свободных» лицензий, то основным столпом и стержнем можно посчитать GNU General Public License (GPL). И в этой статье я хотел бы разделить лицензии, которые попадают под GNU GPL и описать все другие, которые не попадают под условия этой лицензии. Первая часть статьи будет описывать саму GNU GPL, ее краткую историю, другие лицензии, которые похожи на нее. В конце я приведу небольшой словарик терминов и сокращений.

GNU General Public License

Вначале хотелось бы пояснить что такое «GNU». GNU расшифровывается как «GNU’s not UNIX» — это рекурсивный акроним придуманный Ричардом Столлманом, известным идеологом открытого и свободного программного обеспечения. Такое название было придумано для операционной системы, которую в 80-х годах разрабатывал Столлман. История GNU заслуживает отдельной статьи поэтому я перейду сразу к делу.

GNU General Public License или открытое лицензионное соглашение GNU — это лицензия, первый вариант которой датируется 1 февраля 1989 года (википедия сообщает о 1988 г, но я считаю дату которая стоит на оригинале). На сегодняшний день существует четыре варианта лицензии, которые нумеруются в порядке появления.

Основными позициями GNU GPL v1.0 стали следующие требования:

  • предоставление исходных кодов, доступных для изучения, к бинарным кодам публикуемым с данной лицензией;
  • наследование лицензии в случае модификации исходного кода, то есть модифицированный или объединенный с другим код в результате так же должен быть выпущен под лицензией GNU GPL, следовательно, быть доступным для модификации любым желающим.

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

Вторая версия лицензии датируется 1991 годом и основным мотивом провозглашает (согласно wiki) принцип «Liberty or Death» (Свобода или Смерть). Этот принцип заключен в седьмом и восьмом пункте соглашения:

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

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

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

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

8. В том случае если распространение и/или использование Программы в отдельных государствах ограничено соглашениями в области патентных или авторских прав, первоначальный правообладатель, распространяющий Программу на условиях настоящей Лицензии, вправе ограничить территорию распространения Программы, указав только те государства, на территории которых допускается распространение Программы без ограничений, обусловленных такими соглашениями. В этом случае такое указание в отношении территорий определенных государств признается одним из условий настоящей Лицензии.[1]

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

GNU Lesser GPL v2.1

Данная версия лицензии датируется 1999 годом и содержит одно огромное отличие от обычной лицензии GNU GPL: предназначенная для библиотек, лицензия позволяет использовать их в проприетарном программном обеспечении. Например, библиотеки GNU C распространяются под лицензией GNU Lesser GPL v2.1, для того, чтобы сторонние разработчики могли использовать их в своем ПО, свободном или коммерческом.

Последняя на сегодняшний день версия GPL, которая вышла в 2007 году. Изменения, внесенные в лицензию, были призваны оградить пользователей лицензии от судебных исков связанных с патентами, теперь создатели программы не могу подать в суд на пользователя. GPL 3.0 запрещает применять лицензию к программному обеспечению, которое запрещено «обходить» некоторыми законами и директивами (Digital Millennium Copyright Act и the European Union Copyright Directive). То есть, нельзя выпустить под лицензией любое ПО, попадающее под действие этих директив. Таким образом, GPL 3.0 заботится о том, чтобы любое ПО, выпущенное под ее лицензией, можно было свободно модифицировать, обходить или изменять.

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

Вместе с GPL 3.0 вышла так же обновленная версия GNU Lesser GPL 3.0, которая продолжает отличаться тем, что позволяет использовать свободные библиотеки в закрытом ПО.

Многие лицензии практически повторяют принципы, заложенные в GPL и отличаются, в принципе, только тем, что приняты коммерческими или другими организациями. Ниже я постараюсь свести такие лицензии под определенные версии GPL. Совместимость означает то, что отдельные части ПО с лицензией совместимого типа можно выпускать в комплексе с GPL-частями и под одной GPL лицензией.

Совместимые только с GPL 3.0 лицензии

GNU Affero General Public License (AGPL) v3 — содержит пункт о том, что пользователи, которые взаимодействуют с программой по сети, так же должны иметь возможность получать исходные коды;
Apache License, Version 2.0;
Educational Community License 2.0;
Freetype Project License;
Microsoft Public License (Ms-PL);
XFree86 1.1 License;

Совместимые с GNU GPL лицензии (как с v2 так и с v3 версией)

Artistic License 2.0;
Berkeley Database License (aka the Sleepycat Software Product License);
Boost Software License;
Modified BSD license;
CeCILL version 2;
Cryptix General License;
Eiffel Forum License, version 2 — предыдущие версии не были совместимы;
Expat License;
FreeBSD license;
Лицензия the iMatix Standard Function Library;
Independent JPEG Group License;
Лицензия imlib2;
Intel Open Source License;
ISC License;
NCSA/University of Illinois Open Source License;
Лицензия Netscape Javascript;
OpenLDAP License, Version 2.7;
Лицензия Perl 5 и ниже;
Public Domain;
Лицензии Python 2.0.1, 2.1.1, и более новые версии;
Лицензия Ruby;
Standard ML of New Jersey Copyright License;
Unicode, Inc. License Agreement for Data Files and Software;
W3C Software Notice and License;
X11 License — иногда ошибочно называют MIT license.

Совместимые с Lesser GPL лицензии

eCos license version 2.0.

GNU — рекурсивный акроним GNU’s Not Unix;
GNU GPL — открытое лицензионное соглашение GNU;
Проприетарное ПО — программное обеспечение, которое имеет ограничения в использовании и закрыто для модификации, другими словами «несвободное ПО»;
Тивоизация — термин который введен по названию прибора TiVo, на котором стоял Linux под GPL 2.0, который не было возможности модифицировать.
Copyleft — термин который противопоставляют «copyright», предполагает права на полный доступ к исходным кодам программного обеспечения, которые могут использоваться только для создания настолько же свободного ПО.

Используемые источники

В следующей статье, я постараюсь рассмотреть философию BSD-лицензий, чем отличаются BSD-лицензии от GPL и какие лицензии несовместимы с GPL (которые, следовательно, можно считать не полностью открытыми и свободными). Кроме того, я коснусь лицензий которые описывают документацию и отличные от программного обеспечения вещи.

Почему GPL v2? Часто задаваемые вопросы

1. Какие изменения вносятся в лицензирование?

Sun предлагает ввести GPLv2 с исключением Classpath для программного обеспечения NetBeans в качестве второй возможности для лицензирования, наряду с CDDL. GPL v2 предполагает лицензию с открытым исходным кодом. Текст лицензии доступен по адресу http://opensource.org/licenses/gpl-license.php.

2. Зачем Sun необходимо двойное лицензирование программного обеспечения NetBeans через CDDL и GPLv2 с исключением Classpath?

Лицензия GPL v2 дает дополнительную возможность поставщикам, которые не могут работать с программным обеспечением NetBeans по лицензии CDDL.

Дополнительная возможность лицензирования в качестве GPLv2 сделает работу программного обеспечения NetBeans с Linux еще удобнее.

Добавление GPLv2 с исключением Classpath в программное обеспечение NetBeans обеспечит согласованность портфелей продуктов и файлов ресурсов. Sun ввела открытый код для реализации JDK в GPLv2, обеспечив двойное лицензирование проекта GlassFish через CDDL и GPLv2 с исключением Classpath.

3. Что такое исключение Classpath?

Исключение Classpath было разработано в рамках проекта GNU/Classpath Free Software Foundation (обратитесь к http://www.gnu.org/software/classpath/license.html). Оно позволяет привязать приложение, доступное по любой лицензии, к библиотеке, являющейся частью программного обеспечения, лицензированного по GPL v2. При этом на приложение не распространяется требование GPL о публичном предложении GPL.

4. Почему необходимо исключение Classpath?

Если приложение требуется распространить с элементами программного обеспечения NetBeans для GPL v2, к этому приложению применимы требования GPL, предполагающие, что любой код, предоставляемый в рамках «работ на основе программы [GPL]», также подлежит лицензированию GPL. Соответственно, исключение лицензии GPL позволяет избежать требований по лицензированию для любых приложений, связанных с реализацией GPL. Это обеспечивается исключением Classpath. Например, такая возможность важная для разработчиков модулей, которые всегда ссылаются на интерфейс API NetBeans, а также для разработчиков, создающих приложения на базе платформы NetBeans.

5. Как добавление GPL v2 повлияет на текущие дистрибутивы?

Это не повлияет на текущие дистрибутивы. Текущие и последующие дистрибутивы также будут доступны для CDDL. Начиная с выпуска NetBeans 6.0, новые дистрибутивы будут доступны как для CDDL, так и для GPLv2 с исключением Classpath.

6. Каким образом возможны выпуски для двух лицензий?

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

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

НКО | Лицензии для открытых и бесплатных проектов. Все что нужно знать о лицензировании, чтобы не нарушить закон

Подпишись
на рассылку

Лучшие публикации Теплицы, доставленные на твой email

Подпишись
на Теплицу(Pro)

Не пропусти лучшие новости для экспертов в области IT, активистов, дизайнеров

Подпишись
в Фейсбуке

Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий

Подпишись
ВКонтакте

Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий

Подпишись
в Телеграм

Не пропусти лучшие публикации Теплицы, руководства, анонсы мероприятий

Подпишись
на YouTube

Не пропусти видео-уроки, скринкасты, записи вебинаров и мероприятий

Екатерина Изместьева

Всего материалов: 711

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

Выбрать лицензию для вашего проекта, перевести произведение в общественное достояние и правильно указать copyright в исходниках – на сайте Habrahabr опубликовали подробный материал об авторском праве и свободных лицензиях на ПО.

Поделитесь этой статьей с друзьями и коллегами

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

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

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

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

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

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

GPLv3 (GNU General Public License Version 3)

Самая известная из свободных лицензий. Так как она называется свободной, многие ошибочно считают, что код, выпущенный под GPL, можно использовать как угодно, а программы могут/должны быть только бесплатными. И то, и другое неправда. GNU GPL – копилефтная лицензия и требует, чтобы исходные коды производных работ были открытыми под ней же.

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

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

GPLv2 (GNU General Public License Version 2)

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

GPLv3 заметно строже и может создать некоторые проблемы автору. Например, одно из требований состоит в том, что должна быть предоставлена инструкция по установке измененного приложения на устройство. Для приложений под iOS или WindowsPhone, где нет штатной возможности установить пакет не из магазина, выполнить такое требование проблематично.

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

LGPLv3 (GNU Lesser General Public License Version 3)

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

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

GNU AGPLv3 (GNU Affero, GNU Affero General Public License Version 3)

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

Есть определенные нюансы совместимости с другими версиями GPL:

Обратите внимание, что GNU AGPL не совместима с GPLv2. Она также формально не совместима с GPLv3 в узком смысле: вы не можете взять исходные тексты, выпущенные на условиях GNU AGPL, и передавать или изменять их как вам угодно, на условиях GPLv3 и наоборот.

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

MPL v2.0 (Mozilla Public License Version 2.0)

Для проекта open source стоит еще рассмотреть MPL 2.0. Своеобразная лицензия, что-то среднее между LGPL и BSD. От LGPL отличается отсутствием заморочек со статическим связыванием. Это может оказаться важным для программ на ЯП, в которых динамическое связывание не предусмотрено.

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

Лицензией MPL заражаются файлы, а не проекты, в отличие от (L)GPL. Если изменить файл, он должен остаться под MPL. Если добавить – ограничений нет.

В случае если проект под GNU GPL, необходимо сделать используемый в нем код под MPL 2.0 доступным сразу под обеими лицензиями.

Для использования этой лицензии в вашем проекте нужно добавить текст из Exhibit A лицензии

This Source Code Form is subject to the terms of the Mozilla

Public License, v. 2.0. If a copy of the MPL was not distributed

with this file, You can obtain one at //mozilla.org/MPL/2.0/.

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

EPL-1.0 (Eclipse Public License Version 1.0)

Это копилефтная лицензия, но она не совместима с GNU GPL.

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

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

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

Ms-PL (Microsoft Public License)

Копилефтная лицензия, несовместимая с 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 лицензии нам предлагают добавлять в качестве шапки в каждый файл исходного кода следующий текст:

Copyright [yyyy] [name of copyright owner]

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

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.

Но при этом сама лицензия выдвигает следующие требования:

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» означает, что еще должна быть явно указана лицензия. То есть допустимо что-то вида:

Copyright [yyyy] [name of copyright owner]

Licensed under the Apache License, Version 2.0

Причем совсем не обязательно в исходном коде – 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, в ней удален третий пункт, и эта версия практически совпадает по функциональности с лицензией MIT. GNU советуют вместо лицензии BSD использовать MIT, чтобы исключить путаницу с тем, какая именно версия лицензии BSD используется.

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

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

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

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

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

CC0 (Creative Commons CC0)

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

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

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

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

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

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

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

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

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

// Copyright © 2022 John Doe // Copyright © 2023-2028 Jane Doe // Copyright © 2028-2096 Acme Corporation. Contacts: // License: //opensource.org/licenses/MIT

Полезные ссылки

Описание лицензий и особенностей их применения (в том числе в России) – LicenseIT . Большой список свободных лицензий на сайте GNU . Список с open-source лицензиями на английском языке.