171 слово, которое должен понимать любой программист
Лицензия MIT – самая популярная лицензия для программ с открытым кодом. Здесь приводится одно из её прочтений, с построчным разбором.
Читаем лицензию
Если вы разрабатываете программы с открытым кодом, и не читали эту лицензию подробно – а она состоит всего из 171 слова – вам нужно этим заняться. Особенно, если вы не занимаетесь лицензиями на ежедневной основе. Отметьте всё, что вам непонятно. А я повторю все эти слова, по порядку и по кусочкам, вместе с контекстом и комментариями. При этом важно представлять себе её целиком.
The MIT License (MIT)
Copyright © 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
«Лицензия 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. Обеспечивает отказ от гарантий и ограничение ответственности.Никто не запрещает вам брать деньги за распространение копий, или даже делать копии в скомпилированном виде, без исходного кода. Но в этом случае нельзя притворяться, что код принадлежит вам, или проходит под какой-то другой лицензией. Получатели продукта должны знать свои права по «публичной лицензии».
Эти условия, к сожалению, выполняются плохо. Почти в каждой лицензии открытого ПО есть такие условия. Создатели системного и устанавливаемого ПО часто понимают, что им необходимо выводить файл с лицензионной информацией на экран, включать копии лицензии в библиотеки и компоненты. Фонды, управляющие проектами, обучают этим практикам. Но веб-разработчики, видимо, не получали уведомления. Нет им прощения.
Отказ от гарантий
ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ, СООТВЕТСТВИЯ ПО ЕГО КОНКРЕТНОМУ НАЗНАЧЕНИЮ И ОТСУТСТВИЯ НАРУШЕНИЙ, НО НЕ ОГРАНИЧИВАЯСЬ ИМИ.
Почти во всех штатах США закон обязывает следовать версии Единообразного торгового кодекса [Uniform Commercial Code], набору законов, управляющему коммерческие транзакции. 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 – набор определённых и стандартизированных определений, вносящий порядок в хаос в случайные варианты лицензий, принятые в разных организациях.
Мы увидели, как её подход к определению авторства и вопросам авторских прав влияет на практику управления имущественными правами в академических и коммерческих организациях.
Мы увидели, как она даёт права на ПО всем, бесплатно, на условиях, защищающих лицензиаров от исполнения гарантий и ответственности.
Мы увидели, что, несмотря на немного корявое многословие и юридическую манерность, это 171 слово выполняют огромную юридическую работу и расчищают путь ПО с открытым кодам через густые кустарники интеллектуальной собственности и контрактов.
Автор: SLY_G
