В философии есть известный парадокс — корабль Тесея: если заменить все доски, будет ли это тот же самый корабль? Похожая дискуссия с начала марта развернулась и в ИТ-сообществе, и виноваты в этом, как в последнее время часто бывает, системы ИИ, способные за считаные минуты с нуля переписать открытый проект. Кейс библиотеки chardet вызвал споры о допустимости и этичности такого подхода, а также о роли лицензирования в новой реальности. Сегодня мы в Beeline Cloud решили обсудить различные точки зрения по этому вопросу, ведь некоторые считают, что переписывание открытых библиотек с помощью больших языковых моделей — это, наоборот, благо и инструмент для защиты от атак на цепочки поставок.

Изображение: marc belver colomer (Unsplash License)
Изображение: marc belver colomer (Unsplash License)

Первая искра

В начале марта разработчик Дэн Бланшар, который больше 12 лет назад принял на себя обязанности мейнтейнера библиотеки chardet [разработанной в 2006-м Марком Пилгримом], переписал ее с нуля и выпустил под новой лицензией — MIT вместо вирусной LGPL. А вскоре после этого вообще изменил лицензию на 0BSD, которая не имеет никаких условий.

Свое решение он обосновал давним желанием добавить chardet в стандартную библиотеку Python (которая распространяется под разрешительной лицензией PSFL), а заодно повысить производительность кода: «Поддерживая chardet в основном в одиночку [у проекта были и другие контрибьюторы, но подавляющее большинство коммитов было сделано лично Бланшаром] на протяжении многих лет, я понял, что на пути развития проекта стоят несколько преград: скорость, точность и лицензия».

Вся ситуация не была бы крупным инфоповодом, разлетевшимся по интернету, если бы не одно но — новая версия была целиком написана с помощью ИИ-агента. При этом разработчик утверждает, что использовал метод «чистой комнаты» — когда проект реализуется с нуля без обращения к исходникам оригинала. Сперва Бланшар использовал функцию «мозгового штурма» из агентского фреймворка superpowers; с ее помощью он подготовил спецификацию и описание архитектуры новой версии библиотеки [она должна была работать с PyPy и CPython, быть совместимой с публичными API и эффективно использовать возможности многоядерных систем]. Затем он передал эти инструкции в Claude для написания кода.

По оценке JPlag — инструмента для выявления заимствований в коде — пересечения между последней версией под лицензией LGPL и новой версией составляют чуть более 1%. По мнению Бланшара, это достаточное доказательство легитимности подхода.

Но несмотря на, казалось бы, прозрачный процесс, никто из более чем 50 контрибьюторов не поддержал смену лицензии, наоборот, «переворот» Бланшара стал первой искрой, породившей масштабный спор в ИТ-сообществе.

А что, так можно было?

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

Сомнения Пилгрима отчасти поддерживает сторонник открытой разработки Сюдзи Садо, глава японской ассоциации, продвигающей культуру открытого кода: «Сложно говорить об использовании метода “чистой комнаты”. Бланшар имел доступ к исходникам, поэтому позиция Марка кажется более убедительной».

Разумеется, есть участники ИТ-сообщества, которые не видят здесь проблемы. Среди тех, кто поддержал смену лицензии — разработчик Redis Сальваторе Санфилиппо. По его мнению, в ситуации с chardet все однозначно, поскольку права (по крайней мере, с точки зрения американского законодательства) не были нарушены: «Закон гласит, что нельзя копировать “защищенные выражения” — то есть, в нашем случае это код в исходном виде» [еще в 1879 году в США были приняты поправки в законодательство, согласно которому авторское право распространяется только на конкретную реализацию идеи, но не на саму идею]. 

В лагерь сторонников перелицензирования также вступил Армин Ронахер, автор Flask. По его мнению — хотя он сам подчеркивает свою предвзятость, так как заинтересован в проекте chardet с разрешительной лицензией — ничего криминального во всей этой истории не произошло: «Я сам собирался "провернуть" такой трюк с некоторыми библиотеками под GPL и даже начал реализовывать свою версию readline».

Изображение: Emile Seguin (Unsplash License)
Изображение: Emile Seguin (Unsplash License)

В целом сторонники позиции Бланшара подчеркивают, что метод «чистой комнаты» применялся и ранее для куда более крупных проектов — и, по сути, единственное, что изменилось сегодня, это скорость реализации благодаря системам ИИ. Еще в 1980-х Ричард Столлман и его сторонники переписали основные компоненты пользовательского пространства UNIX в рамках проекта GNU, чтобы освободить их от ограничений проприетарного ПО. При разработке Linux Линус Торвальдс во многом опирался на идеи и архитектуру Minix, с которой был хорошо знаком.

