Сочетание проприетарного и открытого лицензирования становится все более популярным и представляет угрозу для модели Open Source, сообщает портал The New Stack.

Заметным сдвигом в индустрии стало появление стратегии отложенной публикации открытого исходного кода (delayed open source publication, DOSP). Этот подход предполагает первоначальный выпуск ПО под проприетарной лицензией с последующим плановым переходом на открытую лицензию. Но зачастую программы сначала выпускаются как ПО с открытым исходным кодом, а затем переиздаются под бизнес-лицензией с обещанием в конечном итоге снова появиться как Open Source.

Организация Open Source Initiative (OSI) выпустила исследование, посвященное истории, моделям и развивающимся тенденциям DOSP. Отчет, подготовленный Open Source-экспертами Сетом Шоеном, Джеймсом Василе и Карлом Фогелем, показал, что, лицензия Business Source License (BSL), которую знает большинство из нас, является DOSP-лицензией, и в DOSP нет ничего нового.

Одним из самых ранних примеров DOSP был выпуск Aladdin GhostScript под «Aladdin Free Public License» в районе 1998 г., с последующим переходом на модель одновременного выпуска под проприетарной лицензией и GPL.

Другой пример — библиотека Qt от KDE, в которой DOSP нашла применение в качестве защиты от возможного прекращения разработки. История лицензирования Qt, мягко говоря, сложна, и сегодня она доступна как под коммерческими, так и под открытыми лицензиями GPL 2.0, GPL 3.0 и LGPL 3.0.

Как используется отложенная публикация открытого кода

Исследователи обнаружили, что существует три вида DOSP:

  • Безусловное запланированное перелицензирование. Этот простой подход предполагает заранее определенную временную задержку перед переходом на открытое лицензирование.
  • Событийное перелицензирование. В этом случае публикация открытого исходного кода привязана к определенным событиям, таким как выпуск новой проприетарной версии, что побуждает к открытию ее предшественника. Если раньше такой способ был распространен, то сейчас он используется редко.
  • Условное перелицензирование. Этот тип зависит от выполнения определенных условий, таких как получение финансирования или поиск подходящей некоммерческой организации, прежде чем раскрыть код. Нет нужды говорить, что это обещание может быть выполнено, а может и не быть.

У DOSP также есть такая разновидность, как «видимый исходный код» («visible source») или «доступный исходный код» («source available»). В этих моделях исходный код обычно доступен, но без свобод, гарантированных определением открытого исходного кода (OSD). Самым последним и известным примером является большая языковая ИИ-модель Llama 2 Community License, чей код доступен, но его коммерческое использование ограничено.

Исследователи OSI обнаружили, что на ранних этапах своего существования DOSP «как правило, была направлена на монополизацию прямых коммерческих доходов: лицензия предоставляла большинство разрешений, необходимых для открытого исходного кода, но, что очень важно, не давала разрешения на коммерческое использование». Это ограничение распространялось на всех последующих лицензиатов, включая пользователей, а не только разработчиков.

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

Например, BSL 1.1, которая была написана для MariaDB, не позволяет использовать лицензионный код в производстве, если лицензиар не использует механизм дополнительных разрешений на использование (Additional Use Grant, AUG). В самой лицензии AUG не прописаны.

AUG варьируются от компании к компании. MariaDB, например, определяет «коммерческое использование», если ваше приложение использует лицензионную работу более чем в трех экземплярах сервера. Другими словами, вы не можете использовать MariaDB без коммерческой лицензии, если собираетесь использовать ее в качестве основы для ПО как сервиса (SaaS) или в производстве. BSL-реализация AUG от HashiCorp допускает использование в производстве... за исключением продуктов, конкурирующих с программами и сервисами Hashicorp.

На практике это означает, что не все BSL созданы одинаковыми. Благодаря AUG каждый экземпляр BSL фактически представляет собой существенно отличающуюся лицензию.

Открытый доступ к старым версиям кода: сложный процесс

В любом случае, при использовании BSL старые версии кода рано или поздно будут выпущены под открытой лицензией. Ключевое здесь — «рано или поздно».

BSL требует, чтобы лицензиар указал «дату изменения» («Change Date») и «лицензию изменения» («Change License»). В будущую дату изменения лицензия покрываемого артефакта будет изменена на лицензию изменения, которая является открытой.

Дата изменения для MariaDB наступает через четыре года после выпуска конкретной версии, а лицензия изменения — GPLv2. Однако, как отмечают исследователи OSI, BSL, по идее, предназначена для применения к конкретным выпускам ПО, так что дата изменения относится к конкретной версии кодовой базы. Это означает, что для проекта с постоянной практикой DOSP, BSL должна периодически применяться с обновленными деталями.

«Большинство проектов, которые мы видели, еще не продемонстрировали, как они будут управлять этим процессом на постоянной основе. У большинства из них нет четко просматриваемого и систематического способа применения обновлений BSL в текущей разработке, — пишут авторы отчета. — Для некоторых проектов с первого взгляда неясно, к какой версии или версиям кодовой базы должен применяться грант BSL. Концепция даты изменения может быть осложнена тем, что не все современные программные проекты имеют надежный график дискретных событий „релиза“».

Запутанно, не правда ли?

Рост Business Source Licenses

Переход HashiCorp с Mozilla Public License 2.0 на BSL 1.1 для Terraform является примером двух растущих тенденций. Первая — это рост популярности BSL. Сегодня BSL используют более десятка проектов, включая CouchBase, DragonflyDB и ArangoDB.

Кроме того, последние лицензии DOSP и их пользователи больше сосредоточены на предотвращении конкуренции, а не на монополизации коммерческих доходов. В частности, пользователи BSL все больше сосредотачиваются на предотвращении прямой конкуренции со стратегическими интересами лицензиара. Этот сдвиг заметен в AUG и особых условиях, добавляемых в эти лицензии.

Помимо применения DOSP, за последние несколько лет несколько проектов облачного ПО, таких как MongoDB и Redis, также отказались от Open Source-лицензий и приняли лицензии с оговорками о неконкуренции. Эти лицензии, например Server-Side Public License (SSPL), обычно позволяют вам видеть код, но поставщики облачных услуг не могут использовать его в SaaS. Это не совместимые с DOSP лицензии.

Исполнительный директор OSI Стефано Маффули отметил, что среди важных выводов исследования не последнее место занимают «сложности и компромиссы, существующие с первых дней движения Open Source», а также «поднятие новых вопросов, требующих более глубокого исследования».

Однако известный обозреватель Open Source Стивен Воан-Николс рассматривает DOSP как «отвратительный компромисс между открытым и проприетарным лицензированием. DOSP слишком часто используется для того, чтобы забрать работу Open Source-программистов, а затем закрыть дверь за их кодом, как только проект наберет достаточно оборотов, чтобы его владельцы смогли его монетизировать».