Обзор лицензионных соглашений, заключаемых нестандартными способами: сlick-wrap, browse-wrap, open-source и свободные лицензии в свете поправок в ГК РФ.

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

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

Несмотря на то, что GitHub - крупнейший в мире сервис для совместной работы над открытым кодом, значительная часть размещённых там проектов формально не имеют никакого отношения к Open Source. Причём вовсе не потому, что их авторы предпочитают проприетарные решения. На сервере опубликована масса ПО, не имеющего никакой лицензии.

По всей видимости, существует достаточно много разработчиков, считающих вопрос лицензирования если не совсем несущественным, то наверняка второстепенным. Например, в опубликованной на сайте Fossbytes.com статье, посвящённой этой проблеме, скрывающийся под псевдонимом gdad-s-river автор сообщает, что он выбирает лицензию случайным образом. Но вовсе не по причине правового нигилизма - он уверен, что его проект не особенно интересен другим людям и его код не будет использован для создания других инструментов.

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

• Apache License 2.0;
• BSD 3 (New BSD);
• BSD 2 (FreeBSD);
• GNU General Public License (GPL) v3.0;
• GNU Lesser General Public License (LGPL);
• MIT License;
• Mozilla Public License 2.0;
• Common Development and Distribution License;
• Eclipse Public License;
• Creative Commons License.

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

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

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

GNU General Public License

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

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

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

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

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

GNU Lesser General Public License

Ранее название этого типа лицензий - GNU Library General Public License. LGPL чаще всего применяется для библиотек ПО, поскольку позволяет использовать их не только в свободных, но и проприетарных приложениях.

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

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

BSD License

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

Выбирающий BSD разработчик по сути разрешает использование своего кода как в открытых, так и в проприетарных приложениях. Это свойство широко применяется на практике, в том числе в больших проектах. В частности, некоторые компоненты FreeBSD вошли в состав операционной системы Mac OS X.

Основная особенность BSD 3, которая часто называется BSD New, в том, что она ограничивает использование имён разработчиков в производных продуктах. На практике означает, что она по умолчанию запрещает применять имя автора для продвижения других программ - для этого требуется его специальное разрешение.

MIT License

Это самая короткая лицензия. Возможно, именно по этой причине она становится всё более популярной. По сути она разрешает всё.

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

Creative Commons

Эта группа лицензий предназначена не для ПО, а для «сопутствующих продуктов»: фотографий, рисунков, текстов, дизайнерских проектов и т. д. Прежде всего потому, что Creative Commons не требует включения в произведение текста лицензии, достаточно только указать соответствующее буквенное обозначение.

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

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

Apache License

У Apache License есть одна интересная для многих разработчиков особенность - она не ставит обязательным условием неизменность лицензии. Таким образом, правила распространения модифицированной версии какой-либо программы могут отличаться от исходных.

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