что такое серверная лицензия creation

Лицензировать Creatio

Доступ к функциональности Creatio получают только лицензированные пользователи.

Этапы лицензирования в Creatio:

Эти операции выполняются в разделе Менеджер лицензий (Рис. 1).

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

На заметку. Чтобы просматривать, раздавать и отзывать лицензии, у вас должны быть настроены права доступа на выполнение системной операции “Управление лицензиями пользователей” (код “CanManageLicUsers”). Подробнее: Настроить права доступа на системные операции.

Добавить лицензии в приложение

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

При покупке лицензий, продлении действия существующих лицензий и обновлении on-site приложения Creatio:

Начиная с версии 7.17.4 данную процедуру необходимо выполнять также и при обновлении on-site приложения Creatio на новую версию.

Сформировать запрос на получение лицензий

Нажмите кнопку Сформировать запрос (Рис. 2).

В результате будет создан и загружен файл запроса лицензий в формате *.tlr.

Запросить лицензии также можно в разделе Пользователи системы по действию Запросить лицензии (Рис. 3).

Загрузить лицензии в приложение

Нажмите Действия —> Загрузить (Рис. 4).

Запросить лицензии также можно в разделе Пользователи системы по действию Загрузить лицензии (Рис. 5).

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

Распределить лицензии между пользователями

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

В Creatio используются следующие типы лицензий:

Кликните по названию продукта.

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

Нажмите кнопку Добавить и выберите пользователей, которым вы хотите выдать лицензии (Рис. 8).

Обратите внимание, что число указанных пользователей не должно быть больше количества лицензий. Количество доступных/использованных лицензий можно отслеживать на круговой диаграмме в левой части экрана (Рис. 8).

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

Чтобы отозвать лицензии, выберите пользователей из списка и нажмите кнопку Отозвать лицензии (Рис. 9).

Вы также можете навести курсор на строку с именем пользователя, у которого вы хотите отозвать лицензию, и нажать кнопку (Рис. 10).

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

Удалить лицензии в приложении

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

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

Источник

Разбираемся в лицензиях клиентского доступа Microsoft (CAL): какие они бывают и сколько их нужно

В организациях, как правило, используется один или несколько серверов, на которых установлены ОС Windows Server и некоторые сервисы (SQL-сервер для баз данных, Exchange-сервер для почты, календарей и т. д.), которыми пользуются сотрудники. Для того, чтобы использование ИТ-инфраструктуры было законным и, соответственно, не повлекло рисков, необходимо иметь лицензии как для серверов, так и для клиентов.

Что такое клиентская лицензия?

Клиентская лицензия (или CAL — Client Access License) даёт пользователям за их устройствами законное право на доступ к установленному на сервер программному обеспечению Microsoft для серверов — самой Windows, SQL-сервера, Exchange-сервера.

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

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

Но многие не знают, что корпорация Microsoft больше не поставляет клиентские лицензии (CAL) в составе с операционными системами Windows Server, лицензированными по каналу OEM.

Какие бывают клиентские лицензии и чем они отличаются?

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

Лицензии CAL на пользователя (User CAL)

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

Лицензии CAL на устройство (Device CAL)

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

Что, если в компании несколько серверов?

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

Для каких редакций Windows Server нужны клиентские лицензии?

Клиентские лицензии Windows Server 2019 можно использовать и для более ранних версий Windows Server.

Нужны ли CAL-лицензии, если пользователи/устройства не подключаются к серверному ПО Microsoft напрямую?

В компании может использоваться определенный серверный продукт для кадрового управления, бухгалтерского учёта и т. д. с собственной системой лицензирования. Если этот продукт сам по себе обращается к серверному ПО Microsoft — например, SQL Server — то такая схема называется мультиплексированием, и для законного использования нужны CAL-лицензии (в данном примере SQL Server CAL) по числу реальных пользователей/устройств.

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Сравнение Open Source лицензий

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

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

Эта задача кажется несложной – просто почистить исходники и историю версий перед тем, как залить свой репозиторий на GitHub или Bitbucket. пока не всплывает вопрос о лицензии. Оказывается, выбор такой широкий. Какую лицензию выбрать? И нужна ли она вам вообще на самом деле?

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

Нужна ли мне лицензия? И что вообще такое лицензия?

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

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

Какова цель лицензии?

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

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

Итак, лицензия защитит вашу работу. Защитит лицензиата. Но помимо этого она защитит и вас – и я имею в виду вас лично. К примеру, ограничивая ответственность лицензиара за потенциальный вред, причиной которого стала его работа.

А что, если я не буду использовать лицензию?

При отсутствии лицензии, ассоциированной с работой, «по умолчанию» действуют авторские права в соответствии с юрисдикцией страны автора. Другими словами, никогда не считайте, что «отсутствие лицензии» подразумевает, что другие люди могут делать с вашей работой что угодно. Всё как раз наоборот: без определенной лицензии вы, автор, не отказываетесь ни от каких прав, предоставленных законом.

