В кризис open source вендоры коммерциализируют свои разработки активнее и все чаще переходят на формат распространения кода «source available». Резкие изменения в лицензиях — головная боль для руководителей и юристов, вынужденных разбираться в хитросплетениях новых условий. В качестве своеобразного ответа на подобные сложности появляются абсурдные тексты лицензий на открытые разработки.

На Хабре уже поднимали эту тему, но здесь — буквально за пару недель до первого апреля — я решил собрать и обсудить примечательные абсурдные лицензии, которые ранее еще не появлялись на площадке. Каждый из примеров напоминает о том, что любая лицензия как минимум должна быть понятной не только юристам, как максимум — вполне может быть нескучной. Всем неунылого и понятного опенсорса всем!

Код за выпечку

Лицензия The Cookie Ware License содержит одно простое условие: программное обеспечение можно использовать для любых целей, однако придется угостить разработчика выпечкой при личной встрече, если такая когда-нибудь произойдет. Кстати, условие, как и саму лицензию, нужно сохранять в производном продукте.

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

Ненаблюдаемые разработки

The Schrödinger License, вдохновленная известным мысленным экспериментом, содержит четыре основных условия: лицензированные материалы нельзя наблюдать, материалы нельзя одновременно наблюдать и не наблюдать, материалы должны одновременно наблюдаться и не наблюдаться, наблюдение требует придерживаться лицензии.

Также есть два исключения:

• Лицензия не применяется, если наблюдатель является котом Шредингера, за которым наблюдают в ходе эксперимента Шрёдингера.

• Лицензия не применяется сама к себе, когда она — предмет обсуждения.

На свой страх и риск

Good Luck with That Public License разрешает копировать, распространять, модифицировать, продавать, публиковать, сублицензировать код — то есть делать с ним практически все что угодно, но на свой страх и риск. Автор снимает с себя всю ответственность за качество программного обеспечения и последствия его применения.

Как можно догадаться, условия подойдут тем, кто не уверен в качестве своего решения, и, кажется, это — идеальный вариант для студенческих проектов. GLWTPL напоминает условия WTFPL — на Hacker News оценили обе лицензии, но предостерегли от их использования (на практике будет сложно придать им юридический вес).

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

Баги — это фичи

The Bugs License — это чуть более (но не слишком) серьезная лицензия, по сравнению с предыдущими. Она предъявляет к проекту и его форкам несколько требований:

• Баги — это функционал, который необходимо документировать.

• Модифицированные версии не должны содержать известных багов.

• Свежие баги также следует исправить.

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

Только для учебы

По мнению автора, многие начинающие разработчики грешат тем, что просто копируют чужой код и бездумно вставляют его в свои проекты. Положения лицензии The Learning Only License (LOL) должны помочь разобраться с этими сложностями. Так, одно из них предписывает брать ответственность за ошибки в своем коде и стараться их исправить. Вместе с этим нужно спокойно относиться к баг-репортам от других пользователей и учиться на них. Интересно и последнее условие: «Если вы получили доход от проекта, который содержит сторонний код, стоит поблагодарить его авторов».

The Learning Only License можно комбинировать с другими лицензиями. Она лишь вводит образовательный компонент и объясняет, почему решение передали в открытый доступ.

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

Будь круче этого

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

• Не приписывать себе чужие достижения, но отдавать должное авторам.

• Поделиться своими модификациями, чтобы все могли получить пользу.

• Помочь нуждающимся — например, стать волонтером.

• Сделать что-нибудь хорошее для комьюнити и т.д.

Против прибыли

Текст The Anti-Capitalist Software License (ACSL) начинается со следующих слов: «Это — антикапиталистическое программное обеспечение, выпущенное для свободного использования частными лицами и организациями, которые не следуют капиталистическим принципам». Авторы считают, что ACSL — это не только юридический документ, но и своеобразный манифест. Лицензия смещает фокус с доступности кода на устройство организации, которая намерена его использовать. ACSL предназначена для частных лиц, коллективов, кооперативов и некоммерческих компаний. В то же время ACSL ограничивает использование для корпораций и правоохранительных органов.

В целом ИТ-сообщество скептически отнеслось к идее ACSL. Из недостатков резиденты Hacker News отметили слишком абстрактные формулировки, которые затрудняют фактическое применение лицензии. И существуют более практичные лицензии — например, Peer Production License (PPL) или CoopCycle. Первая запрещает использовать лицензированное ПО частным компаниям, а CoopCycle всем организациям, цель которых — получение прибыли. Есть мнение, что эти лицензии имеют большую юридическую силу.

Без систем ИИ, пожалуйста

I Hate AI Licenses (IHAIL) запрещает модифицировать и адаптировать исходный код с помощью систем ИИ. Также его нельзя применять для обучения ML-моделей. Есть исключение — повышение доступности для пользователей с ограниченными возможностями. Однако парадокс заключается в том, что сам текст лицензии был сгенерирован, поэтому автор позиционирует его скорее как арт-объект, а не проект юридического документа. Как полагают некоторые участники Hacker News, суть IHAIL — продемонстрировать, что возможности систем ИИ могут быть использованы против него самого. Другие считают, что текст лицензии выглядит как форма протеста. Но тогда встает вопрос, а можно ли протестовать против широкого распространения ИИ-систем с помощью других ИИ-систем? Вероятно, все-таки это — не лучший вариант.

Что на практике — примеры использования и мнения

Подобные тексты лицензий действительно используют, но не в промышленных масштабах, что объяснимо. Например, ACSL выбрали для себя разработчики PEmbroider — это библиотека для управления автоматическими вышивальными машинами, плюс — разработчики языка программирования Carth. Оба решения используют двойное лицензирование, совмещая ACSL с традиционными open source лицензиями.

Из других примеров — The Learning Only License, которую задействовал автор чат-бота Taylor. (Правда, похоже, что это пет-проект, что в целом соответствует духу лицензии.) Bola и The Cookie Ware License встречаются, кстати, в достаточно старых проектах.

Также попросил прокомментировать тему в целом и отдельные примеры лицензий представителей российского ИТ. (Получилось не менее разнообразно и интересно по сравнению с предыдущей подборкой мнений об OSS в стране.) Далее — комментарии:

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

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

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

Владислав Шершульский

Директор по технологическому развитию АО «ГС-Инвест»

—

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

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

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

Андрей Гетманов

ML Researcher в ИТМО, активный член сообщества ITMO.OpenSource

—

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

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

ПО по лицензиям со странными ограничительными условиями не включают в большие проекты, поскольку этот небольшой элемент может саботировать всю работу. Даже если нарушения и есть, эти лицензии довольно нишевые и круг заинтересованных лиц в защите прав на лицензируемое ПО относительно небольшой и не обладает достаточными ресурсами для мониторинга и защиты по ним, чтобы инициировать такие кейсы самостоятельно. Странные лицензии, если они разрешительные, наоборот, включают довольно часто, с ними просто не возникает проблем. Сам неоднократно был свидетелем 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 или наш продукт.

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

Алексей Смирнов

основатель CodeScoring