«Проветрите эту лицензию»: абсурдные, но занимательные тексты лицензий на свободные программные решения
В качестве своеобразного ответа на расширение зоопарка лицензий на открытое программное обеспечение появляются абсурдные, но занимательные лицензии. Разбираем неунылый опенсорс!
В кризис open source вендоры коммерциализируют свои разработки активнее и все чаще переходят на формат распространения кода «source available». Резкие изменения в лицензиях — головная боль для руководителей и юристов, вынужденных разбираться в хитросплетениях новых условий. В качестве своеобразного ответа на подобные сложности появляются абсурдные тексты лицензий на открытые разработки. Буквально за пару недель до первого апреля решил собрать и обсудить примечательные примеры — каждый напоминает о том, что лицензии как минимум должны быть понятными не только юристам, а как максимум — вполне могут быть нескучными.
The Cookie Ware License
Лицензия содержит одно простое условие: программное обеспечение можно использовать для любых целей, однако придется угостить разработчика выпечкой при личной встрече, если такая когда-нибудь произойдет. Кстати, условие, как и саму лицензию, нужно сохранять в производном продукте.
В целом это — вариант популярной лицензии Beerware за авторством датского инженера Пола-Хеннинга Кампа, она считается совместимой с GPL и обладает огромным количеством аналогов. Их наполнение ограничено только фантазией и гастрономическими предпочтениями разработчиков. Встречаются версии с вегетарианской едой, суши, чаем и напитками покрепче.
The Schrödinger License
Лицензия, вдохновленная известным мысленным экспериментом, содержит четыре основных условия: лицензированные материалы нельзя наблюдать, материалы нельзя одновременно наблюдать и не наблюдать, материалы должны одновременно наблюдаться и не наблюдаться, наблюдение требует придерживаться лицензии Шрёдингера.
Также есть два исключения:
- Лицензия не применяется, если наблюдатель является котом Шредингера, за которым наблюдают в ходе эксперимента Шрёдингера.
- Лицензия не применяется сама к себе, когда она — предмет обсуждения.
Good Luck with That Public License
Лицензия разрешает копировать, распространять, модифицировать, продавать, сублицензировать код — то есть делать с ним практически все что угодно, но на свой страх и риск. Автор снимает с себя всю ответственность за качество программного обеспечения и последствия его применения.
Кстати, есть и чуть более «вежливая версия» GLWTPL, которая просит не задавать автору вопросы по поводу качества кода и возникающих ошибок.
The Bugs License
Это чуть более (но не слишком) серьезная лицензия, по сравнению с предыдущими. Она предъявляет к проекту и его форкам ряд требований:
- Баги — это фичи, которые нужно документировать.
- В модифицированных версиях не должно быть известных багов.
- Свежие баги также следует исправить.
В то же время авторы программного обеспечения оставляют за собой право использовать сторонние фиксы без упоминания и поощрения их авторов.
The Learning Only License (LOL)
По мнению автора, многие начинающие разработчики грешат тем, что просто копируют чужой код и бездумно вставляют его в свои проекты. Положения лицензии LOL должны помочь освоить эффективные практики работы с кодом (в том числе чужим). Так, одно из них предписывает брать ответственность за ошибки в своем коде и стараться их исправить. Вместе с этим нужно спокойно относиться к баг-репортам от других пользователей и учиться на них. Интересно и последнее условие: «Если вы получили доход от проекта, который содержит сторонний код, стоит поблагодарить его авторов».
The Learning Only License можно комбинировать с другими. Она лишь вводит образовательный компонент и объясняет, почему открыли решение .
Government Public License
Согласно драфту GPL — не путать с GPL (General Public License) — пользователю необходимо заполнить форму на четырех страницах и отослать ее автору, а тот обязуется рассмотреть и ответить на запрос в течение 4–9 рабочих дней. Подойдет любителям все усложнять!
Linguistic Public License
По этой лицензии каждая последующая версия программного обеспечения должна быть написана на языке, отличном от использованного в предыдущих. Все комментарии к коду, текст лицензии и документация также должны быть переведены на другой язык. Кажется, отличный вариант для тех, кому все еще скучно в зоопарке OSS-лицензий!
wg-easy-license
Разрешает использовать программное обеспечение и модифицировать его при условии, что все изменения будут в открытом доступе с сохраненными ссылками на исходный проект и страницы сбора пожертвований. Однако она запрещает коммерческое использование без разрешения автора.
Nice License
Запрещает пользоваться решением тем, кто а) не пишет документацию к проектам; б) пишет ее некачественно в попытке обойти п. а).
BOLA-License
Название является аббревиатурой от Buena Onda License Agreement. С испанского buena onda переводится как «классный» или «крутой». Для автора важна не столько юридическая сторона вопроса, сколько возможность делиться кодом. Поэтому условия BOLA предполагают, что материалы находятся в публичном доступе, а разработчики не несут ответственности за их дальнейшее применение. Однако, чтобы по-настоящему стать buena onda, лицензия предлагает придерживаться следующих принципов:
- Не приписывать себе чужие достижения, но отдавать должное авторам.
- Поделиться своими модификациями, чтобы все могли получить пользу.
- Помочь нуждающимся — например, стать волонтером.
- Сделать что-нибудь хорошее для комьюнити и т.д.
The Anti-Capitalist Software License (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 в экологическом проекте.
Кроме того, лицензия – это способ договориться, но не всегда на языке законов. С одной стороны, проект с «абсурдной» лицензией вряд ли будут использовать везде, где важна юридическая сила лицензии (хотя встречаются исключения). С другой, использование таких лицензий может означать демонстративный отказ от системы взаимоотношений, где всё держится не на чистом доверии. Такие лицензии напоминают мне, что человечным может быть и пространство кода.
Многие лицензии с экстравагантными условиями написаны, как кажется, для души, нежели чем для фактического регулирования отношений по использованию ПО. Например, они могут содержать неопределенные условия или больше отражать позицию автора, чем фактические требования к использованию ПО.
Однако, не стоит полагать, что все «смешные» лицензии безопасны. Их условия могут мешать использованию в определенной сфере деятельности или же делать код несовместимым с другими лицензиями. Нарушение этих условий все еще будет нарушением права на ПО, несмотря на всю их кажущуюся несерьезность. С другой стороны, громких и больших споров по нарушению условий странных лицензий нет. Или же они есть в таком количестве и масштабе, что это практически незаметно. Такая ситуация может быть объяснима следующим:
ПО по лицензиям со странными ограничительными условиями не включают в большие проекты, поскольку этот небольшой элемент может саботировать всю работу. Даже если нарушения и есть, эти лицензии довольно нишевые и круг заинтересованных лиц в защите прав на лицензируемое ПО относительно небольшой и не обладает достаточными ресурсами для мониторинга и защиты по ним, чтобы инициировать такие кейсы самостоятельно. Странные лицензии, если они разрешительные, наоборот, включают довольно часто, с ними просто не возникает проблем. Сам неоднократно был свидетелем 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 или наш продукт.
А приведенный список лицензий в статье хотелось бы дополнить ещё одной полезной ссылкой, где каждый сможет найти для себя своё.