Условий использования сервиса, которые прояснили (наконец-то) правовой статус GitHub относительно проектов, которые он хранит, компания решила пойти дальше в том, чтобы помочь пользователям разобраться, на что они имеют право, а на что - нет. С этой целью на страницу просмотра файла LICENSE из корневой директории проекта были добавлены краткие сведения о лицензии с сайта Choose A License :
Мы решили перевести для вас эти замечания, чтобы вы в случае необходимости могли быстро вспомнить, зачем нужна та или иная лицензия. Ниже мы приводим краткие описания лицензий и таблицы, которые содержат три колонки:
Разрешения * распространять, * использовать в коммерческих целях или * изменять работу значат ровно то, что написано - вы можете пользоваться этими правами, но лишь до тех пор, пока соблюдаете условия, указанные в секциях * «Требует» и * «Запрещает».
Пункт * «Разрешает личное использование» (англ. private use ) означает, что если вы изменяете работу, вы не обязаны её распространять - на своей машине вы можете делать с кодом всё, что захотите.
Пункт * «» означает что соавторы работы (контрибьюторы) отказываются от патентных прав (если они есть) на те части кода, которые они добавили; это гарантирует безопасность при использовании работы - иск на вас точно не подадут.
Пункты * «Отказ от ответственности» и * «Никакой гарантии» означают, что ни при каких условиях авторы произведения не могут быть ответственны за последствия его использования, продажи и вообще чего угодно.
Отличительной особенностью этой лицензии от основной лицензии GPL является то, что если кто-то предоставляет доступ к программе по сети (например, через интернет), то это считается распространением, а значит, распространитель обязан представлять исходный код, если от него этого потребуют.
Оригинальный текст Перевод на русский
Разрешает:
*
Коммерческое использование
*
Распространение
*
Изменение
*
Личное использование
*
Предоставление патентных прав
Требует:
*
Распространять исходный код вместе с продуктом
*
Упоминания авторства и лицензии в работе
*
Указывать изменения, внесённые в работу
*
Производные продукта необходимо выпускать под той же лицензией
Запрещает:
*
Отказ от ответственности
*
Никакой гарантии
Это самая популярная копилефтная лицензия. От предыдущей она отличается только тем, что не приравнивает использование программы по сети к её распространению.
Оригинальный текст Перевод на русский
Разрешает:
*
Коммерческое использование
*
Распространение
*
Изменение
*
Личное использование
*
Предоставление патентных прав
Требует:
*
Распространять исходный код вместе с продуктом
*
Упоминания авторства и лицензии в работе
*
Указывать изменения, внесённые в работу
*
Запрещает:
*
Отказ от ответственности
*
Никакой гарантии
От основной GPL лицензии эта отличается тем, что использование работы под LGPL в качестве части для большей работы (т.е. в качестве библиотеки) не накладывает требования лицензировать бо льшую работу под LGPL, или открывать её исходный код. Но код самой библиотеки все равно должен предоставляться по первому требованию.
Оригинальный текст
Разрешает:
*
Коммерческое использование
*
Распространение
*
Изменение
*
Личное использование
*
Предоставление патентных прав
Требует:
*
Распространять исходный код вместе с продуктом (в случае использования в качестве библиотеки - только исходный код библиотеки)
*
Упоминания авторства и лицензии в работе
*
Производные продукта необходимо выпускать под той же лицензией (но можно использовать продукт в качестве библиотеки)
Запрещает:
*
Отказ от ответственности
*
Никакой гарантии
*
Ещё одна лицензия, которая хорошо подходит для библиотек из-за слабого копилефта. В отличие от LPGL, при использовании работы под этой лицензией в качестве библиотеки, не нужно открывать даже исходный код самой библиотеки, равно как и указывать изменения, которые были внесены в работу.
Лицензия отдельно оговаривает, что для производных работ нельзя использовать те же названия, если они являются торговым марками.
Оригинальный текст Перевод на русский
Разрешает:
*
Коммерческое использование
*
Распространение
*
Изменение
*
Личное использование
Требует:
*
Упоминания авторства и лицензии в работе
Запрещает:
*
Отказ от ответственности
*
Никакой гарантии
Одна из так называемых «разрешительных» лицензий - с работой можно делать что угодно до тех пор, пока вы указываете автора оригинальной работы. Производные работы можно выпускать под другой лицензией и не открывать их исходники. Однако эта лицензия не гарантирует пользователю патентных прав, поэтому вместо неё рекомендуется использовать Apache License, которая приведена ниже.
Оригинальный текст Перевод на русский
Разрешает:
*
Коммерческое использование
*
Распространение
*
Изменение
*
Личное использование
*
Предоставление патентных прав
Требует:
*
Упоминания авторства и лицензии в работе
*
Указывать изменения, внесённые в работу
Запрещает:
*
Никаких обязательств
*
Никакой гарантии
*
Не передаются права на торговые марки
Ещё одна разрешительная лицензия - от пользователей она требует только, если работа была изменена, писать об этом, и, конечно, указывать исходное авторство. Лицензия отдельно оговаривает, что для производных работ нельзя использовать те же названия, если они являются торговым марками.
Оригинальный текст
Разрешает:
*
Коммерческое использование
*
Распространение
*
Изменение
*
Личное использование
*
Предоставление патентных прав
Требует:
(Ничего не требует)
Запрещает:
*
Никаких обязательств
*
Никакой гарантии
Выпуская работу под этой лицензией, вы отказываетесь от всех прав на неё, буквально передавая её в общественное достояние - на тех, кто её использует, не накладывается никаких ограничений. Приятная новость в том, что вы не будете нести ответственность за то, что написали - отсутствие гарантии здесь прописано так же, как и везде.
Этого набора более чем достаточно, если вы хотите выбрать лицензию для своего Open Source проекта - не надо писать свою лицензию или использовать что-то более специфическое. Путаница, которая возникает из-за обилия лицензий и их совместимости друг с другом - актуальная проблема Open Source. Лицензия BSD достаточно популярна, но её сокращённый вариант полностью совпадает по смыслу с лицензией MIT, и GNU советуют использовать именно последнюю. Если же вы столкнулись с проектом, который использует какую-то нестандартную лицензию, и хотите узнать, что она вам разрешает, вы можете подсмотреть в шпаргалке на сайте Choose A License.
Пётр Соковых , транслятор двоичного кода в русский язык
Заблуждения, относительно того, что с программными продуктами 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.
В наши дни свободное программное обеспечение уже стало распространенным явлением в сфере высоких технологий. Этому есть огромное количество доказательств. Все больше и больше компаний открывают исходные коды своих проектов, что еще более ускоряет темпы роста этой культуры.
Мы склонны называть все продукты с открытым исходным кодом одним термином, считать их одной категорией. Так удобнее, но это всего лишь упрощение. Фундаментальная концепция открытого кода понятна всем, но права, обязанности и привилегии сторон интерпретируются по-разному. Это отражается на лицензиях свободного ПО. В этой статье мы рассмотрим основные виды свободных лицензий, а также насколько они популярны.
Одна из самых распространенных лицензий программного обеспечения - лицензия GNU GPL. Ее суть во взаимности. Лицензия требует, чтобы если код был изменен, то все изменения были обязательно опубликованы и доступны всем. Это называется копилефт. Но есть другие типы лицензии, которые строятся вокруг свободы для разработчика. Такие лицензии накладывают минимальные ограничения на пользователей и не требуют взаимности от разработчиков. Оба типа лицензий свободны, разница только в том, что именно остается свободным.
За последние десятилетие более чем две трети проектов с открытым исходным кодом распространяются под лицензией GPL. Можно предположить, что это лицензия по умолчанию, но все же на протяжении последних лет эта лицензия теряет популярность, а вместо нее начинают использоваться разрешающие лицензии.
Если сравнить долю каждой из лицензий по рейтингу Black Duck в этом месяце, по сравнению с январем 2010, то различие вполне очевидно:
В этом рейтинге самой популярной остается GPLv2, но она потеряла больше половины своей популярности, от 46% до 19%. За этот же период разрешительная лицензия MIT выросла от доли 8% до 29%. Apache License 2.0 выросла с 5% до 15%.
Можно предположить, что если в 2007 мы говорили о свободном по, то имели в виду копилефт лицензию GPL, тогда как сейчас фоукс сместился в сторону разрешающих MIT и Apache. Это не означает, что копилефт лицензии становятся менее важными, просто в наше время разработчикам больше нравятся разрешающие лицензии. Вот какие выводы мы можем сделать из этого графика:
Консолидация. Это топ 10 лицензий по популярности за 2010 и 2016 год, все, кроме трех из них, снизились в популярности. Больше всего снизилась лицензия GPL, а выросли Apache и MIT, это уже обсуждалось. Но примечательно, что достаточно популярная лицензия BSD, наоборот, снизилась. Та же тенденция у лицензии ISC. Сейчас только несколько лицензий являются самыми популярными и, возможно, скоро мы будем видеть консолидацию между несколькими лицензиями.
Бинарный выбор . Исторически так сложилось, что у вас есть три основных варианта выбора лицензии: копилефт, разрешающая и среднее положение. К средним лицензиям можно отнести LGPLv2.1 (4), LGPLv3 (2), EPL (1), MPLv1.1 (<1), CDDL (<1) и CDDLv1.1 (<1) они имеют общую долю порядка 7-8%. Теперь все больше и больше выбор сводится к копилефт или разрешающим лицензиям.
Без лицензии. Сколько бы ни говорилось об открытых лицензиях, но до сих пор остаются репозитории открытых проектов с кодом, не использующим ни одну из лицензий. Со временем процент лицензированных репозиториев сокращается:
Есть много объяснений этому явлению, например,безразличие разработчиков. Но все открытые программы без лицензии - это не открытое программное обеспечение и это плохо.
А теперь давайте сделаем краткое описание для каждой лицензии из рейтинга чтобы вы могли ориентироваться что они из себя представляют:
GNU General Public License. Расшифровывается как универсальная общественная лицензия. Была разработана в 1988 году в рамках проекта GNU. Принцип действия лицензии, как уже говорилось, все изменения кода должны быть опубликованы. Программа не может быть включена в проприетарное ПО, но зато может свободно распространяться между пользователей, изучаться и улучшаться при условии публикации улучшений. За время развития было выпущено три версии - GPLv1, GPLv2 и GPLv3, в которых были немного ослаблены ограничения лицензии gpl к проприетарному ПО.
MIT License. Это лицензия, разработанная Массачусетским технологическим институтом (МТИ). Это разрешительная лицензия, а это значит, что несмотря на свободность распространения, ПО может использоваться в качестве части проприетарных программ.
Apache License 2.0. Это еще одна разрешительная лицензия. Кроме того, что разрешается полностью свободно распространять продукт, программы можно встраивать в проприетарное ПО. Но нельзя изменять название, а в файлах нужно прикладывать всю информацию об изменениях и лицензии.
Artistic License - свободная лицензия, разработанная The Perl Foundation. Это копилефт лицензия, она требует чтобы все изменения были опубликованы, а в файлах были описаны вносимые правки.
BSD Licese 2.0. Лицензия на программное обеспечение университета Беркли. Лицензия очень похожа на MIT, и программное обеспечение тоже можно встраивать в проприетарные проекты. Но здесь нельзя использовать оригинальное название свободного проекта.
Code Project Open 1.0.2 License. Это лицензия, опубликованная сообществом разработчиков The Code Project. Она разрешает использовать исходный код и сами программы в коммерческих целях, код можно изменять и включать в другие проекты.
Mozilla Public License (MPL) 1.1. Эта лицензия была разработана в компании Netscape и улучшена в Mozilla Foundation. Разрешается использование кода в закрытых проектах, но измененный код должен быть лицензирован в соответствии с MPL.
Microsoft Public Licese (MS-PL) - это свободная лицензия, которая предоставляет право на использование, распространение и изменение кода. Но при распространении нужно сохранить информацию об авторских правах.
Понятие об отличиях основных лицензий свободного ПО на одной схеме:
В этой статье мы рассмотрели основные типы свободных лицензий, а также некоторые самые популярные лицензии и их процент использования. Надеюсь эта информация была полезна для вас.
Небольшое видео по теме свободных лицензий и лицензии GPL:
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.
Лицензия MITCopyright «год» «владельцы прав»
Данная лицензия разрешает лицам, получившим копию данного программного обеспечения и сопутствующей документации (в дальнейшем именуемыми «Программное Обеспечение»), безвозмездно использовать Программное Обеспечение без ограничений, включая неограниченное право на использование, копирование, изменение, слияние, публикацию, распространение, сублицензирование и/или продажу копий Программного Обеспечения, а также лицам, которым предоставляется данное Программное Обеспечение, при соблюдении следующих условий:
ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ, СООТВЕТСТВИЯ ПО ЕГО КОНКРЕТНОМУ НАЗНАЧЕНИЮ И ОТСУТСТВИЯ НАРУШЕНИЙ, НО НЕ ОГРАНИЧИВАЯСЬ ИМИ. НИ В КАКОМ СЛУЧАЕ АВТОРЫ ИЛИ ПРАВООБЛАДАТЕЛИ НЕ НЕСУТ ОТВЕТСТВЕННОСТИ ПО КАКИМ-ЛИБО ИСКАМ, ЗА УЩЕРБ ИЛИ ПО ИНЫМ ТРЕБОВАНИЯМ, В ТОМ ЧИСЛЕ, ПРИ ДЕЙСТВИИ КОНТРАКТА, ДЕЛИКТЕ ИЛИ ИНОЙ СИТУАЦИИ, ВОЗНИКШИМ ИЗ-ЗА ИСПОЛЬЗОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЛИ ИНЫХ ДЕЙСТВИЙ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ.
К счастью, инициатива открытых проектов 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 года устранил необходимость соблюдения формальностей. В США владельцам прав до сих пор необходимо регистрировать свои работы перед судебными разбирательствами, но на практике это делается уже непосредственно перед самим судом. Вы не потеряете копирайт, если просто забыли о нём заявить, зарегистрировать, отправить копию в Библиотеку конгресса, и т.п.
Но даже если эти заявления уже не обязательны, они всё ещё довольно полезны. Обозначив год, в котором была сделана некая работа и права на неё, можно сразу же дать понять, когда эти права истекут и работа станет всеобщим достоянием. Личности авторов тоже полезны – в США законы по-разному относятся к отдельным авторам и группам авторов. В бизнесе компания дважды подумает, прежде чем будет использовать софт от своего соперника, даже если лицензия это позволяет. Если вы надеетесь, что другие заметят вашу работу и захотят получить от вас лицензию, информация о правообладателе тоже будет полезной.
Для владельца копирайта место есть не во всех лицензиях. Более современные лицензии, например, 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, в котором перечислены все люди, сделавшие свой вклад, с именами, членством, областью вклада и другими данными.
Данная лицензия разрешает лицам, получившим копию данного программного обеспечения и сопутствующей документации (в дальнейшем именуемыми «Программное Обеспечение»),
Иногда закон разделяет лицензию и обещание в передаче лицензии. Если кто-то нарушает обещание передать вам лицензию, вы можете засудить его за нарушение обещания, но при этом вы можете так и не получить лицензию. В данном предложении [в английской версии для этого служит архаизм «hereby» – прим. перев. ] поясняется, что сам по себе текст этой лицензии уже даёт вам лицензию, а не просто обещание её передачи.
И хотя множество лицензий дают разрешение на определённую поименованную лицензию, лицензия от MIT – это «общественная лицензия». Общественные лицензии дают разрешение всем, т.е. – обществу. Это одна из трёх великих идей, стоящих за лицензиями для открытого кода. Лицензия MIT использует эту идею, предлагая лицензию всем «лицам, получившим копию данного программного обеспечения».
Обозначение понятия в скобках и кавычках («Определение») – стандартный способ придания терминам определённого значения в легальных документах. Этим терминами стороны смогут пользоваться в судебном разбирательстве.
безвозмездно использовать Программное Обеспечение без ограничений,
включая неограниченное право на использование, копирование, изменение, слияние, публикацию, распространение, сублицензирование и/или продажу копий Программного Обеспечения, а также лицам, которым предоставляется данное Программное Обеспечение,
Во-первых, «включая неограниченное право» – это пример того, как не нужно писать юридические тексты. Бывают вариации этой формулировки:
Все они пишутся для одной цели, и ни одна из них её не достигает. Использующие их юристы хотят и рыбку съесть, и на мель не сесть. В лицензии MIT они означают попытку представить определённые примеры «использования ПО» – «использование, копирование, изменение,», и проч.,- не имея в виду, что использовать это ПО можно будет только одним из перечисленных способов. Проблема в том, что если представить такую лицензию в суде, то суду для понимания лицензии придётся определять значения указанных терминов. Если суд захочет понять, что означает «использовать ПО», он не сможет «развидеть» указанные в лицензии примеры использования. Я бы сказал, что лучше всего написать в лицензии «использовать ПО без ограничений». Это ещё и короче.
Во-вторых, перечисленные термины представляют собой мешанину. Некоторые из них описаны в законах об авторских правах и патентах, а некоторые – нет.
при соблюдении следующих условий
Если вы не выполните условия, вы не получите разрешения. Поэтому теоретически в таком случае вас могут засудить, скорее всего, по закону об авторских правах.
Использовать ценность софта как мотивацию лицензиата на выполнение условий, хотя он за лицензию и не платил, это вторая великая идея софта с открытым кодом. Последняя, которой в лицензии MIT не нашлось места, основана на условиях лицензии – такие лицензии, как GNU Public License, используют условия для контроля над тем, как вносящие изменения люди могут лицензировать и распространять изменённые версии.
Указанное выше уведомление об авторском праве и данные условия должны быть включены во все копии или значимые части данного Программного Обеспечения.
Эти условия, к сожалению, выполняются плохо. Почти в каждой лицензии открытого ПО есть такие условия. Создатели системного и устанавливаемого ПО часто понимают, что им необходимо выводить файл с лицензионной информацией на экран, включать копии лицензии в библиотеки и компоненты. Фонды, управляющие проектами, обучают этим практикам. Но веб-разработчики, видимо, не получали уведомления. Нет им прощения.
ДАННОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ, СООТВЕТСТВИЯ ПО ЕГО КОНКРЕТНОМУ НАЗНАЧЕНИЮ И ОТСУТСТВИЯ НАРУШЕНИЙ, НО НЕ ОГРАНИЧИВАЯСЬ ИМИ.
Некоторые правила UCC обязательны для исполнения и применяются всегда. Другие лишь описывают состояние «по умолчанию» – если продавцы и покупатели не напишут в соглашении чего-либо иного. Среди таких правил по «умолчанию» находятся и гарантии, то есть обещания продавцов покупателям по поводу качества и годности для использования продуктов.
Идут споры о том, являются ли публичные лицензии вроде MIT контрактами – соглашениями, к которым можно принудить лицензиатов и лицензиаров – или же это просто лицензии, к которым могут быть прикреплены условия. Чуть меньше споров идёт по поводу того, является ли ПО товаром, и входит ли, таким образом, в юрисдикцию UCC. Но насчёт ответственности у лицензиаров спора нет: никто не хочет, чтобы его засудили, если раздаваемый им софт ломается, причиняет проблемы, не работает, или ещё как-то отрицательно проявляет себя. Это прямо противоположно тому, что описывают три правила гарантий по умолчанию:
Юристы давно заблуждаются, что написав текст ЗАГЛАВНЫМИ БУКВАМИ, они выполняют требование заметности. Это не так. Заглавные буквы часто отталкивают читателя вместо того, чтобы привлекать его внимание. Но большинство лицензий открытого кода пишут эту часть заглавными, поскольку это самый очевидный способ сделать текст в простых текстовых файлах выделяющимся. Я бы предпочёл использовать звёздочки или другой ASCII-art, но этот поезд уже ушёл.
НИ В КАКОМ СЛУЧАЕ АВТОРЫ ИЛИ ПРАВООБЛАДАТЕЛИ НЕ НЕСУТ ОТВЕТСТВЕННОСТИ ПО КАКИМ-ЛИБО ИСКАМ, ЗА УЩЕРБ ИЛИ ПО ИНЫМ ТРЕБОВАНИЯМ, В ТОМ ЧИСЛЕ, ПРИ ДЕЙСТВИИ КОНТРАКТА, ДЕЛИКТЕ ИЛИ ИНОЙ СИТУАЦИИ, ВОЗНИКШИМ ИЗ-ЗА ИСПОЛЬЗОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЛИ ИНЫХ ДЕЙСТВИЙ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ.
Обычно суды тщательно читают отказы от гарантий, поскольку это может помочь переложить риск с одной стороны на другую. Чтобы дать народу возможность защитить себя, в любых возможных случаях суды интерпретируют эти отказы против того, кого они защищают. Часто суды отказываются принимать их во внимание, если такие условия находятся где-то в глубине контракта и не выделяются. Поэтому юристы привыкли писать и их заглавными буквами.
Ограничение ответственности, в числе прочего, ограничивает и сумму денег, на которую можно засудить лицензиата. У открытых лицензий это ограничение всегда нулевое. В коммерческих лицензиях часто встречаются суммы, кратные лицензионным отчислениям, оплаченным за последние 12 месяцев.
В этой секции перечисляются те типы законных преследований, которые лицензиар не может использовать. Как и многие легальные формы, эта лицензия упоминает нарушения контрактов и деликты . Правила деликтов относятся к совершению поступков, влекущих за собой возмещение ущерба. Если вы задавили кого-то на дороге, отправляя SMS, вы совершили деликт. Если ваша компания продала бракованные наушники, которые сожгли людям уши, она совершила деликт. Если в контракте не указано явно исключение требований по деликтам, суды иногда этим пользуются. В лицензии MIT указано «по иным требованиям», чтобы исключить всякие экзотические требования.
Фраза "ВОЗНИКШИМ ИЗ-ЗА ИСПОЛЬЗОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЛИ ИНЫХ ДЕЙСТВИЙ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ " – нервный тик, характерный для приобретённого страха за свою безопасность у юриста. Смысл в том, что любой иск, связанный с этим ПО, покрывается ограничениями и исключениями. Однако использование ПО вполне входит в «иные действия» с ПО. [в оригинале лицензии указано три варианта событий «arising from», «in connection with», «use» – то есть, «возникающих из», «в связи с» и «при использовании», которые, по сути, дублируют друг друга, что и вызывает претензии у автора статьи – прим. перев. ] Однако такой язык используется в миллионах других лицензий.
Мы увидели, что лицензия MIT – набор определённых и стандартизированных определений, вносящий порядок в хаос в случайные варианты лицензий, принятые в разных организациях.
Мы увидели, как её подход к определению авторства и вопросам авторских прав влияет на практику управления имущественными правами в академических и коммерческих организациях.
открытое по
Добавить метки
Тема свободных, открытых, а также, на первый взгляд, непривычных browse -wrap лицензий обрела новое звучание. Чтобы разобраться, что изменилось в регулировании, сначала необходимо определить, что же представляют из себя различные лицензии: shrink -wrap , click-wrap, browse-wrap, свободные и open -source лицензии, а также новые виды лицензий в том понимании, в котором они будут закреплены в части четвертой Гражданского кодекса Российской Федерации.
Прежде всего необходимо ознакомиться с историей развития правовых концепций использования программ для ЭВМ (далее по тексту для удобства будут использоваться термины «программа» и «ПО»). Проблема необходимости правового регулирования использования программ требовала решения, особенно после того как программы стали доступны огромному числу людей, а производители начали терпеть убытки из-за копирования программ, приобретенных пользователями. Для производителей в США это стало настоящей проблемой также ввиду существования так называемой доктрины первой продажи (first-sale doctrine), сформулированной Верховным Судом США в решении по делу Bobbs-Merill Co. v . Strauss . Затем эта доктрина была закреплена в положениях закона об авторском праве 1909 г., а в законе об авторском праве 1976 г. (Copyright Act of 1976) (17 U.S.C. § 109 (а)) она уже была оформлена в более совершенном виде, закрепляя положение о том, что законный владелец конкретной копии (то есть экземпляра результата интеллектуальной деятельности, охраняемого авторскими правами) или иное лицо, наделенное полномочиями, вправе продавать или распоряжаться данным экземпляром иным образом.
C появлением программ, широко распространяемых на CD (дистрибутивах), правообладатели стали опасаться, что такие дистрибутивы будут перепродаваться покупателями (на основании доктрины первой продажи). В связи с этим появилась идея размещать текст лицензионного соглашения (регламентирующего виды использования программы) на упаковках программных продуктов с условием, что потребитель, разрывая оберточную бумагу (обертку), выражает свое согласие с условиями этого соглашения и тем самым заключает договор с правообладателем ПО. Такой договор определяет правомочия сторон, а также ограничивает право покупателя на распоряжение программой (в части перепродажи). Эти соглашения получили название shrink-wrap agreements (дословно — соглашения на упаковке). По сути, американские производители ПО, ссылаясь на § 109 (d) , предусматривающий невозможность применения доктрины первой продажи, если владение экземпляром осуществляется при отсутствии права собственности, указывали на оберточной бумаге виды разрешенного использования, подчеркивая, что программное обеспечение «лицензируется, а не продается» (licensed, not sold). Этот тезис о лицензировании был подтвержден в деле Timothy S. Vernor v. Autodesk, Inc . Истец (Тимоти Вернор) выставил на продажу на eB ay купленные им диски с программой AutoCAD, за что стал получать предупреждения от правообладателя. После принудительного закрытия аккаунта на eB ay он обратился в суд, считая, что никакого правонарушения не совершал, ведь обертку не снимал, диск не устанавливал иознакомиться с условиями лицензии не мог. Апелляционный суд девятого округа США указал, что приобретатель CD с программой приобретает право собственности на носитель, а не на программу как таковую, потому для определения прав покупателя нужно обращаться к тексту лицензии, в которой указано на исключительное право распространения программы, принадлежащее лишь организации-правообладателю или же организации, наделенной полномочиями по продаже .
Следующим этапом развития лицензирования ПО стали так называемые click -wrap agreements , то есть договоры, акцепт которых производится кликом. Если пользователь желает воспользоваться функционалом, предоставляемым онлайн, ему необходимо передвинуть курсор на окошко «I Accept » («Я соглашаюсь») и щелкнуть OK . В США правомочность таких соглашений также была подтверждена в решении по делу Hughes v . McMenanon : «…Если суды признают действительными условия shrink -wrap лицензий, то условия click -wrap соглашений должны быть признаны таковыми тем более, поскольку согласие пользователя с ними является более выраженным» .
В современном мире технологий все автоматизируется, совершенствуется и упрощается. Эта тенденция отразилась и на способах заключения лицензионных соглашений: появились browse -wrap лицензии, которые представляют собой помещенные на сайте кликабельные условия использования сайта, однако пользователь не выражает согласия с ними в явном виде (нет отдельного окна, в котором пользователь ставил бы «галку» о согласии с условиями использования). Сами же правила предусматривают, что просмотр или иное использование сайта предполагает выражение согласия с данными условиями.
А. И. Савельев указывает, что, как правило, все условия, предусмотренные правилами пользования сайтом, можно разделить на информационные и регулятивные. К примеру, условия использования сайта Amazon.com содержат также порядок подачи заявлений о нарушении авторских прав, порядок рецензирования товаров, запреты на коммерческое использование размещенной на сайте информации и использование роботов для сбора информации на сайте .
Необходимо остановиться на рассмотрении вопроса, когда в случае использования click-wrap и browse-wrap лицензий договор считается заключенным. Требования к форме договора содержатся в ст. 434 ГК РФ, а подходящее обоснование способа заключения договора — в п.3 ст. 438 ГК РФ: акцепт оферты конклюдентными действиями. С октября 2014г. вступит в силу новая редакция п. 5 ст. 1286 ГК РФ, вводящая упрощенный порядок заключения лицензионного договора на использование программ для ЭВМ и баз данных. Лицензионный договор, заключаемый в упрощенном порядке, является договором присоединения, условия которого могут быть изложены на приобретаемом экземпляре программы для ЭВМ или базы данных либо на упаковке такого экземпляра, а также в электронном виде.
Существует еще один пласт лицензий, характеризующихся определенной спецификой, — это свободные лицензии. Большая часть программ с открытым исходным кодом (open-source) являются одновременно свободными. Чтобы понять, что представляют из себя свободные и открытые лицензии, необходимо обратиться к истории их развития. В середине 1980-х гг. развивались два параллельных идеологических движения: за свободное программное обеспечение (Free Software Foundation, FSF, во главе с Ричардом Столлманом) и за создание и распространение ПО с открытым исходным кодом (OSI , идеологами которого были Брюс Перенс и Эрик Рэймонд).
Ричард Столлман, стоявший у истоков движения за свободное программное обеспечение, видел одной из задач разработчиков ПО сопротивление монополизму проприетарного (proprietary) ПО. В 1985 г. Столлман основал FSF, опубликовал «Манифест GNU» (в нем изложена идея General Public L icense, GPL), а также разработал операционную систему GNU GPL. Основным посылом его философии было распространение ПО на условиях полной свободы (которая становится не привилегией, а, скорее, обязательством!). Лицензия GPL, которую принято называть «копилефтной лицензией» (что означает, что любая копия программы, созданная на основании программы, лицензируемой по условиям GPL, должна быть свободной), рассматривается в статье ниже.
Примерно в те же годы зародилось движение за интеграцию ПО с открытым исходным кодом в бизнес. В 1997 г. был опубликован доклад «Собор и Базар» (The Cathedral and the Bazaar, сокращенно CatB) о методах разработки ПО, в котором анализировались «соборная» и «базарная» модели. «Соборная» модель подразумевает, что исходный код становится доступным после релиза программы, а в процессе разработки доступ к коду разрешен лишь разработчикам проекта. «Базарная» модель подразумевает разработку кода через Интернет «на виду» и при возможном участии общественности, что является более прогрессивным с точки зрения автора эссе, поскольку «при наличии достаточного количества глаз все ошибки всплывают» («given enough eyeballs, all bugs are shallow»). В 1998 г. Эрик Рэймонд и Брюс Перенс основали OSI (Open Source Initiative ) .
В настоящее время при упоминании свободных лицензий или свободного ПО имеют в виду ПО с открытым кодом, и наоборот. Однако разница все же существует, пусть и на уровне философии обоих движений. Свободное ПО — это обязательно открытый код, а вдобавок еще и четыре свободы :
запускать;
изучать и модифицировать;
распространять копии первоначальной программы;
распространять модифицированные версии.
У OSI есть свои критерии определения ПО с открытым исходным кодом, состоящие из десяти пунктов (OS definition ) и изложенные на сайте организации:
программа должна свободно распространяться ( не должна подразумевать какого-либо вознаграждения);
программа должна включать исходные тексты;
программа должна допускать модификации;
никакой дискриминации против лиц или групп;
никакой дискриминации в отношении областей деятельности (лицензия не должна запрещать использование программы в конкретной области деятельности);
права, связанные с программой, должны применяться ко всем, кому она будет распространена;
распространение программы в составе какого-либо программного продукта не должно зависеть от распространения самого программного продукта;
лицензия не должна ограничивать другое ПО;
лицензия должна быть технологически нейтральной.
OSI осуществляет сертификацию лицензий на предмет их соответствия указанным условиям. Только лицензии, удовлетворяющие перечисленным требованиям и сертифицированные OSI , могут именоваться open -source license . Перечень таких OSI -approved licenses указывается на сайте OSI .
Для любого пользователя ПО крайне необходимо точно понимать, на каких условиях его можно использовать. Поскольку ПО с открытым исходным кодом разрабатывается посредством распределенных совместных усилий многих участников, а впоследствии может быть использовано в коммерческих целях, то код выкладывается в общедоступные источники с указанием лицензий, которыми он регулируется. Большинство проектов по разработке ПО с открытым исходным кодом имеют «доверенные репозитории» (trusted repository), а именно — определенный веб-источник, где можно получить «официальную версию» программы. Изменять программу могут лишь создатели (creators). При этом пользователи могут направлять сообщения об ошибках в том числе напрямую в репозиторий. Однако основным отличием является то, что пользователь и сам может внести любые изменения. Опять же, получается некоторый цикл: чем более удобной (capable) становится программа, тем больше пользователей ее используют, и в итоге пользователь (или совокупность пользователей) становится разработчиком (user as developer).
Встает резонный вопрос: зачем вообще лицензия на свободное использование или зачем лицензия, которая очевидно разрешит делать с ПО все что угодно? Поскольку родина ПО — Америка, то в соответствии с требованиями о копирайте пользователи должны получить разрешение от правообладателя до того, как они запустят программу. Таким образом, любое ПО, предоставляемое в пользование неопределенному круг лиц, должно сопровождаться лицензией (то есть явно выраженными условиями последующего использования).
Наиболее известным хостингом свободных проектов является GitHub, команда которого в 2013 г. запустила новый сайт C hooseAL icense.com для упрощения принятия решения о выборе той или иной лицензии при создании репозитория с кодом. На сайте в краткой форме описаны особенности основных открытых лицензий. На главной странице регистрации нового репозитория в GitHub появилась форма выбора лицензии, позволяющая автоматически сформировать файл с выбранным типом лицензии, чтобы не приходилось копировать условия лицензии вручную. Такая автоматизация понадобилась еще и потому, что зачастую код размещался без явного указания лицензии, что формально не давало возможности без согласия автора использовать код в проектах .
Несмотря на различия в философии FSF и OSI , в обеих идеологиях подход к open -source одинаков, потому границы между свободными лицензиями и ПО с открытым исходным кодом стираются. Широко используется FOSS и FLOSS (разница лишь в наличии буквы L ), что означает Free/Libre and Open-Source Software — свободное программное обеспечение с открытыми исходными кодами. Указанная категория включает в себя как свободное, так и открытое программное обеспечение. В английском языке слово Free означает как «свободный», так и «бесплатный», поэтому в термин FOSS (Free and Open-Source Software) было включено слово Libre (фр.«свободный»), чтобы подчеркнуть, что речь идет именно о свободном ПО.
Определив, что различия в идеологии не влияют на общий смысл, порядок лицензирования и использования ПО, далее будем употреблять термин «свободные лицензии».
Лицензии подразделяются на две основные группы: разрешительные лицензии (permissive licenses ), содержащие минимум условий (BSD , MIT , Apache ), и взаимные лицензии (reciprocal licenses , copyleft ), налагающие обязанность распространять модификации программы на тех же условиях, на которых распространялась исходная программа (GPL , LGPL , MPL ). К признакам всех свободных лицензий можно отнести следующие:
лицензии стандартизированы (GNU , CC , Apache , Mozilla );
наименование договора или соглашения, к условиям которого присоединяется пользователь, содержит указание на сам предмет (GNU GPL , LGPL );
в условия использования нельзя внести изменения, можно принять их как есть (as is );
лицензия является безотзывной.
Для более наглядного представления о наиболее известных лицензиях, под которыми распространяется код, необходимо ознакомиться с их условиями.
Самая простая и исторически первая из ныне используемых свободных лицензий — лицензия операционной системы BSD (Berkley Software Distribution License ) — появилась в начале 1980-х гг. Существовало три версии лицензии. Исходная лицензия («старая BSD», или «4-пунктовая BSD») называется так потому, что она содержала помимо условий о сохранении уведомления об авторском праве и требования о выдаче бумажной лицензии еще и указание на необходимость упоминания об университете в случае публикации характеристик программы в рекламных материалах (advertising clause ). «Новая BSD» («модифицированная BSD», или «3-пунктовая BSD») уже не содержит обременительного условия о рекламе. Лицензия предоставляет полную свободу распространения кода, на любых условиях, с исходными текстами или без них, и заботится только об охране честного имени организации-автора. Лицензии BSD -типа относятся к разрешительным лицензиям, поскольку не требуют использования той же лицензии для производных произведений (downstream versions ). Лицензия содержит стандартный набор условий, предусматривающих предоставление программы «как есть» в отсутствие каких-либо гарантий, с исключением ответственности за любые убытки, которые могут быть причинены программой.
Лицензия MIT (Massachusetts Institute of Technology ) по содержанию похожа на лицензию BSD , однако содержит формулировки, допускающие сублицензирование (то есть права каждому последующему пользователю предоставляются предыдущим, а не первоначальным) .
Лицензия Apache 2.0 (Apache Software Foundation ) разрешает распространять производные продукты под условиями иных лицензий, а также позволяет разработчикам самим решать, сохранять ли для итогового продукта статус бесплатного и открытого. Единственным условием, накладываемым лицензией Apache, является информирование получателя о факте использования исходного кода. Таким образом, в противоположность copyleft -лицензиям, получатель модифицированной версии не обязательно получает все права, изначально предоставляемые лицензией Apache.
При распространении программного обеспечения необходимо поместить следующие файлы в корневую директорию: license — файл, содержащий копию текста лицензии Apache; notice — текстовый файл, перечисляющий все библиотеки, лицензированные под Apache, с именами их создателей.
В процессе развития все эти лицензии претерпевали определенные изменения, которые в итоге сделали их универсально применимыми (удалялись лишние условия, добавлялись необходимые). Похожий путь прошла и лицензия Mozilla (Mozilla Public License , MPL ), однако, учитывая, что она изначально была составлена юристами, в ней все было сформулировано более логично. В случае если распространяется файл, содержащий первоначальный код или ранее сделанные модификации к нему, итоговые файлы лицензируются на условиях MPL . Целостный продукт при этом может распространяться под любой лицензией. В лицензии указаны два типа авторов: первоначальный автор и внесший вклад в доработку этого кода (contributor ). Таким образом, лицензия не ограничивает использование ПО в различных продуктах и гарантирует дальнейшее развитие проекта.
История проекта GNU началась в 1984 г., когда Ричард Столлман решил создать ПО, которое бы свободно распространялось и дорабатывалось. В итоге все условия использования, которые Столлман считал необходимыми, нашли выражение в лицензии GPL (General Public License ) . Пользователь вправе копировать, модифицировать и распространять исходный код, распространять скомпилированные версии, содержащие в себе как доработанный, так и исходный код. При этом все распространяемые копии должны содержать уведомление об авторском праве и об отсутствии гарантий на ПО, все доработанные версии подчиняются условиям GPL , все компилятивные версии (compiled versions ) должны сопровождаться исходным кодом или содержать указание на реальную доступность кода (viable offer ). К примеру, указание на то, что код раскрывается любому лицу по первому его требованию. По условиям лицензии каждому новому лицензиату права предоставляются непосредственно от первого лицензиара, то есть все пользователи вступают в отношения непосредственно с Free Software Foundation (FSF ).
GPL породила определенные мифы о жесткости применения. Считается, что если кто-то модифицировал ПО под GPL , то он обязан сделать ПО доступным. На самом деле если нет цели распространять ПО, то нет необходимости и обнародовать деривативное ПО.
В свое время поднимался вопрос о правомерности условия о необходимости подчинения программы, созданной на базе GPL , условиям этой же лицензии. Американские суды сошлись на том, что GPL не нарушает конкурентного права (anti-trust laws). В решении по делу Wallace v. FSF судья Даниэль Тиндер указал, что «GPL способствует, а не препятствует свободной конкуренции и распространению компьютерных программ» . Истец обращался в суд целью установления судебного запрета на использование GPL в связи с тем, что условия лицензии накладывают ограничения на коммерческий оборот, якобы устанавливая фиксированные цены на программное обеспечение. Тем самым, по мнению истца, происходило нарушение антимонопольного законодательства (Sherman Act). В итоге же суд не нашел никаких нарушений и по сути лишь укрепил своим решением легитимность условий лицензии.
За рубежом свободные лицензии существуют давно, и, несмотря на это, все равно возникают судебные споры. В России же дискуссии на тему использования свободных лицензий, то набирая обороты, то затухая, велись несколько лет.
В 2011 г. в рамках круглого стола «“Свободные лицензии” или самоограничение права?» в Российской школе частного права (РШЧП) состоялось обсуждение судьбы свободных лицензий в России . Круглый стол освещал предложенные на тот момент поправки в четвертую часть ГК РФ (озвученные на круглом столе членом рабочей группы В. Калятиным) и контраргументы юриста IBM А. Савельева, который стоял на позиции отсутствия необходимости особого регулирования свободных лицензий. По мнению А. Савельева (более подробно его взгляды изложены в монографии «Лицензирование программного обеспечения в России: законодательство и практика»), модель свободных лицензий вполне применима в рамках российского законодательства.
В конечном итоге поправки в четвертую часть ГК РФ были приняты Федеральным законом № 35 от 12 марта 2014 г. «О внесении изменений в части первую, вторую и четвертую Гражданского кодекса Российской Федерации и отдельные законодательные акты Российской Федерации». В контексте данной статьи ключевыми являются следующие изменения: пересмотр и дополнение положений об оберточных лицензиях (п. 5 ст. 1286 ГК РФ); введение положений об открытых лицензиях (ст. 1286.1 ГК РФ); введение нового способа распоряжения исключительным правом на произведение науки, литературы или искусства либо объект смежных прав — публичного заявления о предоставлении любым лицам возможности безвозмездно использовать результат интеллектуальных прав на определенных правообладателем условиях и в течение указанного им срока (п. 5 ст. 1233 ГК РФ).
Необходимо проанализировать нововведения ГК РФ с целью их сопоставления с зарубежными институтами свободных лицензий. На настоящий момент п. 5 ст. 1286 ГК РФ говорит о том, что заключение лицензионных договоров о предоставлении права использования программы для ЭВМ или базы данных допускается путем заключения каждым пользователем с соответствующим правообладателем договора присоединения, условия которого изложены на приобретаемом экземпляре такой программы или базы данных либо на упаковке этого экземпляра. Начало использования таких программ или баз данных пользователем, как оно определяется этими условиями, означает его согласие на заключение договора. С 1 октября 2014 г. п. 5 ст. 1286 ГК РФ излагается в новой редакции. Редакция статьи предусматривает алгоритм заключения лицензионного договора в упрощенном порядке, расширяя перечень вариантов изложения условий и указывая на возможность существования условий в электронном виде.
Также с 1 октября 2014 г. вступает в силу ст. 1286.1, в п. 1 которой определено понятие открытой лицензии, которая презюмируется безвозмездной, если ею не предусмотрено иное. В случае если срок действия открытой лицензии не определен, в отношении программ для ЭВМ и баз данных договор считается заключенным на весь срок действия исключительного права, а в отношении других видов произведений — на пять лет. Кроме того, поправки в ГК РФ определяют ответственность за нарушение условий открытых лицензий, в том числе дают возможность автору требовать применения к нарушителю мер защиты исключительного права в соответствии со ст. 1252 ГК РФ.
С 1 января 2015 г. вступает в силу п. 5 ст. 1233 ГК РФ, предусматривающий публичное заявление о возможности безвозмездного использования произведения. По сути, вводится новый способ распоряжения исключительным правом. Правообладатель может публично сделать заявление о предоставлении любым лицам возможности безвозмездно использовать принадлежащее ему произведение науки, литературы или искусства либо объект смежных прав на определенных им условиях и в течение указанного им срока. Причем законодатель регламентирует и процедуру совершения заявления: путем размещения на официальном сайте федерального органа исполнительной власти. Пока не ясно, какой именно орган предоставит площадку и будет каким-то образом вести реестр. В любом случае для программ ЭВМ будет использоваться именно механизм ст. 1286.1 ГК РФ. Содержание понятия открытой лицензии по ГК РФ не идентично понятию open-source лицензии. Ст. 1286.1 ГК РФ распространяет свое действие на произведения науки, литературы или искусства, программы для ЭВМ и базы данных, в то время как open-source лицензии регулируют лишь сферу использования программ для ЭВМ. ГК называет в качестве сторон лицензиара и лицензиата, а в open-source лицензиях могут существовать первоначальный автор, автор производного продукта и пользователь. Важным вспомогательным механизмом, введенным поправками к ГК РФ, является п. 3 ст. 1266 ГК РФ, закрепляющий применительно к п. 2 ст. 1286.1 ГК РФ и п. 5 ст. 1233 ГК РФ возможность дать согласие на внесение в будущем изменений, сокращений и дополнений в свое произведение, на снабжение его иллюстрациями и пояснениями, если это вызвано необходимостью (исправление ошибок, уточнение или дополнение фактических сведений ит.п.), при условии, что этим не искажается замысел автора и не нарушается целостность восприятия произведения.
В заключение хотелось бы отметить, что нововведения в гражданском законодательстве оцениваются неоднозначно. Если новую редакцию ст. 1286 ГК РФ и введение ст. 1286.1 ГК РФ можно смело оценивать положительно, то для оценки п. 5 ст. 1233 ГК РФ потребуется время. Практика покажет, будет ли востребован предложенный способ распоряжения правом посредством публикации заявления или же эта конструкция останется лишь на бумаге.
Федеральный закон № 35-ФЗ от 12.03.2014 «О внесении изменений в части первую, вторую и четвертую Гражданского кодекса Российской Федерации и отдельные законодательные акты Российской Федерации» // СПС «Консультант Плюс».
Савельев А. И. Лицензирование программного обеспечения в России: законодательство и практика. — М.: Инфотропик Медиа, 2012. — С. 183.
Савельев А. И. Электронная коммерция в России без ЭЦП: иллюзия иди реальность? // Вестник гражданского права 2013, №3 // СПС «Консультант Плюс».
