Построчный разбор лицензии MIT. Сравнительный анализ основных лицензий Open Source: GPL, LGPL, BSD, MIT, Mozilla public license, Apache software license

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

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

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

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

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

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

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

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

GNU AGPLv3

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

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

GNU GPLv3

Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
* Распространять исходный код вместе с продуктом
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
* Производные продукта необходимо выпускать под той же лицензией Запрещает:
* Отказ от ответственности
* Никакой гарантии

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

GNU LGPLv3

Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
* Распространять исходный код вместе с продуктом
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
* Запрещает:
* Отказ от ответственности
* Никакой гарантии

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

Mozilla Public License 2.0

Оригинальный текст
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
* Распространять исходный код вместе с продуктом (в случае использования в качестве библиотеки - только исходный код библиотеки)
* Упоминания авторства и лицензии в работе
* Производные продукта необходимо выпускать под той же лицензией (но можно использовать продукт в качестве библиотеки) Запрещает:
* Отказ от ответственности
* Никакой гарантии
*

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

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

The MIT License

Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование

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

Apache License 2.0

Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

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

The Unlicense

Оригинальный текст
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
(Ничего не требует) Запрещает:
* Никаких обязательств
* Никакой гарантии

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

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

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

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

Тезисы доклада на семинаре "Открытые системы: философия, технология, бизнес" (проведенного 30 января 2002 г. Институтом Логики и ALT Linux): Все шесть лицензий, которые будут рассматриваться в настоящем докладе, являются лицензиями, одобренными Open Source Initiative для распространения ПО с открытым исходным текстом. Эти же лицензии называются "лицензиями на свободное ПО" (free software licenses) на сайте проекта GNU Free software foundation (FSF)...

Комментарии (3)

К сожалению, не могу с этим не согласится. Но существует и другая проблема. Большинство copyleft лицензий основано на идеологии AS IS, т.е. отсутствие каких-либо гарантий, что существенно затрудняет профессиональное использование продуктов на них основанных. Очень часто при выборе между продуктом под copyleft лицензией и коммерческим продуктом делается выбор в пользу последнего только на основании гарантий функциональности и поддержки, которые берёт на себя производитель.

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

Это чистая пропаганда. Во-первых, противопоставлять "copyleft" и "коммерческое" бессмысленно. Copyleft противостоит не "коммерческому", а незащищенному свободному или (вместе с незащищенным свободным) несвободному. "Коммерческое" - это режим поставки. Copylefted software может поставляться как коммерчески (за деньги), так и некоммерчески.

Во-вторых, AS IS - это отсутствие ответственности автора/поставщика по умолчанию. Ответственность и обязательства могут описываться другим документом; copyleft-лицензии, собственно, для этого не предназначены, в них четко говорится, что они регулируют распространение и использование.

Перед тем как выложить software-продукт в сеть, хорошо бы подумать об авторских правах и возможных нюансах использования вашего кода. Здесь на помощь приходят open-source лицензии. Сегодня мы рассмотрим наиболее популярные из них:

• GNU GPL
• Apache 2.0
• MPL v2.0
• The Unlicense

Общие понятия

Когда речь идет о лицензиях, вам могут встретиться следующие термины:

• Копилефтная лицензия - требующая распространять производные продукты под такой же лицензией. То есть, допустим, вы использовали в своем проекте стороннюю библиотеку с копилефтной лицензией X. Вам придется также лицензировать продукт Х.
• Разрешительная лицензия не накладывает никаких ограничений. Использовав чужой модуль, обладающий такой лицензией, вы можете распространять конечный продукт под любой лицензией, как коммерческой, так и open-source.
• Совместимость. Вы можете использовать в качестве компонентов своего проекта стороннее ПО с лицензиями X, Y, Z, если X, Y, Z совместимы с лицензией вашего проекта.

GNU General Public License

Самое важное, что вам нужно знать о GNU GPL это:

• Вы должны предоставить для изучения исходный код вашей программы, даже если распространяете продукт в скомпилированном виде.
• Если вы использовали в вашем проекте ПО, лицензированное GNU GPL, конечный продукт также должен быть лицензирован GNU GPL. То же касается модификации и распространения версий чужого кода.

MIT

Лицензия MIT наиболее «на слуху» в мире свободного ПО. Если разработчику не важны патентные права и в каком виде будет распространятся его код, оказавшись в сети, выбор часто падает на MIT.

• Позволяет безвозмездное использование ПО без ограничений: включая изменение, распространение и продажу копий.
• Конечный продукт можно распространять под любой лицензией.
• Исходные коды предоставлять не обязательно.
• Отказ от гарантий. Пользователь использует ПО на свой страх и риск.
• Отказ от ответственности. Вы ничего не сможете предъявить разработчику.
• Единственным обязательным условием является указание лицензии и автора.

Apache 2.0

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

Copyright Licensed under the Apache License, Version 2.0 (the «License»);

Это не обязательно делать в исходном коде - можно использовать файл NOTICE . Если вы используете в проекте чужой компонент под лицензией Apache 2.0, содержащий свой файл NOTICE, вы обязаны скопировать его содержимое в конечный продукт.

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

Mozilla Public License v2.0

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

• Если вы изменили файл, он должен остаться под MPL 2.0.
• Можно без ограничений добавлять в проект компоненты любых лицензий.

The Unlicense

Попытка сделать код общественным достоянием и отказаться от авторства.

Beerware

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

Вывод

Хотите, чтобы другие разработчики делились улучшениями вашего продукта? Выбирайте GNU GPL или MPL. Важен вопрос авторских прав? Тогда вам подойдет Apache 2.0. Нет точных требований к лицензии? Можно выложить код в интернет, лицензировав его MIT. Полный список лицензий есть на сайте

• Перевод

171 слово, которое должен понимать любой программист

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

Читаем лицензию

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

The MIT License (MIT)

Copyright «year» «copyright holders»

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Лицензия MIT

Copyright «год» «владельцы прав»

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

ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ, СООТВЕТСТВИЯ ПО ЕГО КОНКРЕТНОМУ НАЗНАЧЕНИЮ И ОТСУТСТВИЯ НАРУШЕНИЙ, НО НЕ ОГРАНИЧИВАЯСЬ ИМИ. НИ В КАКОМ СЛУЧАЕ АВТОРЫ ИЛИ ПРАВООБЛАДАТЕЛИ НЕ НЕСУТ ОТВЕТСТВЕННОСТИ ПО КАКИМ-ЛИБО ИСКАМ, ЗА УЩЕРБ ИЛИ ПО ИНЫМ ТРЕБОВАНИЯМ, В ТОМ ЧИСЛЕ, ПРИ ДЕЙСТВИИ КОНТРАКТА, ДЕЛИКТЕ ИЛИ ИНОЙ СИТУАЦИИ, ВОЗНИКШИМ ИЗ-ЗА ИСПОЛЬЗОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЛИ ИНЫХ ДЕЙСТВИЙ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ.

Лицензия разбита на пять параграфов, но логически делится следующим образом:

• Заголовок
  • Название
  • Копирайт
• Разрешение
  • Область действия
  • Условия
    • Передача лицензии
    • Отказ от гарантий
    • Ограничение ответственности

Поехали.

Заголовок

Название

«Лицензия MIT» – это не одна лицензия, а семейство лицензионных форм, сформировавшихся под влиянием стиля, принятого в продуктах, выпускаемых из Массачусетского технологического института. С годами она часто менялась, как у тех проектов, что использовали её изначально, так и в качестве модели для других проектов. Проект Fedora Project поддерживает архив интересных вариантов лицензии, с вариантами лицензий, хранящимися простым текстом, будто бы анатомическими диковинами в формальдегиде, демонстрирующими ход эволюции.

К счастью, инициатива открытых проектов Open Source Initiative и группа Software Package Data eXchange стандартизировали общий вид MIT-лицензии и назвали его “The MIT License”. OSI приняла строковые идентификаторы для общеупотребительных лицензий открытого кода у SPDX, и сокращение MIT недвусмысленно подразумевает «лицензию MIT». Если вам необходимо распространять ваш продукт на MIT-условиях, воспользуйтесь стандартной формой лицензии MIT.

Но даже если вы включите в файл LICENSE строки “The MIT License” или “SPDX:MIT”, ответственный читатель сверит ваш текст со стандартной формой, просто для подстраховки. Много разных форм лицензий называет себя «MIT License», отличаясь при этом в деталях, и благодаря слишком сильной размытости понятия «лицензия MIT» многие авторы не устояли перед искушением добавить в текст что-нибудь от себя. Каноническим примером такого плохого, ужасного, отвратительного изменения служит лицензия JSON, в которой к MIT-лицензии добавляется «Программа должна использоваться с хорошими, а не с плохими, целями». Такая выходка весьма в духе Крокфорда . Ужасная головная боль. Может, это насмешка над юристами. Они смеялись всю дорогу до банка.

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

Копирайт

Copyright <год> <владельцы прав>

До вступления в силу Закона об авторских правах 1976 года в США требовались особые действия, «формальные требования», для обеспечения сохранения авторского права. И если вы им не следовали, ваше право подавать в суд на незаконное использование ваших работ было ограничено, а иногда и вовсе исчезало. Одним из формальных требований было т.н. «уведомление»: размещение отметок на ваших работах, и другие действия, необходимые для оповещения рынка о заявлении на права. Значок - стандартный символ для этого. В ASCII не было такого значка, поэтому для той же цели использовалась комбинация.

Закон об авторских правах 1976 года устранил необходимость соблюдения формальностей. В США владельцам прав до сих пор необходимо регистрировать свои работы перед судебными разбирательствами, но на практике это делается уже непосредственно перед самим судом. Вы не потеряете копирайт, если просто забыли о нём заявить, зарегистрировать, отправить копию в Библиотеку конгресса, и т.п.

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

Для владельца копирайта место есть не во всех лицензиях. Более современные лицензии, например, Apache 2.0 и GPL 3.0, публикуют тексты LICENSE, которые нужно дословно скопировать, а затем в комментариях и отдельных файлах уже указать владельцев работы. Такой подход исключает изменение текстов лицензий и упрощает их автоматическую обработку.

Лицензия MIT происходит из релизов кода, выполняемых различными учреждениями. Для таких релизов владельцем прав был только институт, выпускающий код. Другие институты переняли эти лицензии, заменяя MIT своими названиями, что и привело к существованию лицензий общего вида. Такому процессу подвергались и другие лицензии, например, BSD License из Калифорнийского университета, изначально состоявшая из четырёх пунктов, а теперь используемая в вариантах с тремя и двумя пунктами, а также The ISC License for the Internet Systems Consortium, вариант MIT-лицензии.

В каждом случае организация указывала себя в качестве владельца прав, и пользовалась возможностями «работы, выполненной по найму», которые позволяли оставлять себе права на работу, выполненную сотрудниками и контрактниками. Эти правила обычно не распространяются на работу, которую сотрудники и контрактники выполняют по своей инициативе. Также они не распространяются на распределённые группы работающих вместе людей, добровольно предоставившие свой код. Для фондов, управляющих проектами, вроде Apache Foundation и Eclipse Foundation, принимающих код из различных источников, это представляет проблему. Обычно фонды справлялись с этим, используя домашнюю лицензию, заявлявшую об одном владельце прав – Apache CLA и Eclipse CLA – для получения прав от спонсоров. Собирание прав в одном месте даже более важно для всяческих лицензий типа «copyleft», например, GPL, которые перекладывают ответственность по распространению ценностей свободного софта на владельцев копирайта.

Сегодня многие проекты, даже не управляющие работой нескольких поставщиков кода, используют MIT-лицензии. Этому поспособствовали SPDX и OSI, стандартизировав формы лицензий, не ссылающиеся на определённое лицо или группу лиц, обладающих правами. В результате большинство авторов просто вписывают своё имя в уведомление о правообладателе, и иногда ещё вставляют год.

Изначальный владелец кода сохраняет права на свою работу. Но хотя MIT-подобные лицензии дают другим права на надстройку и изменение софта, создавая то, что называется «производной работой», они не дают изначальному автору возможности владеть тем, что создали другие люди. Каждый, внёсший свой вклад, сохраняет права на свою часть работы, проведённую на основе существовавшего кода.

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

Чтобы заполнить разрыв между легализованными и документированными передачами прав и отсутствием каких бы то ни было бумаг, некоторые проекты принимают Developer"s Certificate of Origin, сертификат о происхождении от разработчика, стандартное заявление, на которое ссылаются разработчики при помощи метатегов Signed-Off-By. DCO был разработан для разработки ядра Linux, вышедшего из ядра Unix, принадлежавшего SCO. DCO хорошо справляется с документацией процесса, в котором каждая из линеек Linux появилась благодаря вносящим в неё вклад людям. И хотя это не лицензия, она предоставляет множество неплохих доказательств, что те, кто отправлял в проект свой код, подразумевали, что он будет распространяться вместе с проектом, и что пользователи будут пользоваться им согласно существующей для kernel лицензии. Также с ядром поддерживают человеко-читаемый файл CREDITS, в котором перечислены все люди, сделавшие свой вклад, с именами, членством, областью вклада и другими данными.

Разрешение

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

Суть лицензии от MIT в том, что это, как вы могли догадаться, лицензия. В общем случае, лицензия – это разрешение, которое один человек или юридическое лицо – лицензиар – разрешает другому – лицензиату – делать что-либо, что в противном случае можно было бы оспаривать в суде. Лицензия MIT – это обещание не подавать в суд.

Иногда закон разделяет лицензию и обещание в передаче лицензии. Если кто-то нарушает обещание передать вам лицензию, вы можете засудить его за нарушение обещания, но при этом вы можете так и не получить лицензию. В данном предложении [в английской версии для этого служит архаизм «hereby» – прим. перев. ] поясняется, что сам по себе текст этой лицензии уже даёт вам лицензию, а не просто обещание её передачи.

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

Обозначение понятия в скобках и кавычках («Определение») – стандартный способ придания терминам определённого значения в легальных документах. Этим терминами стороны смогут пользоваться в судебном разбирательстве.

Область действия

безвозмездно использовать Программное Обеспечение без ограничений,

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

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

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

Во-первых, «включая неограниченное право» – это пример того, как не нужно писать юридические тексты. Бывают вариации этой формулировки:

• включая, без ограничений;
• включая, без ограничений обобщения вышеупомянутого;
• включая, но не ограничиваясь;

И другие.

Все они пишутся для одной цели, и ни одна из них её не достигает. Использующие их юристы хотят и рыбку съесть, и на мель не сесть. В лицензии MIT они означают попытку представить определённые примеры «использования ПО» – «использование, копирование, изменение,», и проч.,- не имея в виду, что использовать это ПО можно будет только одним из перечисленных способов. Проблема в том, что если представить такую лицензию в суде, то суду для понимания лицензии придётся определять значения указанных терминов. Если суд захочет понять, что означает «использовать ПО», он не сможет «развидеть» указанные в лицензии примеры использования. Я бы сказал, что лучше всего написать в лицензии «использовать ПО без ограничений». Это ещё и короче.

Во-вторых, перечисленные термины представляют собой мешанину. Некоторые из них описаны в законах об авторских правах и патентах, а некоторые – нет.

• использовать встречается в Кодексе Соединённых Штатов Америки, ст.35 п.271(а) в перечне того, из-за применения чего без разрешения патентодержателя последний может подать в суд
• копировать встречается в Кодексе ст.17 п.106, в списке закона об авторском праве
• изменять, публиковать, объединять не встречается ни в авторском, ни в патентном праве.
• распространять встречается в законе об авторском праве.
• сублицензировать – это общий термин закона об интеллектуальной собственности. Оно означает право другим раздавать свои собственные лицензии на частичный или полный список того, что вы им разрешаете делать. Этот пункт необычен для открытых лицензий. Нормальный подход – прямой, когда каждый, получающий копию софта, получает и лицензию напрямую от владельца.
• продавать – слово гибридное. Оно похоже на продажи, упомянутые в патентном праве, но имеет в виду продажу копий, как в законе об авторских правах. С точки зрения копирайта оно ближе к «распространению», но в законе о копирайте не упоминаются продажи.
• а также лицам, которым предоставляется данное Программное Обеспечение – эта фраза выглядит ненужным повторением «сублицензирования». Также она не нужна постольку, поскольку получающие копии софта люди сразу получают и лицензию.

И, наконец, из-за этой смеси юридической, производственной, интеллектуальной собственности и общеупотребительных терминов, непонятно, включает ли лицензия MIT разрешение на патент. «Использование» намекает на патенты, хотя и не очень понятно. То, что лицензия исходит от владельца авторских прав, у которого могут быть, а могут и не быть патентные права на софт, а также большинство указанных для примеров использования глаголов и само определение ПО, указывают на лицензию на копирайт. Более новые лицензии, вроде Apache 2.0, отдельно и явно упоминают копирайт, патенты, и даже торговые марки.

Три условия лицензии

при соблюдении следующих условий

Всегда есть подвох – а у MIT их даже три!

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

Использовать ценность софта как мотивацию лицензиата на выполнение условий, хотя он за лицензию и не платил, это вторая великая идея софта с открытым кодом. Последняя, которой в лицензии MIT не нашлось места, основана на условиях лицензии – такие лицензии, как GNU Public License, используют условия для контроля над тем, как вносящие изменения люди могут лицензировать и распространять изменённые версии.

Передача лицензии

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

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

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

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

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

Отказ от гарантий

ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ, СООТВЕТСТВИЯ ПО ЕГО КОНКРЕТНОМУ НАЗНАЧЕНИЮ И ОТСУТСТВИЯ НАРУШЕНИЙ, НО НЕ ОГРАНИЧИВАЯСЬ ИМИ.

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

Некоторые правила UCC обязательны для исполнения и применяются всегда. Другие лишь описывают состояние «по умолчанию» – если продавцы и покупатели не напишут в соглашении чего-либо иного. Среди таких правил по «умолчанию» находятся и гарантии, то есть обещания продавцов покупателям по поводу качества и годности для использования продуктов.

Идут споры о том, являются ли публичные лицензии вроде MIT контрактами – соглашениями, к которым можно принудить лицензиатов и лицензиаров – или же это просто лицензии, к которым могут быть прикреплены условия. Чуть меньше споров идёт по поводу того, является ли ПО товаром, и входит ли, таким образом, в юрисдикцию UCC. Но насчёт ответственности у лицензиаров спора нет: никто не хочет, чтобы его засудили, если раздаваемый им софт ломается, причиняет проблемы, не работает, или ещё как-то отрицательно проявляет себя. Это прямо противоположно тому, что описывают три правила гарантий по умолчанию:

1. Товарная пригодность, согласно секции 2-314, это обещание, что товар – ПО – будет качеством не ниже среднего, соответствующим образом упакован и промаркирован, и пригоден для обычного использования. Это правило применяется только к торговцам ПО – то есть, к продающим их и к считающим себя специалистом в этой области.
2. Пригодность к определённой цели, согласно секции 2-315, применяется, когда продавец знает, что покупатель рассчитывает на то, что товар будет пригоден для применения определённым образом.
3. Отсутствие патентных препятствий – не входит в UCC, но обычно используется в контрактных законах. Оно защищает покупателя в случае, когда выясняется, что купленный товар нарушает чьи-либо интеллектуальные права.

Секция 2-316(3) требует, чтобы текст лицензии, исключающий эти гарантии, делал это заметным образом – то есть, привлекая внимание к себе, а не прячась в виде мелкого шрифта на последней странице контракта. То же законами штата может требоваться и от объявлений об отсутствиях патентных препятствий.

Юристы давно заблуждаются, что написав текст ЗАГЛАВНЫМИ БУКВАМИ, они выполняют требование заметности. Это не так. Заглавные буквы часто отталкивают читателя вместо того, чтобы привлекать его внимание. Но большинство лицензий открытого кода пишут эту часть заглавными, поскольку это самый очевидный способ сделать текст в простых текстовых файлах выделяющимся. Я бы предпочёл использовать звёздочки или другой ASCII-art, но этот поезд уже ушёл.

Ограничение ответственности

НИ В КАКОМ СЛУЧАЕ АВТОРЫ ИЛИ ПРАВООБЛАДАТЕЛИ НЕ НЕСУТ ОТВЕТСТВЕННОСТИ ПО КАКИМ-ЛИБО ИСКАМ, ЗА УЩЕРБ ИЛИ ПО ИНЫМ ТРЕБОВАНИЯМ, В ТОМ ЧИСЛЕ, ПРИ ДЕЙСТВИИ КОНТРАКТА, ДЕЛИКТЕ ИЛИ ИНОЙ СИТУАЦИИ, ВОЗНИКШИМ ИЗ-ЗА ИСПОЛЬЗОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЛИ ИНЫХ ДЕЙСТВИЙ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ.

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

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

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

В этой секции перечисляются те типы законных преследований, которые лицензиар не может использовать. Как и многие легальные формы, эта лицензия упоминает нарушения контрактов и деликты . Правила деликтов относятся к совершению поступков, влекущих за собой возмещение ущерба. Если вы задавили кого-то на дороге, отправляя SMS, вы совершили деликт. Если ваша компания продала бракованные наушники, которые сожгли людям уши, она совершила деликт. Если в контракте не указано явно исключение требований по деликтам, суды иногда этим пользуются. В лицензии MIT указано «по иным требованиям», чтобы исключить всякие экзотические требования.

Фраза "ВОЗНИКШИМ ИЗ-ЗА ИСПОЛЬЗОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЛИ ИНЫХ ДЕЙСТВИЙ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ " – нервный тик, характерный для приобретённого страха за свою безопасность у юриста. Смысл в том, что любой иск, связанный с этим ПО, покрывается ограничениями и исключениями. Однако использование ПО вполне входит в «иные действия» с ПО. [в оригинале лицензии указано три варианта событий «arising from», «in connection with», «use» – то есть, «возникающих из», «в связи с» и «при использовании», которые, по сути, дублируют друг друга, что и вызывает претензии у автора статьи – прим. перев. ] Однако такой язык используется в миллионах других лицензий.

Заключение

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

Мы увидели, что лицензия MIT – набор определённых и стандартизированных определений, вносящий порядок в хаос в случайные варианты лицензий, принятые в разных организациях.

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

С 1 октября 2014 года в России легализованы свободные лицензии (open source). Соответствующие изменения были внесены законодателями в 4 часть Гражданского кодекса.

Теория

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

• Свобода выполнять программу, как вам угодно и в любых целях (свобода 0).
• Свобода изучать, как работает программа, и адаптировать ее под свои нужды (свобода 1). Для этого необходим доступ к исходному тексту.
• Свобода распространять копии, чтобы помочь своему ближнему (свобода 2).
• Свобода улучшать программу и делать ваши улучшения общедоступными к выгоде всего сообщества (свобода 3). Для этого необходим доступ к исходному тексту.

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

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

Данные права корреспондируют со следующими обязанностями автора:

1. раскрывать исходный код программы;
2. не ограничивать использование и распространение программы, что фактически нейтрализует монополию автора.

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

История

Движение за свободное программное обеспечение боролось за свободу пользователей с 1983 года. В 1984 году был дан старт разработке свободной операционной системы GNU, чтобы пользователи могли обходиться без операционных систем, которые отказывают своим пользователям в свободе. За восьмидесятые годы XX века были разработаны большинство основных компонентов такой системы и программисты составили Стандартную общественную лицензию GNU (GNU GPL), чтобы выпускать их под этой лицензией, созданную специально для того, чтобы защитить свободу всех пользователей программы.

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

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

В некоторых странах программные продукты могут быть зарегистрированы как объекты патентного права и на них получены патенты (например, США, Южная Корея, Япония и др). Возникает некое противоречие между открытой лицензией и охраной патентным правом объекта патентования. Возможно, поэтому последние версии открытых лицензий включают в себя условия, ограничивающие автора в использовании своих прав, вытекающих из полученных патентов.

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

В 90-е годы прошлого века принуждение к исполнению свободных лицензий осуществлялось на неформальной основе. Если говорить о GPL, наиболее распространенной лицензии, то защищал нарушенные права сам Столлмен, основатель движения. Первые положительные судебные решения были получены в Европе, начиная с 2004 года. Интересы сообщества разработчиков свободного программного обеспечения защищал Г. Велте (Harald Welte).

Перечислим ряд выигранных судебных споров. В США первое дело, связанное с нарушением условий свободной лицензии, было рассмотрено в 2007 году. Ответчик, компания Monsoon Multimedia, использовал свободную программу BusyBox в своем устройстве для дистанционного просмотра телепрограмм. Правовой центр защиты свободы программного обеспечения (Software Freedom Law Center), который выступал в качестве представителя разработчиков свободной программы, и компания Monsoon Multimedia пришли к мировому соглашению, в соответствии с которым компания взяла на себя обязательство по исполнению всех условий GPL.

Мировым соглашением завершился также процесс по иску Фонда свободного программного обеспечения (Free Software Foundation), предъявленному компании Cisco Systems по факту многочисленных нарушений <1>. В соответствии с мировым соглашением, которое удалось достичь только спустя полгода после начала судебного разбирательства, компания Cisco согласилась не только разместить на своих сайтах исходный код используемых ею свободных программ, но и выплатить Фонду свободного программного обеспечения денежную компенсацию.

В России

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

Но не путем признания существующих свободных лицензий.

Статьей 1286.1 ГК РФ вводится понятие «открытой лицензии». Договор открытой лицензии является разновидностью упрощенного порядка заключения лицензионного договора и может быть заключен в отношении произведений науки, литературы или искусства, а также программ ЭВМ.

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

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

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

Еще раз повторюсь, что, по сути, «открытая лицензия» — это легализация «open source», можно делать ссылки на любой вариант General Public License, или написать свой.

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

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

Практика

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

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

1. разрешение на любые виды использования программы без ограничения сферы использования и субъектного состава/или с ограничениями;
2. разрешение на свободное дальнейшее распространение программы на любых носителях, в том числе за плату и в том числе в составе сложных программ, или без взимания платы за такое распространение и без предъявления к пользователю каких-либо дополнительных требований;
3. разрешение создавать производные программы и условие об их распространении на тех же условиях, на которых программа была получена;
4. условие о распространении одной и той же лицензии по всей цепочке пользователей без необходимости получения ими дополнительных лицензий или иных разрешений;
5. решение вопроса об открытости кода.

Помимо «открытой лицензии» с 1 января 2015 года в России появляется еще один новый способ распоряжения исключительными правами - публичное сообщение о возможности использования произведения.

Заявление делается путем размещения на официальном сайте федерального органа исполнительной власти в сети Интернет. Федеральный орган исполнительной власти, ответственный за размещение соответствующих заявлений, а также порядок и условия их размещения определяются Правительством Российской Федерации.