Open Source лицензии: полное руководство по выбору и применению

Open Source — двигатель технологического мира, составляющий до 90% современных программных стеков, включая фреймворки, библиотеки, базы данных, операционные системы и множество автономных приложений.

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

Существует два основных типа лицензий, соответствующих формальному определению open source, установленному Open Source Initiative (OSI).

Разрешительная – лицензия почти не ограничивает пользователей в том, как можно изменять и распространять ПО, что делает такую лицензию популярной среди компаний, желающих использовать open source в коммерческих целях.

Копилефт – лицензия предоставляет аналогичные свободы, но с важным условием: любая модифицированная версия ПО должна распространяться под той же копилефт-лицензией. Это может быть непривлекательно для бизнеса, стремящегося защитить свои разработки.

Но дело не только в этом. В рамках каждой из этих категорий существует множество лицензий. Кроме того, существуют лицензии, которые формально не являются open source, но также заслуживают внимания.

Разрешительные лицензии

MIT

Возникшая в Массачусетском технологическом институте в 1980-х годах, лицензия MIT по праву считается одной из самых популярных среди open source-лицензий. Она долгое время занимает верхние строчки в сообществе разработчиков GitHub.

Данная лицензия используется в таких проектах, как React (JavaScript-библиотека для фронтенда) и Ruby (язык программирования общего назначения). Лицензия MIT позволяет разработчикам использовать ПО по своему усмотрению. Как и большинство подобных лицензий, MIT не предоставляет гарантий, освобождая авторов от ответственности за ущерб, вызванный использованием их ПО (например, потеря данных). Единственное требование для разработчиков — включить оригинальное уведомление об авторских правах и текст лицензии MIT в производные работы.

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

С другой стороны, ключевое преимущество лицензии MIT — простота: всего 200 слов. Добавление сложного юридического текста о патентах лишь усложнило бы её использование для проектов, которым патенты не важны, таких как языки программирования или веб-фреймворки.

Тем не менее, для проектов, связанных с запатентованными технологиями, например, Android, такой недостаток может быть критичным.

Apache License 2.0

Фонд Apache Software Foundation опубликовал лицензию Apache 2.0 в 2004 году как обновление предыдущей версии, включив явное предоставление патентных прав для защиты пользователей от судебных разбирательств. Например, если разработчик добавит уникальный алгоритм обработки изображений в проект под лицензией Apache 2.0, то любые патенты, связанные с данным алгоритмом, автоматически лицензируются для всех пользователей ПО.

Рассмотрим данную лицензию на примере Android. Основа проекта – Android Open Source Project (AOSP) – распространяется под лицензией Apache 2.0. Это было частью стратегии Google в 2008 году для конкуренции с Apple и привлечения производителей телефонов к Android, а не к другим проприетарным платформам (например, Symbian). И это сработало: Samsung, HTC, LG и другие перешли на Android.

Однако объем текста лицензии Apache 2.0 примерно в 5 раз больше, чем у MIT. Это компромисс, который иллюстрирует ключевые различия между двумя популярными разрешительными open source-лицензиями.

Другие разрешительные лицензии

2-Clause BSD License похожа на MIT, но отличается в формулировке. Например, она требует включения копии лицензии как в исходный код, так и в скомпилированные файлы. Лицензия 3-Clause BSD License добавляет пункт о запрете использования имен авторов и участников проекта в рекламных целях.

Есть также MIT No Attribution License (MIT-0), которая упрощает лицензию MIT, убирая требование об атрибуции, что делает MIT-0 практически эквивалентной передаче ПО в общественное достояние, но с сохранением авторских прав.

Копилефт

GNU General Public License (GPL) v2.0 и 3.0

Фонд Free Software Foundation (FSF) опубликовал GPL в 1989 году как одну из первых копилефт-лицензий общего назначения.

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

GPL 3.0, запущенная в 2007 году, занимает третье место по популярности среди open source-лицензий, согласно данным GitHub. В неё добавлены положения о патентах, улучшена совместимость с другими лицензиями и запрещена тивоизация (Tivoization) — использование механизмов DRM для ограничения установки модифицированных версий ПО.

Среди известных проектов, использующих GPL, можно отметить WordPress, который распространяется под лицензией GPL 2.0 «или более поздней», что оставляет разработчику право выбора лицензии для любой модификации.

Linux, в свою очередь, является одним из самых успешных open source-проектов всех времён, используемым на серверах, в облачной инфраструктуре, встроенных системах и даже в Android. Однако основное ядро Linux доступно только под лицензией GPL 2.0, поскольку создатель Linux Линус Торвальдс не согласен с рядом положений, добавленных в версию 3.0, включая пункт о тивоизации.

GNU Affero General Public License (AGPL) 3.0

Лицензия Affero General Public License (AGPL) похожа на GPL 3.0 и является «сильной» копилефт-лицензией, направленной на продвижение свободы программного обеспечения и сохранение модификаций в открытом доступе. Однако её ключевое отличие заключается в том, что она ориентирована на веб-сервисы и приложения, где программное обеспечение работает на серверах, а не распространяется в виде исполняемых файлов.

