Предыдущую статью я закончил на том, что сегодня интерес к ИИ большой, структура ИИ-проекта сложная, open source в ИИ подавляющее количество. При этом всё чаще мы видим, что при попытке бизнеса выпустить open source проект части этого проекта лицензируются по-разному.
Зачем?
Open source и AI
Благодаря тому, что общее технологическое развитие в IT в целом подтянулось, тема машинного обучения вышла из научных и промышленных кругов на широкие массы и бизнес. Лет пять назад мы говорили про чат-ботов, но работали они часто на запрограммированном дереве решений. Мы говорили про генерацию контента, но легкодоступного оборудования для обучения моделей, чтобы сгенерировать его качественно, не было. Сегодня в облаке есть и оборудование, которое легко получить, и масса моделей, часть из которых разработана вендорами, часть — использующая наработки ChatGPT и иже с ними.
Вопрос того, потеряет ли человечество какие-то профессии благодаря этим трендам, интересный, но кто является правообладателем того, что создано? На этот вопрос надо отвечать уже сейчас, что оказалось сложной задачей.
Связь может быть неочевидна, поэтому приведу обобщенный пример. Большая компания выкатывает генерационную модель сначала у себя, а потом в open source. Компания получает множество бонусов, так как ее модель обучают, отдают обратную связь по ее работе, в общем, всё отлично. Появляется стартап, который берет эту разработку и делает на основе нее собственный продукт с дополнительной ценностью. Например, если это генерация картинок, то генерация картинок на какую-то конкретную тему с увеличенной точностью и качеством. Получается, что возникает контент, который был сделан с использованием продукта, созданного на основе другого продукта, обученного на данных, которые неизвестно кому точно принадлежат и откуда взяты. Эта последовательность может быть сколь угодно длинной, но приводит она к одному: вопросу, кто в итоге является правообладателем этого контента и что произойдет, если компания, сделавшая этот продукт изначально, изменит свою лицензию, а стартап это не отследит и продолжит продавать контент?
Получается, что бизнесу выгоднее отчуждать ту часть проекта, которая приносит либо будет приносить ему деньги, и лицензировать его иначе, нежели продукт деятельности этого проекта либо вспомогательные инструменты. В принципе, это то, что можно назвать планированием ИИ как продукта, когда вокруг core-части продукта, чаще всего сложного программного кода, формируется экосистема, которую надо как-то продвигать. Часто выбирают самый простой путь — показывать, что продукт работает эффективно, и таким образом продвигать продукт, получая за него деньги по той или иной модели.
Например, выложить обработанные лицензированной моделью данные, показать, что она работает, создать лояльную базу пользователей и продавать эту модель по модели подписки-сервиса. Так сделала Microsoft, предоставив Azure Machine Learning в облаке. Фактически это пользовательский интерфейс-конструктор, который позволяет загрузить свои данные, которые пройдут обработку внутри экосистемы Microsoft, подключить необходимые модели (например, распознавание образов и в дальнейшем их группировку) и получить результат. Это простая для понимания конечным пользователем модель, причем, насколько известно автору, строить на основе этого собственные решения, покупая мощности Microsoft, не запрещено. Это многоуровневая бизнес-модель, которой пользуются как стартапы, так и корпорации.
Промежуточный вывод
Пользователи и бизнес не любят сложность. Как показывает практика, пользователи в целом готовы мигрировать с одного продукта на другой, если им становится некомфортно им пользоваться и даже если лицензия нового продукта сложна для понимания.
У бизнеса же ситуация значительно сложнее. У небольшого программного проекта может быть множество зависимостей, у которых свои зависимости, и внутри этого дерева могут возникать коллизии. Например, смена лицензии одной из зависимостей. Для open source проекта это может грозить репутационными потерями, для бизнеса же — сломом бизнес-ритмов.
По этой причине появляются инструменты, анализирующие зависимости на момент безопасности, от которых отпочковываются инструменты, анализирующие лицензионную чистоту.
Почему мы должны думать о лицензии?
Пока я готовил эту статью, Broadcom заархивировала open source проект Greenplum. Несмотря на то что многие говорят, что ванильный проект Greenplum не так уж кому и нужен, я вижу это как очередной кирпичик в построении нового видения open source, корпоративного.
Лицензия — это попытка выровнять ожидания разработчика проекта и ожидания пользователя от использования этого проекта. В условиях, в которых возможны юридические прецеденты, любое нарушение лицензионного соглашения может нести за собой репутационные и другие угрозы для пользователя и бизнеса. Сегодня скорее для бизнеса, поскольку ни возможности как-то обнаружить частное нарушение лицензии, ни особого желания не наблюдается.
Основные аспекты лицензии покрывают использование, возможность коммерциализации, построения своих проектов поверх и распространения.
У лицензий есть общий наблюдательный орган, Open Source Initiative (OSI), который сертифицирует новые лицензии и следит за соблюдением уже существующих. В списке OSI более ста лицензий, но это не означает, что разработать и сертифицировать лицензию легко. Ревью-процесс состоит в общих положениях и достижении консенсуса через дискуссии сообщества. Одна из больших целей OSI — снизить количество дублирования в лицензиях и улучшить, сделать формулировки более понятными.
Самые популярные и часто используемые лицензии: Apache License, Common Development and Distribution License, Eclipse Public License, GNU General Public License, Mozilla License, BSD License, MIT License.
Если проект берет, например, MIT, то лицензионное соглашение позволяет пользователям свободно форкать или копировать код. Если GNU GPL — то добавляет некоторое количество ограничений. Например, указание, что любая модификация части проекта должна вести к отметке его как modified, чтобы не было претензий к оригинальному разработчику. Этот проект становится зависимостью другого проекта с другой лицензией. У некоторых проектов могут быть тысячи зависимостей. Изменение любой из них может нарушить лицензионную целостность и в некоторых случаях лицензионную чистоту проектов, использующих их.
Рассмотрим ситуацию, которую однажды описывали где-то на Реддите, к сожалению, ссылка не сохранилась.
Популярный open source проект, несколько мейнтейнеров, без всякой бизнес-модели. Контактное лицо проекта получает письмо от компании X с просьбой заполнить опросник. В письме указано, что в их продукте используется open source проект и продукт проходит аудит безопасности/сертификации. Почему это происходит? Потому что open source проект был взят в коммерческое использование и стал предметом исследований внутри компании, аудита в данном случае. Этого можно было бы избежать, форкнув проект и инвестировав собственные ресурсы. Для больших компаний, в которых выстроены процессы разработки и взаимоотношений с open source, форкать проект может быть простой задачей, но таких меньшинство. Однако форки наследуют ограничения лицензий и каждую ситуацию надо анализировать в моменте.
Время идет, количество неоднозначно трактуемых ситуаций возрастает. Вышеописанные кейсы с аудитом, непрозрачной цепочкой авторского права и неожиданные смены лицензий создают нарастающую массу юридических коллизий, опасных для бизнеса. Государственные организации находятся ровно в такой же ситуации. И если бизнес способен так или иначе договориться между собой на собственных условиях, аналогичные риски у государственных организаций вызывают пристальное внимание регуляторных органов.
Почему важно регулировать open source и как пытаются это делать?
В 2023 году, по данным OpenAI, их сайт посетили больше полутора миллиардов раз, а активных пользователей было около 100 миллионов в месяц. И все из них генерируют контент.
Этот контент попадает в открытый доступ, и на нем обучаются open source модели, которые становятся лучше и, по мнению некоторых экспертов, иногда достигают качества коммерческих моделей GPT-4. Регулировать эти события сложно, но многие страны пытаются, так как есть опасения: если в стране N использовать модель, сделанную в стране M, то кто получает от этого большую выгоду? Отсюда большое количество законотворческой деятельности, одними из самых активных представителей которых являются США и Евросоюз. Сопутствующий урон, и довольно ощутимый, получает мир open source.
В качестве аргументации необходимости регулировать развитие ИИ часто называют высокий шанс использования генерируемого контента для пропаганды, влияния на исходы различных инициатив, имперсонацию (генерацию контента от лица человека, который не был его автором, но по той или иной причине порочащего этого человека). Корпорации, наиболее уязвимые к последствиям регуляторных ограничений, добавляют больше ограничений и правил в условия использования.
Можно ли регулировать контент, но не трогать open source?
Ответ пока отрицательный. Задача, в конце концов, правильная и достойная: минимизировать вред от контента. Но если бизнес можно обязать различными регламентами, то частных пользователей, которым доступно огромное количество инструментов, можно либо ограничивать больше, чем надо, либо влиять каким-то другим образом.
Осмелюсь утверждать, что в истории с регуляцией контента, который создается open source и проприетарными инструментами, больше всего страдает open source сообщество. Так, фреймворк по регуляции ИИ в США включает в себя очередной президентский Executive Order, а в Евросоюзе в 2024 году войдет в силу крайне неоднозначно воспринятый сообществом open source Cyber Resilience Act. Последствия санкционных ограничений на Россию и другие страны со стороны США также вызывают обеспокоенность у апологетов open source, так как вдобавок к попыткам сделать суверенные разработки добавляется риск прийти к изоляционизму и распаду open source на региональные островки. Это снизит темпы развития и повлечет каскадом замедление индустрии, всё плотнее сидящей на open source проектах.
Внимание к ИИ приковано и у организаций, занимающихся стандартизацией и другими историями, которые раньше имели ключевое значение для индустрии. Это IEEE, ISO/JTC, CEN, Linux Foundation, CNCF и многие другие. За счет работы экспертов из сообщества и корпораций внутри этих организаций индустрия ограничивала (старалась) излишнее влияние отдельных игроков. Поэтому всё вышеописанное — про инструменты для профессионального и личного использования, управляемые корпорациями, — увеличило влияние нескольких игроков.
Пока я писал статью, в Евросоюзе успели согласовать AI Act, который наложил массу ограничений на LLM и конкретно упоминает open source. Для компаний, которые публикуют модели в open source, благодаря активистам были сделаны поблажки.
Заключение
Ситуация меняется каждый день. Уложить в одну статью что-то кроме высокоуровневой картины невозможно, да и отдельные детали этой картины меняются слишком часто. Единственное, что понятно сегодня: open source стал фактически заложником ситуации с массовым распространением контента. Законодатели, пытаясь решить глобальную проблему, невольным образом закладывают коллизии с open source на будущее.
На этом всё на сегодня. В следующей статье поговорим про безопасность и затронем новую тему: как в open source стало настолько много инструментов, что это перестало быть хорошей новостью.
