Руководство разработчика по лицензиям с открытым исходным кодом
Опубликовано: 2022-03-11Не все лицензии с открытым исходным кодом одинаковы. Некоторые из них обязывают поставщика программного обеспечения предоставлять патентные лицензии пользователям и разработчикам программного обеспечения. Другие лицензии обязывают разработчика, использующего лицензионный продукт или библиотеку, предлагать исходный код этого продукта или библиотеки на тех же условиях. Другие просто раздают код без каких-либо гарантий или каких-либо проблем. В этой статье я попытаюсь выделить основные различия между наиболее часто используемыми лицензиями с открытым исходным кодом с точки зрения пользователя программного обеспечения и разработчика программного обеспечения.
Когда в 1984 году Ричард Столлман начал проект GNU по созданию свободной операционной системы, он возродил идею о том, что программное обеспечение должно совместно использоваться разработчиками, инженерами и пользователями; и они должны иметь возможность улучшать его совместными усилиями, как это обычно делается в науке.
Этот вариант контрастировал с обычной концепцией лицензионного программного обеспечения, используемой большинством корпораций и разработчиков программного обеспечения для распространения и продажи своих программ. Сегодня, более тридцати лет спустя, программное обеспечение с открытым исходным кодом медленно продолжает завоевывать широкие сектора нашей отрасли: Linux, Android, Apache и Git являются примерами ведущих продуктов с открытым исходным кодом в своих категориях.
Открытый исходный код или бесплатное программное обеспечение?
В этой статье я буду использовать термины «открытый исходный код» и «бесплатный» как синонимы применительно к программному обеспечению или лицензиям. На мой взгляд, оба термина выражают одну и ту же идею. «Открытый исходный код» выражает это практическим и техническим образом, а использование «бесплатно» ставит акцент на философском и политическом значении понятия.
К сожалению, слово «бесплатно» в английском языке, помимо прилагательного, связанного со словом «свобода», также означает «бесплатно». По этой причине я обычно предпочитаю говорить «с открытым исходным кодом».
Общие свойства программного обеспечения с открытым исходным кодом
Я полагаю, что вы уже имеете приблизительное представление о том, что такое ПО с открытым исходным кодом. Но поскольку мы собираемся говорить о деталях различных лицензий, сначала нам нужно поговорить о конкретных свойствах, которые определяют программное обеспечение с открытым исходным кодом.
Прежде всего: я не юрист, и это не юридическая консультация. В случае сомнений, пожалуйста, обратитесь к фактическому тексту лицензий, о которых я говорю, и к своему юрисконсульту.
Все программное обеспечение с открытым исходным кодом, согласно Инициативе открытого исходного кода, распространяется по лицензии, которая дает его пользователям и разработчикам (лицензиатам) некоторые права. С полным списком можно ознакомиться в Open Source Definition, но вот основное резюме:
- Бесплатное распространение программного обеспечения: программное обеспечение может быть продано или передано как продукт или включено в пакет программного обеспечения. Это можно сделать без уплаты роялти.
- Исходный код лицензионного ПО либо включен в дистрибутив, либо, по крайней мере, существуют широко разрекламированные способы получения исходного кода. Этот исходный код можно использовать для разработки модифицированных версий программного обеспечения.
- Разрешено создание производных работ, и лицензия позволяет их распространять на тех же условиях и с той же лицензией, что и оригинальное программное обеспечение. В зависимости от лицензии исходного программного обеспечения в некоторых случаях эти производные работы должны отличаться от исходного программного обеспечения путем изменения их имени или номера версии или могут распространяться только в виде исправлений исходного кода.
- Программное обеспечение может использоваться любым человеком или группой людей и в любых сферах деятельности без каких-либо ограничений.
Но вы должны иметь в виду, что лицензии на программное обеспечение говорят только об использовании или распространении разрешений, предоставленных правообладателями. Лицензии с открытым исходным кодом могут позволить вам свободно распространять программное обеспечение или производные работы, но это разрешение также может быть ограничено в некоторых странах, где экспорт криптографического программного обеспечения запрещен. Аналогичным образом лицензии с открытым исходным кодом позволяют вам использовать программное обеспечение для любых целей, но это не означает, что они позволяют вам взломать банк, используя лицензионное программное обеспечение с открытым исходным кодом. Патенты на программное обеспечение являются еще одним примером этого: некоторые лицензии с открытым исходным кодом предоставляют разрешения на свободное использование патентов, но не все из них.
Итак, можем ли мы использовать программное обеспечение с открытым исходным кодом при разработке продукта или проекта? В основном это зависит от лицензии используемого программного обеспечения и предполагаемой лицензии на конечный продукт. Различные лицензии также имеют значение, когда вы хотите опубликовать свой собственный код с открытым исходным кодом и решаете, какую лицензию использовать.
Авторское лево
Одна довольно интересная концепция лицензий с открытым исходным кодом — это то, что обычно называют копилефтом, противоположным авторскому праву. В тех случаях, когда авторское право используется для защиты интеллектуальной собственности (включая программное обеспечение) от копирования или распространения, авторское лево используется для обеспечения того, чтобы интеллектуальная собственность и программное обеспечение с открытым исходным кодом могли быть скопированы или распространены как открытый исходный код.
По своей силе копилефт бывает двух видов:
- Сильное авторское лево: когда произведения, полученные из других произведений, лицензированных с сильным авторским левом, или связанные с этими произведениями, должны по-прежнему иметь сильные лицензии с авторским левом или даже точно такую же лицензию. То есть эти работы с открытым исходным кодом не могут быть закрыты в будущем.
- Слабое авторское лево: когда произведения, использующие лицензии со слабым авторским левом, или связанные с ними, могут быть лицензированы по другим лицензиям, даже по лицензиям с закрытым исходным кодом. В этом случае копилефт влияет только на оригинальную работу со слабым авторским левом.
Существуют также лицензии с открытым исходным кодом без авторского лева: их просто не волнует будущая открытость производного программного обеспечения.
Вседозволенность
По разрешительности лицензии также можно разделить на:
- Строгие лицензии: когда вы не можете смешивать надежное лицензионное программное обеспечение с программным обеспечением с закрытым исходным кодом или даже с более разрешительным лицензионным программным обеспечением.
- Разрешающие лицензии: когда продукты обычно можно смешивать с программным обеспечением с закрытым исходным кодом или с программным обеспечением с полностью открытой лицензией.
Обычно лицензии с сильным авторским левом также строгие, а слабые лицензии с авторским левом являются более либеральными, но так быть не должно.
Различия в лицензиях с открытым исходным кодом
Существует множество лицензий с открытым исходным кодом. Инициатива Open Source уже одобрила более 80 из них. Некоторые из них являются избыточными и могут рассматриваться как эквивалентные другим. Другие относятся к интересам издателя программного обеспечения (например, лицензия НАСА) или для конкретной среды или цели (например, лицензия образовательного сообщества или лицензия открытого шрифта).
Это распространение лицензий основано на определенных условиях лицензии, которые в дополнение к основным свойствам с открытым исходным кодом разрешают или запрещают другие виды использования. Примеры этих дополнительных условий могут включать:
- Тип копилефта: слабый, сильный или несуществующий.
- Тип вседозволенности: разрешительный или строгий.
- Обязательство добавления уведомления об авторских правах в исходный код или в пользовательский интерфейс.
- Автоматическая выдача патентов лицензиатам.
- Рассматривая в качестве лицензиатов не только стороны, которым распространяется программное обеспечение, но и пользователи программного обеспечения (чтобы люди, использующие службу в облаке, использующую такое программное обеспечение с открытым исходным кодом, имели возможность загрузить исходный код программное обеспечение)
Проблема смешивания кода с разными лицензиями
Согласно тому, что мы уже говорили ранее, некоторые лицензии являются разрешительными, что позволяет пользователям комбинировать код с исходным кодом с другой лицензией (возможно, с дополнительными условиями). Этот случай позволит смешивать такое лицензионное программное обеспечение с открытым исходным кодом с программным обеспечением с закрытым исходным кодом. Примером такой лицензии является лицензия MIT.
Другие имеют более строгие ограничения, поэтому исходный код можно комбинировать только с кодом, лицензированным аналогичным образом, а конечный результат должен быть лицензирован с той же исходной лицензией. Примером такой лицензии является Стандартная общественная лицензия (GPL).
Возможно, вы хотите объединить код, лицензированный двумя разными ограничительными лицензиями с открытым исходным кодом. Используя свободу с открытым исходным кодом использовать программное обеспечение по своему усмотрению, вы можете сделать это. Но финальную программу нельзя распространять, так как она должна распространяться под двумя несовместимыми друг с другом лицензиями.
Одним из примеров такой ситуации была ZFS. ZFS — очень передовая и инновационная файловая система, которая была включена в OpenSolaris в 2005 году. Это программное обеспечение с открытым исходным кодом, лицензированное в соответствии с условиями Common Development and Distribution License (CDDL). Хотя это открытый исходный код, его нельзя интегрировать в ядро Linux, поскольку исходный код Linux распространяется в соответствии с условиями General Public License, еще одной ограничительной лицензии с открытым исходным кодом. Бинарные файлы ядра Linux, скомпилированные с поддержкой ZFS, не могут распространяться из-за конфликта лицензий.
Такого рода конфликты могут быть разрешены только в том случае, если все владельцы одной из программ с открытым исходным кодом согласятся изменить лицензию или добавить условия исключения в лицензию на программное обеспечение. Например: многие программы под лицензией GPL связаны с библиотекой OpenSSL. Распространение библиотеки OpenSSL лицензируется, требуя появления фразы в рекламных материалах и любых перераспределениях. Эти дополнительные условия несовместимы с GPL, и поэтому разработчики продуктов GPL, использующих OpenSSL, включили в свою лицензию исключение, специально разрешающее связывание с OpenSSL.
Отличительные особенности лицензий с открытым исходным кодом
Теперь я попытаюсь проанализировать самые популярные лицензии с открытым исходным кодом, отметив их отличительные особенности, с небольшим руководством о том, когда их использовать или нет. Согласно базе знаний Black Duck, я отсортировал их от более к менее используемым.
Стандартная общественная лицензия GNU (GPL)
GPL — самая популярная лицензия с открытым исходным кодом. Он был создан FSF как лицензия для проекта GNU, а также лицензия ядра Linux.
Его дифференциальные характеристики:
- Сильное копилефт.
- Очень строгая лицензия.
- Обычно это называется «вирусной» лицензией: если вы связываете свой код с другим фрагментом кода, лицензированным по GPL, и хотите распространять результаты, весь продукт должен быть под лицензией GPL.
- Это также «охватывающая» лицензия: если вы разрабатываете программное обеспечение и хотите лицензировать его по GPL, вы можете связать его или включить другое программное обеспечение с открытым исходным кодом, если это программное обеспечение имеет лицензию, совместимую с GPL. Это не требует никаких обязательств, не предусмотренных GPL.
Обычно используемый текст лицензии включает текст о том, что программное обеспечение распространяется на условиях GPL версии N (или любой более поздней версии).
В настоящее время используются две версии лицензии GPL: v2 и v3. Версия 3 была выпущена в 2007 году для решения некоторых проблем, возникших после выпуска версии 2 в 1991 году.
GPL v3 включает в себя некоторые дополнительные пункты и условия, касающиеся правил совместимости с другими лицензиями с открытым исходным кодом, обязательного лицензирования патентов, определения условий использования программного обеспечения под лицензией GPL в качестве встроенного программного обеспечения в устройствах и учета таких концепций, как управление цифровыми правами.
Лицензия Массачусетского технологического института
Лицензия с открытым исходным кодом, обычно известная как лицензия MIT, также известная как лицензия X11, является очень разрешительной лицензией без авторского лева, которая позволяет каждому в основном использовать код с такой лицензией для чего угодно, пока вы сохраняете сообщение об авторских правах и знаете, что программное обеспечение поставляется без каких-либо гарантий.