Согласно GPL 3.0, разработчики не обязаны публиковать исходный код модифицированного ПО, если оно используется в качестве SaaS (Software-as-a-Service). AGPL устраняет этот пробел, требуя предоставления исходного кода даже в случае работы модифицированного ПО только на сервере. Опубликованная в 2007 году FSF, AGPL 3.0 стала популярной благодаря росту облачных вычислений и SaaS, и сегодня это пятая по популярности open source-лицензия.

GNU Lesser General Public License (LGPL)

LGPL, также разработанная FSF, является «слабой» копилефт-лицензией. Она менее строгая по сравнению с GPL, что делает её более удобной для бизнеса. LGPL обычно используется для библиотек, где авторы хотят поощрять вклад сообщества, но при этом позволяют проприетарному ПО подключаться к библиотекам без необходимости раскрывать весь исходный код.

Если кто-то изменяет саму открытую библиотеку, изменения должны быть опубликованы под лицензией LGPL, но это не касается всей программы, которая использует библиотеку.

Mozilla Public License 2.0

Опубликованная Mozilla Foundation в 2012 году, Mozilla Public License (MPL) 2.0 занимает десятое место по популярности среди open source-лицензий, согласно метрике GitHub. MPL — это слабый копилефт, предназначенный для защиты проприетарного кода, одновременно позволяя разработчикам пользоваться преимуществами открытого ПО.

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

Общественное достояние и Creative Commons

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

Просто опубликовать программное обеспечение без лицензии недостаточно, так как по умолчанию на большинство творческих работ, включая программное обеспечение, распространяется действие закона об авторских правах. Здесь помогают инструменты «передачи в общественное достояние» (public domain dedication).

Для программного обеспечения существует Unlicense — девятая по популярности лицензия на GitHub (хотя её статус как лицензии вызывает споры). Несмотря на то, что OSI одобрила Unlicense в 2020 году, организация отметила, что документ плохо составлен и может быть юридически недействительным в некоторых юрисдикциях, где невозможно полностью отказаться от авторских прав.

Creative Commons предлагает схожий инструмент — CC0 1.0, который фокусируется на творческих работах в целом. CC0 использует более ясный юридический язык, соответствующий международному праву, но не предоставляет патентных прав. Стоит отметить, что в 2012 году Creative Commons подала заявку на одобрение CC0 1.0 в качестве open source-лицензии, но отозвала ее после того, как OSI выразила обеспокоенность тем, что она явно исключает выдачу патентов.

Существуют и другие инструменты, такие как Zero-Clause BSD, который обладает ещё более простым текстом. Однако до сих пор нет единого мнения о том, какой механизм лучше всего подходит для полного отказа от прав на программное обеспечение.

«Псевдооткрытые» лицензии

В спектре лицензирования программного обеспечения существует множество других подходов.

Некоторые компании используют двойное лицензирование, предлагая пользователям выбор между признанной open source-лицензией и коммерческой лицензией в зависимости от их намерений. Другие компании используют модель «open core», где основное ПО доступно по open source-лицензии, но ключевые функции находятся за платным доступом.

Иногда к разрешительным open source-лицензиям добавляют оговорку Commons Clause, накладывающую коммерческие ограничения.

Есть и такие лицензии, которые выглядят как open source, но не соответствуют её определению.

Например, в 2018 году MongoDB перешла с копилефта AGPL на собственную Server Side Public License (SSPL). Хотя SSPL остаётся «открытой» в определённой степени, она является лишь «доступной для просмотра», так как содержит существенные коммерческие ограничения. Это противоречит требованиям OSI.

Разработчики MariaDB выбрали схожий путь, внедрив бизнес-лицензию Business Source License (BUSL), которая накладывает коммерческие ограничения на определённый срок, после чего переходит в статус полностью открытой лицензии.

Существуют и более новые попытки внедрения «справедливого лицензирования» (fair source), например Functional Source License, позиционируемая как более простой аналог BUSL. Иногда встречаются и «этические» лицензии, такие как Hippocratic License, которая запрещает использование ПО в нарушении международно-признанных прав человека. Наконец, формат JSON, являющийся крайне разрешительным, содержит забавное условие: «Программное обеспечение должно использоваться только во благо, а не во зло».

Заключение

Лицензии открытого исходного кода играют ключевую роль в развитии технологий, обеспечивая гибкость, свободу и прозрачность для разработчиков и компаний. Они позволяют создавать инновационные проекты, объединяя усилия сообщества и бизнеса. Однако выбор подходящей лицензии — это всегда баланс между открытостью и защитой интересов.

Копилефт-лицензии идеально подходят для проектов, где важна открытость и совместная разработка, а разрешительные лицензии предлагают больше свободы для коммерческого использования. Эволюция лицензирования также привела к появлению новых подходов, таких как «псевдооткрытые» лицензии и модели, которые учитывают современные реалии, включая облачные технологии и защиту прав разработчиков.

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