Наверняка профессиональному юристу такой список покажется небольшим, и он без труда разберётся в особенностях той или иной лицензии. Однако техническому специалисту непросто понять смысл, скрывающийся за явно перегруженными с его точки зрения формулировками. Более того, даже не все разработчики понимают, зачем нужно лицензирование, и искренне считают, что свободное ПО предполагает отсутствие каких бы то ни было ограничений.
В действительности, у всех открытых лицензий есть только одна прагматичная цель. В них сформулированы правила, которыми должны руководствоваться другие разработчики, если они заходят как-то использовать чужой код. Это может быть как создание производного продукта, так и вклад в развитие оригинального.
Открытые лицензии можно разделить на несколько больших категорий. У каждой их них есть свои особенности с точки зрения практического применения. Вероятнее всего, начинающим свои проекты разработчикам целесообразней ориентироваться именно на типы лицензий, выбирая наиболее подходящий для себя.
Сравнение лицензий с открытым исходным кодом GPL / MIT / Apache
GNU General Public License
Этот тип лицензий позволяет копировать исходный код без каких-либо ограничений. Копии можно размещать на рабочих станциях и серверах, причём делать это неограниченное число раз.
Также GNU GPL не накладывает никаких ограничений на распространение программ ни по количеству, но по форме. Код можно переносить на специальных накопителях, можно дать ссылку для загрузки, можно даже распечатать его на бумаге и раздавать всем желающим.
Этот тип лицензий позволяет любому физическому или юридическому лицу брать деньги за услугу по распространению ПО. Правда, потенциальный покупатель должен быть предупреждён, что продавец не имеет каких-либо эксклюзивных прав, поэтому то же самое решение можно получить совершенно бесплатно. Это качество также даёт возможность объяснить, за что именно берётся плата.
Наконец, GNU GPL позволяет вносить в код любые изменения, удалять или добавлять любые функции. Правда только при условии, что полученный таким образом продукт также должен распространятся на условиях той же лицензии.
Разработчикам следует знать, что использование GNU GPL предполагает соответствие неким стандартам оформления кода. Внутри него в комментариях должны быть изложены лицензионные требования.
GNU Lesser General Public License
Ранее название этого типа лицензий — GNU Library General Public License. LGPL чаще всего применяется для библиотек ПО, поскольку позволяет использовать их не только в свободных, но и проприетарных приложениях.
В проприетарном ПО распространяемый на условиях LGPL код применяется в форме разделяемой библиотеки. Эта мера обеспечивает разграничение между закрытыми и открытыми компонентами в программе, сама же лицензия не требует открытия кода всего решения.
LGPL, в отличие от GPL, носит компромиссный характер. Она не гарантирует пользователю полную свободу всех производных продуктов, но позволяет использовать открытый код в проприетарных решениях, причём открытые модули должны оставаться открытыми.
03 Виды лицензий ПО
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 есть одна интересная для многих разработчиков особенность — она не ставит обязательным условием неизменность лицензии. Таким образом, правила распространения модифицированной версии какой-либо программы могут отличаться от исходных.
Эта лицензия в основном защищает права авторства. Например, в любой распространяемый пакет должен входить текстовый файл, в котором перечисляются все библиотеки, лицензированные на условиях Apache, и имена их разработчиков.
Разумеется, право на изменение лицензии не означает возможности её отзыва. Никто не имеет права менять условия, которые уже были однажды определены.
Источник: www.itweek.ru
Какую лицензию выбрать для своей программы
Нас часто спрашивают, какую лицензию мы рекомендуем для их проекта. Мы открыто писали об этом раньше, но сведения были разбросаны по разным очеркам, пунктам вопросов и ответов и пояснениям к лицензиям. В этой статье все эти сведения собраны в один источник, чтобы людям было легче следовать им и ссылаться на них.
Приводимые ниже рекомендации применимы к лицензированию работ, которые вы создаете — это может быть доработка существующих работ или оригинальные новые работы. Вопрос комбинирования существующего материала под разными лицензиями в них не рассматривается. Если вам нужна помощь в этом вопросе, сверьтесь, пожалуйста с нашими ответами на вопросы о GPL.
Если вы захотите проконсультироваться после того, как прочтете наши рекомендации, вы можете написать по адресу . Имейте в виду, что нашей группе лицензирования, вероятно, потребуется несколько недель, чтобы вам ответить; если вы не получили ответа в течение месяца, напишите, пожалуйста, еще раз.
Вклад в существующий проект
Когда вы делаете вклад в существующий проект, вам обычно следует выпускать свои измененные версии под той же лицензией, под которой выпущена первоначальная работа. Сотрудничество с разработчиками проекта — это хорошо, а применение другой лицензии для ваших доработок часто сильно затрудняет это сотрудничество. Вам следует применять другую лицензию, только когда есть веский довод, оправдывающий это.
Если вы по какой бы то ни было причине решаете выпускать свои доработки под другой лицензией, вы должны убедиться, что первоначальная лицензия позволяет использовать материал на условиях выбранной вами лицензии. Чтобы быть честными, указывайте явно, какая лицензия распространяется на какие части работы.
Программы
Краткий гид по open‑source лицензиям
Перед тем как выложить software-продукт в сеть, хорошо бы подумать об авторских правах и возможных нюансах использования вашего кода. Здесь на помощь приходят open-source лицензии. Сегодня мы рассмотрим наиболее популярные из них:
- GNU GPL
- MIT
- 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 [yyyy] [name of copyright owner] 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. Полный список лицензий есть на сайте choosealicense.
If you like this article, share a link with your friends
Read more
We talk about interesting technologies and share our experience of using them.
Источник: codex.so