«Проветрите эту лицензию»: абсурдные, но занимательные тексты лицензий на свободные программные решения

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

 

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

 

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

Идеи открытости и взаимопомощи роднят open source сообщество не только с наукой, но и с искусством. Например, сейчас многие art&science проекты принципиально используют открытые библиотеки и датасеты, и тренд на это, думаю, будет только расти. Код некоторых таких проектов тоже распространяется под открытыми лицензиями.

 

Возможность выложить свой проект под любой (даже собственной) лицензией — это в том числе возможность рассматривать текст лицензии не только как юридическое соглашение, но и как художественное высказывание. Специфическая лицензия может идейно дополнить арт-проект: например, Nuclear Waste Software License в экологическом проекте.

 

Кроме того, лицензия – это способ договориться, но не всегда на языке законов. С одной стороны, проект с «абсурдной» лицензией вряд ли будут использовать везде, где важна юридическая сила лицензии (хотя встречаются исключения). С другой, использование таких лицензий может означать демонстративный отказ от системы взаимоотношений, где всё держится не на чистом доверии. Такие лицензии напоминают мне, что человечным может быть и пространство кода.

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

 

Однако, не стоит полагать, что все «смешные» лицензии безопасны. Их условия могут мешать использованию в определенной сфере деятельности или же делать код несовместимым с другими лицензиями. Нарушение этих условий все еще будет нарушением права на ПО, несмотря на всю их кажущуюся несерьезность. С другой стороны, громких и больших споров по нарушению условий странных лицензий нет. Или же они есть в таком количестве и масштабе, что это практически незаметно. Такая ситуация может быть объяснима следующим:

 

ПО по лицензиям со странными ограничительными условиями не включают в большие проекты, поскольку этот небольшой элемент может саботировать всю работу. Даже если нарушения и есть, эти лицензии довольно нишевые и круг заинтересованных лиц в защите прав на лицензируемое ПО относительно небольшой и не обладает достаточными ресурсами для мониторинга и защиты по ним, чтобы инициировать такие кейсы самостоятельно. Странные лицензии, если они разрешительные, наоборот, включают довольно часто, с ними просто не возникает проблем. Сам неоднократно был свидетелем Beer-ware лицензии в списке компонентов. Некоторые программы с «пивным» компонентом даже включены в реестр отечественного ПО.

 

Относительно Cookie Ware License: Разработчика угощать при встрече не придется, но можно, если вы этого захотите. Фраза and you think this stuff is worth it в лицензиях позволяет говорить о том, что покупка выпечки остается на усмотрение лицензиата. Это важный момент для совместимости с GPL. Ведь если бы покупка выпечки при встрече была бы обязательной, такое ограничение было бы дополнительным ограничением лицензиата при использовании кода по Cookie Ware License. А вот разработчик должен будет принять лицензионное угощение, по крайней мере, по российскому праву. Ведь в лицензии он дал согласие на одаривание его печеньками или иными гастрономическими дарами.

 

Относительно GLWTPL: На самом деле условия «я ни в чем не виноват» встречается в классических оговорках «AS IT IS» и стандартных отказах от гарантий и ответственности. Так что в каком-то смысле все лицензии снимают с себя эту ответственность. Самое примечательное отличие данной лицензии — обязательство сохранять анонимность автора. Обычно в других лицензиях требование обратное — указывать изначальных авторов.

Действительно, лицензии бывают разные. По состоянию на сегодня, команда CodeScoring насчитала более 2000 открытых лицензий. Не все они одинаково полезны, да и не все они действительно открытые, если быть честным. К примеру, OSI (Open Source Initiative) не признает тексты лицензий содержащие экспортные ограничения, по причине установления территориальных правил распространения. Более сотни лицензий подчиняются экспортному контролю США и сегодня на это нужно обращать особенное внимание.

 

Что касается «веселых» лицензий, важно напомнить про понятие лицензионной совместимости, которая может здесь сработать не на руку и добавить проблем для последующего использования компонента. Лицензии разных типов, бывают несовместимы с точки зрения предъявляемых требований. К примеру, компонент с лицензией Apache 2.0 не может использовать компонент с лицензией LGPL {2,2.1,3} и иные. Поэтому важно следить и за транзитивными компонентами, которые могут привнести что угодно в ваше ПО.

 

Кроме того, важно помнить, что лицензии устанавливаются авторами сторонних пакетов как в момент выпуска самой первой версии, так и могут быть изменены с выпуском новой. По нашей статистике, 2% пакетов меняют лицензию с течением своей жизни — об этом я рассказывал на докладе «Занимательные лицензии» на DUMP в прошлом году. Помощь в контроле большого объема сторонних компонентов в промышленных масштабах осуществляют инструменты класса SCA (композиционный анализ ПО), примером такого является открытое решение Dependency Track или наш продукт.

 

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