Но всегда помните, что лицензия регулирует права и обязанности. Вы когда-нибудь задумывались, почему в тексте многих лицензий содержится написанное БУКВАМИ В ВЕРХНЕМ РЕГИСТРЕ предупреждение о гарантиях, предоставляемых вместе с продуктом – или, куда чаще, об отсутствии таковых? Это делается для того, чтобы защитить владельца работы от пользовательских ожиданий и того, что подразумевается какая-либо гарантия. Последнее, что вам нужно – это чтобы на ваш открытый код подали в суд!

Могу ли я использовать кастомную (собственную) лицензию?

Да, можете. Но, вероятно, не стоит этого делать.

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

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

Могу ли я использовать несколько лицензий?

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

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

Могу ли я поменять лицензию «позже»?

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

Для проекта средней величины это реально. И на самом деле делалось, как вы увидите в некоторых примерах ниже.

Какую лицензию Open Source мне следует использовать?

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

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

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

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

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

Популярные проекты

GPL – лицензия, очень строгая к тому, чтобы каждая производная работа публиковалась на тех же условиях, что и исходная, и с открытым исходным кодом. Это особенно неудобно в случае с библиотеками, которые служат «кирпичами» для крупных программных продуктов: если библиотека выпущена под GPL, то любое использующее её приложение должно также выпускаться под GPL. Эту сложность адресует LGPL.

В отношении библиотек Фонд свободного программного обеспечения (FSF) выделяет три случая:

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

Популярные проекты

Eclipse Public License (EPL 1.0)

С более слабым копилефтом, чем в LGPL, лицензия Eclipse больше подходит для бизнеса и допускает сублицензирование и создание программного обеспечения (ПО) на основе кода как под EPL, так и под другими лицензиями (даже проприетарными), с условием, что код под другой лицензией вынесен в отдельный модель программного продукта.

Кроме того, EPL предоставляет дополнительную защиту соавторам кода под EPL в случае судебных исков/ущерба, вызванного коммерческой деятельностью, связанной с этой работой.

Популярные проекты

Очевидно, что EPL – наиболее подходящая лицензия для проектов Eclipse Foundation, в том числе Eclipse IDE. Но она прибрела некоторую популярность и за пределами этого – особенно в мире разработки на Java:

Mozilla Public License (MPL)

MPL – лицензия, которая используется для ПО, созданного Mozilla Foundation. Но её применение этим не ограничено. MPL пытается достичь компромисса между строгими лицензиями (такими как GPL) и либеральными лицензиями (такими как лицензия MIT).

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

Популярные проекты

Apache License 2.0 (ASL 2.0)

С ASL мы попадаем в мир либеральных свободных лицензий. Но даже FSF в некоторых случаях рекомендует лицензию Apache. Лицензия Apache считается либеральной, поскольку не требует того, чтобы какие-либо производные работы выпускались на тех же условиях. Другими словами, это «не-копилефт» лицензия.

ASL – единственная лицензия, которая используется для проектов Apache Software Foundation. Считающаяся удобной для бизнеса, она получила широкое распространение за пределами этой организации. Можно нередко увидеть проекты корпоративного уровня, выпущенные под этой лицензией.

Популярные проекты

MIT License

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

Популярные проекты

Лицензии BSD

Лицензии BSD бывают трёх видов. Оригинальная лицензия «4-х пунктов», «пересмотренная» лицензия, состоящая из 3-х пунктов и «упрощённая» лицензия из 2-х пунктов. По духу все три очень близки к лицензии MIT. И действительно, между упрощенной лицензией BSD и лицензией MIT нет существенных различий.

Лицензии BSD, состоящие из 3-х и 4-х пунктов, содержат больше требований в отношении повторного использования наименований и рекламы. Это полезно учесть, если вы хотите защитить название вашего продукта или марки.

Популярные проекты

В заключение о лицензиях Open Source

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

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

Онлайн курс по Linux

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

Источник

Лицензия для вашего open-source проекта

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

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

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

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

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

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

Meanwhile in Russia

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

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

Лицензии

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

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

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

В мире

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

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

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

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

Copyleft

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

Основные свободные лицензии

GPLv3 (GNU General Public License Version 3)

GPLv2 (GNU General Public License Version 2)

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 для любых программ, которые обычно выполняются в сети.

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

Apache 2.0

Наиболее современная и сбалансированная из разрешительных лицензий. Написана человеческим языком, но с оглядкой на современное правоприменение, в частности, упомянутые выше патентные отношения (пункт 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.

Beerware

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.

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

CC0 (Creative Commons CC0)

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

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

Unlicense

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

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

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

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

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

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

Заключение

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

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

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

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

Источник