Эта лицензия очень популярна и используется несколькими проектами, такими как X Window System, Ruby on Rails, jQuery или Node.js.
Он совместим с GPL, поэтому вы можете смешивать код под лицензией MIT с программным обеспечением GPL.
Лицензия Апача 2.0
Лицензия Apache была создана Apache Software Foundation (ASF) в качестве лицензии для HTTP-сервера Apache.
Как и лицензия MIT, это очень разрешительная лицензия без авторского лева, которая позволяет использовать программное обеспечение для любых целей, распространять его, изменять его и распространять производные от него работы, не заботясь об лицензионных отчислениях. Его основное отличие от лицензии MIT:
- Используя лицензию Apache, авторы программного обеспечения предоставляют патентные лицензии любому пользователю или распространителю кода. Эти патентные лицензии применяются к любому патенту, который, будучи лицензированным любым автором программного обеспечения, будет нарушен частью кода, который они создали.
- Лицензия Apache требовала, чтобы неизмененные части в производных работах сохраняли лицензию.
- В каждом лицензионном файле должны быть сохранены любые оригинальные уведомления об авторских правах, патентах, товарных знаках или авторстве.
- При каждом изменении лицензионного файла должно быть уведомление о том, что в файл были внесены изменения.
- Если программное обеспечение под лицензией Apache включает файл NOTICE, этот файл и его содержимое должны быть сохранены во всех производных работах.
- Если кто-либо намеренно отправляет вклад в разработку программного обеспечения под лицензией Apache его авторам, этот вклад может быть автоматически использован в соответствии с лицензией Apache.
Эта лицензия интересна автоматической патентной лицензией и пунктом о представлении вклада.
Он совместим с GPL, поэтому вы можете смешивать лицензионный код Apache с программным обеспечением GPL.
Лицензия BSD
Есть 3 разные лицензии BSD. Все они являются очень либеральными лицензиями без авторского лева.
Лицензия BSD с двумя пунктами (или упрощенная лицензия BSD) полностью эквивалентна лицензии MIT, о которой говорилось выше.
Лицензия BSD из 3 пунктов (или Новая лицензия BSD) добавляет один пункт, указывающий, что ни имя правообладателя, ни имена его участников не могут использоваться для поддержки или продвижения продуктов, полученных из программного обеспечения, без специального предварительного письменного разрешения. Эта версия совместима с GPL, что позволяет вам смешивать лицензионный код BSD из 3 пунктов с программным обеспечением GPL.
Лицензия BSD из 4 пунктов (или Исходная лицензия BSD) добавляет еще один пункт, указывающий, что все рекламные материалы, в которых упоминаются функции или использование программного обеспечения, должны отображать подтверждение того, что продукт включает программное обеспечение, разработанное правообладателем. Эта лицензия BSD из 4 пунктов несовместима с GPL. Код с этой лицензией не может быть перелицензирован в соответствии с условиями GPL, поскольку четвертый пункт добавляет требование, которого нет в GPL.
Стандартная общественная лицензия ограниченного применения GNU (LGPL)
LGPL была создана FSF как модификация GPL с более слабым авторским левом, что позволяет связывать программное обеспечение под лицензией LGPL с любым другим программным обеспечением. Первоначально LGPL расшифровывалась как «Стандартная общественная лицензия для библиотек», но впоследствии она получила свое нынешнее название «Меньшая стандартная общественная лицензия», что отражает мнение FSF о том, что все программы должны быть бесплатными, и поэтому LGPL не должна быть обычно используется.
Вы можете связать закрытый исходный код с библиотекой или программным обеспечением LGPL и распространять окончательные результаты, если:
- Вы предоставляете исходный код части LGPL со всеми изменениями, которые вы в него внесли.
- Любой пользователь, обладающий достаточными знаниями, может заменить часть программы под LGPL модифицированной версией. Это можно сделать, распространяя часть программы под LGPL в виде динамической библиотеки (DLL в Windows, .so в Linux/Unix) или предоставляя объектный код части программы, не подпадающей под LGPL.
LGPL v3 совместима с GPLv3, поэтому вы можете ввести код LGPLv3 в программное обеспечение GPL.
Художественная лицензия
Художественная лицензия в ее текущей версии 2.0 является разрешительной лицензией с открытым исходным кодом без авторского лева, аналогичной лицензии MIT.
Основное различие между лицензией MIT и лицензией Artistic заключается в том, что последняя требует, чтобы любая модификация, внесенная в код, была четко указана.
Эта лицензия используется почти исключительно в сообществе Perl.
Текущая лицензия Artistic License 2.0 совместима с GPL: вы можете смешивать код под лицензией Artistic с программным обеспечением GPL.
Публичная лицензия Microsoft (MS-PL)
Публичная лицензия Microsoft была создана этой компанией в 2008 году как одна из лицензий с открытым исходным кодом, созданных в рамках инициативы Shared Source.
Это строгая, слабая лицензия с авторским левом: она позволяет создавать и распространять программы с закрытым исходным кодом с кодом MS-PL, но обязывает использовать MS-PL в качестве лицензии производных работ, если они распространяются в исходном коде.
Я лично считаю, что эта лицензия немного порочна и противоречит духу открытого исходного кода, позволяя закрывать код так, что правообладателю все равно, что вы можете делать с программным обеспечением, а вы не можете. поделитесь кодом для смешивания с другим исходным кодом с авторским левом. Таким образом, с другой стороны, правообладатель действительно заботится о том, что вы можете сделать, и он не хочет, чтобы вы использовали код для таких целей, как улучшение Linux.
MS-PL несовместима с GPL.
Публичная лицензия Eclipse (EPL)
Публичная лицензия Eclipse — это лицензия, созданная Eclipse Foundation для их интегрированной среды разработки. Это ограничительная лицензия со слабым авторским левом, во многом похожая на LGPL. Он также включает положения об автоматической выдаче патентных лицензий.
EPL несовместима с GPL.
Публичная лицензия Mozilla (MPL)
Публичная лицензия Mozilla версии 2.0 — это разрешительная лицензия со слабым авторским левом, созданная Mozilla Foundation для своих продуктов.
Мы могли бы считать эту лицензию похожей на LGPL, но с тем главным отличием, что MPL также позволяет статическое связывание фрагментов кода MPL с программным обеспечением с закрытым исходным кодом.
MPL в ее текущей версии 2.0 совместима с GPL. Это неверно для предыдущих версий MPL.
Общая лицензия на разработку и распространение (CDDL)
CDDL — это разрешительная лицензия со слабым авторским левом, созданная Sun (теперь Oracle) на основе MPL версии 1.1. По сути, он имеет те же свойства, что и MPL. Его условия были уточнены, но существенно не изменены.
CDDL — это лицензия с открытым исходным кодом, выбранная Sun (теперь Oracle) для многих своих продуктов, таких как OpenSolaris или NetBeans и других.
Поскольку эта лицензия была основана на MPLv1.1, эта лицензия несовместима с GPL, поэтому вы не можете смешивать исходный код под лицензией CDDL с программным обеспечением под лицензией GPL. Многие говорят, что это было сделано намеренно, поэтому исходный код OpenSolaris нельзя вводить в ядро Linux.
Стандартная общественная лицензия GNU Affero (AGPL)
AGPL — это версия GPL с еще более сильным авторским левом. Он обязывает предоставлять исходный код приложения не только лицам, получающим копию программного обеспечения, но и лицам, использующим это программное обеспечение через компьютерную сеть.
Эта лицензия была создана FSF для предоставления разработчикам средств, позволяющих избежать практического закрытия программного обеспечения с открытым исходным кодом, когда оно выполняется на сетевых серверах или в облаке, поскольку GPL не может заставить поставщиков услуг предоставлять исходный код пользователям. . В этом случае программное обеспечение не распространяется.
AGPLv3 совместима с GPL3. Вы можете поместить код AGPLv3 в код GPLv3, если конечный результат находится под лицензией AGPLv3.
Лицензия ISC
Лицензия ISC — это разрешительная лицензия на свободное программное обеспечение, написанная Консорциумом программного обеспечения Интернета (ISC). Функционально он эквивалентен лицензиям BSD и MIT из двух пунктов после удаления некоторых языков, которые считались ненужными.
Первоначально использовавшаяся для выпусков собственного программного обеспечения ISC, с тех пор она стала предпочтительной лицензией OpenBSD (начиная с июня 2003 г.) среди других проектов.
Он совместим с GPL: вы можете смешивать код под лицензией ISC с программным обеспечением GPL.
Взаимная лицензия Microsoft (MS-RL)
Взаимная лицензия Microsoft была создана этой компанией в 2008 году как одна из лицензий с открытым исходным кодом, созданных их Инициативой общего исходного кода.
Он похож на MS-PL, описанный выше, но имеет немного более сильное авторское лево, напоминающее условия LGPL, CDDL и EPL. Это требует, чтобы, если вы смешиваете свой код с исходным кодом с лицензией MS-RL и хотите распространять окончательные результаты, по крайней мере исходная часть с лицензией MS-RL должна продолжать лицензироваться с этой лицензией.
Это несовместимо с GPL.
Общественное достояние (CC0)
Согласно Википедии, «произведениями, находящимися в общественном достоянии, являются те, права на интеллектуальную собственность которых истекли, были конфискованы или неприменимы». Посвящая произведение общественному достоянию, автор отказывается от всех своих прав на него по закону об авторском праве.
В Public Domain есть несколько программных проектов, например SQLite, библиотека, которая реализует встраиваемый и простой механизм базы данных SQL, который включен в несколько других проектов, таких как проекты Mozilla, Android и т. д.
Есть много способов сделать часть программного обеспечения общественным достоянием. Creative Commons создала CC0 Public Domain Dedication, универсальный способ передачи произведения в общественное достояние. FSF рекомендует использовать этот текст для выделения программного обеспечения в общественное достояние.
Работы, находящиеся в общественном достоянии, совместимы с любыми лицензиями с открытым или закрытым исходным кодом и могут быть смешаны с любым другим программным обеспечением.
Множественное лицензирование
Есть некоторое программное обеспечение с открытым исходным кодом, которое имеет двойную или даже тройную лицензию. Это означает, что человек, получивший это программное обеспечение с несколькими лицензиями, может выбрать, под какой лицензией он или она хочет его распространять. Поскольку каждая лицензия предоставляет разные разрешения и налагает разные обязательства, необходимо сделать выбор для выбора лицензии, которая наилучшим образом соответствует потребностям.
Это обычный случай для некоторых библиотек. Например, NSS — это библиотека, созданная Mozilla, которая реализует поддержку SSL/TLS, помимо других функций, связанных с безопасностью. Он имеет три лицензии: MPL, GPL и LGPL.
Пожалуйста, выберите лицензию
Многие люди публикуют код на платформах как GitHub без какой-либо письменной лицензии. Никто не должен использовать этот код. Мы понятия не имеем, какие разрешения у нас есть для его использования. Если вы используете его, вас могут засудить за это. Это как если бы эти люди дразнили нас, говоря: «Эй, посмотрите, что я сделал! Круто, не так ли? Но ты не можешь его использовать, я только хотел тебе показать!».
Пожалуйста, не будьте одним из них. Если вы загружаете свой код на GitHub или аналогичные общедоступные сайты, разрешите другим использовать его и улучшать. Если вы не хотите много думать, вот мои рекомендации:
- Если вы хотите, чтобы это было просто и разрешительно, позволяя всем делать с вашим кодом все, что они хотят, при условии, что они указывают вам авторство и не возлагают на вас ответственности, используйте лицензию MIT.
- Если вы хотите оставить его разрешительным, позволяя всем делать то, что они хотят с вашим кодом, но разумно перечисляя права в соответствии с законом об авторском праве и предоставляя эти права, наряду с предоставлением явного предоставления патентных прав от участников пользователям, используйте лицензию Apache 2.0. .
Если вы заботитесь о совместном использовании модификаций и не хотите, чтобы ваш код использовался в закрытых разработках (ни в закрытых программных продуктах, ни в закрытых аппаратных устройствах), используйте GPL v3.
- Если вас не волнует возможность использования вашего программного обеспечения в закрытом устройстве, используйте GPL v2. Но, пожалуйста, с предложением «или любая более поздняя версия», чтобы ваш код также можно было использовать в проектах GPLv3.
- Если вас не волнует возможность того, что ваше программное обеспечение будет использоваться в закрытом программном обеспечении, пока ваше программное обеспечение или часть, которая его использует, остается открытым исходным кодом на тех же условиях, используйте LGPL v3.
- Если вы хотите, чтобы каждый, кто использует ваше программное обеспечение по сети, имел право на получение его исходного кода, используйте AGPL v3.
После всего этого вы можете быть измотаны всей этой почти бессмысленной квазиюридической тарабарщиной. Но знаете что? Это необходимо. Потому что без лицензии у вас нет прав на использование или распространение любого кода.