Метод «чистой комнаты» использовала даже компания Phoenix Technologies, когда в 1984 году фактически «воссоздала» IBM BIOS. Для этого инженеров разделили на две группы. В первую вошли те, кто был знаком с техническими руководствами и распечатками исходного кода IBM — они же составляли спецификацию нового проекта. Во вторую попали программисты, которые никогда не видели исходников, и они реализовывали систему с нуля. В результате появился ROM BIOS — полностью легальная и более доступная альтернатива оригинальному решению. Кстати, сам подход «чистой комнаты» изначально появился в стенах IBM как способ предотвращать критические ошибки на этапе разработки. Иронично, что одним из самых показательных примеров использования этого метода стал их продукт-конкурент.

Наконец, в ИТ-сообществе можно встретить мнение, что подобные «ИИ-копии» библиотек могут стать инструментом, позволяющим предотвратить атаки на цепочки поставок, когда злоумышленники компрометируют компоненты открытой экосистемы. Такие ситуации не редкость — пожалуй, многие слышали историю, которая произошла с библиотеками colors.js и faker.js в 2022 году. Разработчик Марак Сквайрс сознательно «сломал» свои проекты, выпустив для них вредоносные обновления. В первом случае в код была добавлена бесконечная петля, которая выводила в консоль слово «свобода» на английском языке. Во втором случае Сквайрс просто удалил рабочий код из публичного репозитория и npm-пакета.

Если системы ИИ позволяют за короткое время переписать критичные модули инфраструктуры, то атаки на цепочки поставок, подобные colors.js и faker.js, могут стать в принципе невозможными (или, по крайней мере, труднореализуемыми). И кажется, такая практика набирает обороты — появляются платформы вроде MALUS, которые стремятся автоматизировать подход «чистой комнаты». Сервис предлагает пользователям систему ИИ-агентов, которые изучат документацию «клонируемого» проекта, составят спецификацию, а затем воссоздадут программное обеспечение с нуля. В компании делают акцент на то, что методика эта — можно сказать, «канон» в ИТ: «Это тот же самый процесс, что использовали Phoenix Technologies в 1980-х. <...> Мы просто применили современные технологии к доктрине прошлого века».

Разберется комьюнити

Сегодня нет единого фреймворка, определяющего рамки лицензирования контента, сгенерированного ИИ-системами. Позиции по этому вопросу отличаются от страны к стране. У нас в России сейчас рассматривают законопроект, согласно которому контент, сгенерированный системой ИИ, может охраняться авторским правом, если будет оригинальным творением. А вот Верховный суд США в марте постановил, что контент, сгенерированный ИИ-системой, напротив, не может быть защищен авторским правом — суд обосновал решение тем, что работа в первую очередь должна быть выполнена человеком, и это «железобетонное правило». Суды в США в целом считают, что нейросетевое творчество автоматически становится достоянием общественности.

Технический директор одного из крупнейших частных коммерческих банков Вьетнама убежден, что аналогичный подход должен применяться и к сгенерированному коду. Он, как и многие другие участники дискуссии, говорит, что у новой версии chardet вообще не может быть лицензии. Армин Ронахер также предположил, что подобные проекты нельзя лицензировать, так как всю работу выполнил ИИ-агент практически без участия человека.

Изображение: Vinicius “amnx” Amano (Unsplash License)
Изображение: Vinicius “amnx” Amano (Unsplash License)

Но даже если отойти от вопросов, связанных с лицензиями, самая сильная сторона и движущая сила опенсорса — это комьюнити. Если программное обеспечение будет переписано и выложено под другой лицензией, то сообщество просто может отказаться мигрировать или форкнуть оригинальный проект. Наверное, самая наглядная из подобных историй — кейс Terraform. В 2023 году HashiCorp перевела инструмент на лицензию BUSL, однако буквально через две недели участники комьюнити, заручившись поддержкой спонсоров, представили форк OpenTofu, который продолжил развиваться под открытой лицензией.

Судя по активности сообщества, с момента запуска количество контрибьюторов в форк увеличилось втрое, а в развитие оригинального инструмента сообщество почти не включается. А в случае Terraform только 9% пул-реквестов теперь идут от сторонних разработчиков, хотя раньше этот показатель держался на уровне 21%. Также стоит отметить, что кейсы, подобные chardet, могут стать полем для битвы в сфере корпоративных интересов, если компании начнут переписывать сервисы друг друга, чтобы переманить аудиторию. Подобные вещи уже происходят — в январе этого года Vercel с помощью ИИ-агентов разработали свою версию bash на TypeScript, но были не очень довольны, когда другой облачный провайдер за одну неделю реализовал vinext — аналог Next.js от Vercel. В любом случае пока есть свежие и громкие прецеденты подобных переделок — их будут обсуждать в комьюнити. Но приживется ли такой подход, станет понятно по мере развития ситуации и появления других примеров.

Beeline Cloud — безопасный облачный провайдер. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.

Что еще почитать в нашем блоге и медиа: