• Перевод

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

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

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

Многие разработчики и дизайнеры хотят опубликовать свои работы в виде открытых проектов. Они хотят иметь возможность делиться своим кодом. Сообщество open-source с каждым днём всё прочнее стоит на ногах. Открытые программы существуют для любых видов задач, каких вы только можете себе вообразить. А многие веб-разработчики используют свободное ПО как фундамент для своей работы (WordPress, Drupal и многие другие CMS открыты, свободны и бесплатны).

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

Что такое лицензирование?

В двух словах: лицензирование даёт определённые полномочия сторонним лицам на использование вашего продукта.

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

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

GNU General Public License

GNU Lesser General Public License

От GNU появилось много производных лицензий. Самая популярная из них – LGPL . Она даёт несколько больше прав, чем стандартная GPL . Обычно используется для лицензирования библиотек, которым нужно работать в связке с не-GPL и с не-открытыми программами. Так как GPL требует, чтобы ПО с участками GPL также распространялось под GPL , разработчики не могут использовать код под GPL-лицензией для разработки проприетарного коммерческого ПО. LGPL даёт такое право.

Лицензия BSD

Существует целое семейство BSD-лицензий, которые накладывают гораздо меньше ограничений на распространение продукта, чем строгая GPL. Среди всей палитры BSD-лицензий, существуют 2 наиболее используемые: New BSD /Modified BSD и Simplified BSD /FreeBSD . Обе GPL-совместимы и одобрены в качестве свободных лицензий влиятельной организацией Open Source Initiative.

Лицензия New BSD разрешает неограниченное распространение с любой целью, не даёт никаких гарантий и не несёт никакой ответственности. Лицензия содержит также положение, ограничивающее использование имён участников проекта для подтверждения работы без специального разрешения. Говоря нормальным языком, “делайте с кодом что хотите, но не говорите, что это вы его написали”. Основное различие между New BSD и Simplified BSD в том, что последняя не включает в себя пункт этого “специального разрешения”.

MIT License

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

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

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

Что всё это значит:

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

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

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

Лицензия Apache

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

Вот основные положения:

Права вечны Как только они вам предоставлены, вы можете использовать их всегда.

Права глобальны Если права выданы в одной стране, то они распространяются и во всех других странах. Например, если вы живёте в США, а оригинальная лицензия была выдана в Индии, вы всё равно не ограничены в использовании кода (ничего не могу сказать про Украину, Россию и Белоруссию, у нас всё очень зыбко).

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

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

Права неотъемлемы Никто не может отобрать у вас права. Другими словами, вам не стоит беспокоится о том, что однажды, создав некий потрясающий код, кто-то скажет вам: “Извини, но ты больше не можешь его видеть”.

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

Creative Commons

Лицензия Creative Commons () не совсем open-source лицензия, так как она обычно используется в мультимедиа и дизайн-проектах. Существует широкое множество CC-лицензий и каждая из них даёт определённые права. У CC есть 4 основных положения, которые могут быть использованы по одиночке или в комбинации друг с другом. Вот они:

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

Копилефт – SA

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

Некоммерческое использование – NC

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

Без производных – ND

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

Как уже было сказано, эти составляющие можно комбинировать. Наиболее жёсткая лицензия - “С указанием авторства – Некоммерческая – Без производных” (BY-NC-ND). Это наиболее хороший вариант для того, чтобы освободить свою работу, но сохранить над ней контроль. А наименее жёсткая лицензия - “С указание авторства” (BY) означает, что люди могут использовать вашу работу до тех пор, пока указывают ваше авторство.

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

P.S.

Вот шесть наиболее часто используемых лицензий мира open-source. На самом деле их намного больше, некоторые источники уверяют, что около 60-ти. Многие практически дублируют друг друга с некоторыми небольшими оговорками, что создаёт сложности в их выборе и использовании. Open Source Initiative работает над тем, чтобы сократить их количество до приемлемого. Я же считаю, что на все случаи жизни хватило бы и четырёх: GPL , LGPL , BSD и . Рекомендую вам более подробно ознакомиться с каждой из них, а если вы заинтересовались использовать эти лицензии в своём бизнесе, как это делают IBM, Google и сотни других крупных компаний, обязательно проконсультируйтесь со своим юристом. В постсоветских странах, насколько мне известно, нет никакой правовой защиты open-source лицензий, по крайней мере не было ни одного судебного прецедента. С другой стороны, юристы OSI (Open Source Initiative) гарантируют защиту ваших прав по каждой из указанных лицензий.

Поправка от tarzanasg:

«Некоммерческое использование – NC» и «Без производных – ND» к open source не относятся. Применение этих условий делает лицензию и тексты с медиафайлами собственническими.

Заблуждения, относительно того, что с программными продуктами open source можно делать все что угодно в личных и коммерческих целях, сильно распространено. У большинства людей такое ПО ассоциируется со словом «бесплатно», но на самом деле в разработанных open source-лицензиях ничего не говорится о цене программ, распространяемых таким образом.

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

GPL

GNU GPL (GNU General Public License) - одна из наиболее распространенных open source-лицензий. Под этой лицензией распространяются ядро Linux, MySQL, Asterisk и многие другие. Большинство CMS систем, таких как MovableType, MODx, WordPress, Joomla, Drupal, osCommerce и множество других выпускаются под GPL. По разным данным, в мире до 70% open source-ПО выпускается под GPL.

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

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

LGPL

GNU LGPL (GNU Lesser General Public License) отличается от GPL тем, что позволяет использовать продукты LGPL в проектах, распространяемых под другими лицензиями. То есть условия, сходные с GPL, распространяются только на ту часть производного продукта, которая заимствована из продукта, защищенного LGPL.

Изначально создатели GPL и LGPL – Free Software Foundation – предполагали использование GPL в готовых продуктах, а LGPL - в библиотеках для разработчиков, но на данный момент такое разделение не соответствует действительности. Наиболее известный продукт, выпускаемый под LGPL, – OpenOffice.org.

Перед тем как выложить 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. Полный список лицензий есть на сайте