Мы переписали на Python несколько старых программ. G2P-фронтенд espeak-ng, правила транскрипции галисийского и испанского из Cotovia, баскскую лингвистическую обработку из AhoTTS, N3-резонёр EYE и резонёр OWL 2 DL HermiT. C, C++ и Java, большинству из них больше десяти лет, и все они по-прежнему лучшее, что есть для своей задачи.
Мотив был обычный. Программа на C, которая фонемизирует галисийский, отлично работает,
пока вы не захотите встроить её в стек речи на Python на плате ARM. Тогда вам нужен
компилятор, тулчейн, кросс-компиляция, история упаковки под каждую платформу и
граница subprocess, через которую приходится маршалить текст. Java-резонёру нужна JVM.
Чистому Python нужен pip install. Это ещё и читаемо: можно открыть файл, который
решает, куда падает ударение, и изменить его, не зная, как работает исходная
система сборки.
Порты были сделаны полуавтономно. ИИ читал исходный код и писал Python; человек направлял работу и сверял результат с оригинальным бинарником. В нескольких случаях никто с нашей стороны так и не прочитал исходный код. Его читала модель. Мы читали диффы и тесты на паритет.
Это оставляет вопрос, по которому нам пришлось принять решение и на который мы не смогли ответить: является ли результат производным произведением, и кому он принадлежит?
Мы инженеры. Ничто здесь не является юридической консультацией, и мы не квалифицированы её давать. Это описание решения, которое мы приняли, и рассуждений, которые к нему привели.
Два вопроса, которые постоянно путают
Реализовать программу заново, прочитав её исходный код, — не новость. Люди переписывали C на Python с тех пор, как появился Python. Новое здесь — расстановка ролей: читатель — машина, реализатор — та же машина, а люди в цепочке никогда не видели оригинала.
Здесь два вопроса, и почти в каждом обсуждении их сваливают в один. Они независимы.
- Может ли результат вообще принадлежать кому-то? Авторское право закрепляется за произведениями, у которых есть авторы. Если код произвела машина, кто автор?
- Является ли результат производным от входных данных? Кто бы ни был автором — если он вообще есть — нарушает ли результат права на оригинал?
На один вопрос можно ответить «да», а на другой «нет», в любой комбинации. Держите их раздельно.
Немного терминологии, поскольку на ней держится всё дальнейшее. Производное произведение (derivative work) — это произведение, основанное на уже существующем: перевод, адаптация, порт. Право создавать такое произведение принадлежит правообладателю оригинала. Копилефтные (copyleft) лицензии (семейство GPL) позволяют использовать и модифицировать код при условии, что распространяемый результат остаётся под теми же условиями. Разрешительные (permissive) лицензии (MIT, Apache-2.0, BSD) позволяют делать практически что угодно, включая включение результата в проприетарное ПО. LGPL находится между ними: копилефт применяется к самой библиотеке, но её подключение к более крупной программе не делает эту программу открытой. Все они построены на авторском праве. Они действуют, только если есть авторское право, которое можно защищать.
Вопрос первый: есть ли автор?
Авторское право требует человека-автора. Бюро авторских прав США последовательно придерживалось этой позиции, и по делу Thaler v. Perlmutter Апелляционный суд округа Колумбия согласился: Закон об авторском праве «требует, чтобы любое подпадающее под охрану произведение изначально было создано человеком» (No. 23-5233, D.C. Cir., 18 марта 2025 г.; Верховный суд отклонил ходатайство о пересмотре в марте 2026 г.). Европейский стандарт устроен иначе по форме, но приводит к похожему результату — охрана требует «собственного интеллектуального творения автора» (author’s own intellectual creation), что предполагает наличие автора, который творит.
Ни один из этих подходов не говорит, что работа, созданная при помощи ИИ, не охраняется. Оба говорят, что то, что машина сгенерировала самостоятельно, — не охраняется. Граница проходит внутри произведения, а не вокруг него, и то, где именно она пролегает, зависит от того, насколько велик вклад человека. В наших портах вклад человека реален, но тонок: выбор цели, структурирование пакета, оценка сбоев паритета. Не очевидно, что этого достаточно, чтобы считать нас авторами правил транскрипции.
Это порождает неловкий объект. Лицензия — это предоставление разрешения правообладателем. Если ни у кого нет прав на результат, файл лицензии в корне репозитория — просто украшение. Обратите внимание, куда ведёт этот аргумент: он сначала съедает вашу собственную лицензию. Любой, кто утверждает, что сгенерированный машиной код никому не принадлежит, тем самым утверждает, что его собственные условия распространения неисполнимы, ещё до того, как речь заходит о правах вышестоящего проекта.
Вопрос второй: является ли это производным?
Этот вопрос не зависит от того, кто автор. Нарушение прав определяется доступом к оригиналу плюс существенным сходством с его охраняемым выражением (expression) — конкретным способом, которым вещь была написана, а не тем, что она делает.
У нас был доступ. Модель читала исходный код. Эта половина не оспаривается.
Половина про сходство — вот где становится интересно, и где смена языка значит меньше, чем можно подумать. Перевод романа на другой язык создаёт производное произведение; это хрестоматийный пример. Смена языка снимает претензию о буквальном копировании. Она не снимает претензию о структуре — порядке преобразований, декомпозиции на функции, форме таблиц правил, способе, которым разложены крайние случаи.
Стоит также прямо сказать, что инструмент ничего не «отмывает». Если вы направляете копирование и распространяете результат, именно вы его создали. «Это написала модель» — не защита в большей степени, чем «это выдал компилятор».
Самый сильный аргумент с другой стороны
Есть серьёзные основания считать, что кросс-языковая переимплементация допустима, и их стоит изложить как следует, а не просто упомянуть.
В деле SAS Institute v World Programming (Суд ЕС, C-406/10, 2 мая 2012 г.) суд постановил, что «ни функциональность компьютерной программы, ни язык программирования и формат файлов данных, используемых в компьютерной программе для использования некоторых её функций, не составляют форму выражения этой программы». Следовательно, они не охраняются авторским правом. Директива о программном обеспечении (2009/24/EC, статья 1(2)) говорит то же самое об идеях и принципах, лежащих в основе любого элемента программы. Суд также постановил, что лицензиат может изучать и наблюдать за поведением программы, чтобы определить лежащие в её основе идеи, и реализовать их заново.
Это не техническая деталь. Это означает, что то, что делает фонемизатор — эта последовательность графем в этом контексте становится той фонемой — никому не принадлежит. Правила ударения галисийского языка — факты о галисийском языке. Прямая семантика OWL 2 — опубликованная спецификация W3C. При таком прочтении переимплементация, воспроизводящая поведение, а не выражение, законна, и переписывание на другом языке гораздо дальше от нарушения прав, чем копирование-вставка.
Разрыв между этим аргументом и нашей ситуацией — в источнике. SAS — про изучение поведения. Наша модель читала код.
Прецедент, который уже существует, и насколько далеко он простирается
Аргумент «у машинного вывода нет автора, значит, авторское право не возникает» — не мысленный эксперимент. Он лежит в основе промышленной практики. Дистилляция моделей и синтетические обучающие данные оба опираются на него.
Самое ясное публичное заявление этого — карточка модели Kokoro-82M, широко используемой открытой TTS-модели. В ней говорится, что модель обучена исключительно на разрешительном или не защищённом авторским правом аудио, и среди допустимых источников перечислено:
Synthetic audio generated by closed TTS models from large providers
со сноской на руководство Бюро авторских прав США по политике в отношении ИИ («Синтетическое аудио, сгенерированное закрытыми TTS-моделями крупных провайдеров»). Цепочка рассуждений та же, что и выше: аудио сгенерировано машиной, у машинного вывода нет человека-автора, значит, в нём не возникает авторского права, значит, обучаясь на нём, нечего нарушать. Модель распространяется под Apache-2.0. В карточке также проведена граница — она исключает синтетическое аудио из открытых TTS-моделей и из пользовательских клонов голоса, — что указывает: авторы продумали, где аргумент перестаёт работать, вместо того чтобы применять его повсеместно.
Вот часть, важная для портирования. Этот прецедент решает другую половину проблемы.
Аргумент Kokoro — о входных данных. То, что они потребляли, само было сгенерировано машиной, поэтому утверждается, что изначально это не несло авторского права. Не защищено на входе — значит, нечего наследовать.
Наша ситуация — зеркальное отражение. То, что мы потребляли — C espeak-ng, C++ Cotovia, Java HermiT — безусловно написано людьми и защищено авторским правом, конкретными людьми, в конкретных университетах, десятилетия назад. То, что получилось на выходе, написала машина. Аргумент «нет авторского права в выводе ИИ» ложится на наш выход, а не на наш вход. Он не распространяется вверх по цепочке. Это, опять же, аргумент, который подрывает нашу собственную лицензию, оставляя права вышестоящего проекта полностью нетронутыми.
Есть и дополнительная асимметрия, которую стоит отметить. Остаточный риск Kokoro — на самом деле не столько авторское право, сколько договор. Условия обслуживания закрытых провайдеров, как правило, запрещают использовать их вывод для обучения конкурирующих моделей, и условие, с которым вы согласились, не исчезает от того, что вывод оказался незащищённым авторским правом. Копилефт работает иначе. Никто не нажимает «согласен» под GPL. Это односторонний грант разрешения, и он связывает вас только если вам нужно это разрешение — то есть только если то, что вы создали, является производным произведением.
Так что всё сводится обратно к тому единственному вопросу, на который никто не ответил. Если кросс-языковая, написанная машиной переимплементация не является производным произведением, GPL никогда не вступала в действие и ничего из её условий не применялось. Если это производное произведение, GPL применялась с первой строки. Третьего состояния нет, и никакие споры об авторстве ИИ не сдвигают эту конкретную стрелку.
Чистые комнаты и составляют ли две модели одну
Классический ответ ровно на эту проблему — протокол «чистой комнаты» (clean room), и стоит описать его точно, потому что форма имеет значение.
Одна команда читает оригинал и пишет функциональную спецификацию: что программа делает, в терминах поведения. Вторая команда, никогда не видевшая оригинала, реализует только по этой спецификации. Результат второй команды доказуемо не скопирован с выражения, которое она никогда не видела. Именно так был реализован заново BIOS для ПК, и именно поэтому эта переимплементация выстояла.
Очевидный современный шаг — запустить одну модель для чтения и описания и другую модель, с чистым контекстом, для реализации. Структурно это тот же протокол. Является ли это чистой комнатой?
Форма правильная. Но чистая комната — это не техническая конструкция, а доказательственная. Вся её ценность в том, чтобы суметь впоследствии продемонстрировать разделение тому, кто заранее подозревает вас в жульничестве. Так что версия с двумя моделями что-то значит только если дисциплина соблюдается на всём протяжении:
- Обе стороны действительно никогда не делят контекст. Не «мы сказали ей забыть» — отдельные запуски, отдельные транскрипты.
- Спецификация несёт поведение и ничего больше. Никакого псевдокода, повторяющего поток управления оригинала. Никаких имён идентификаторов. Никакого порядка функций. Это выражение, и спецификация, полная им, — это оригинал в другом костюме.
- Записи обеих сторон сохраняются, потому что чистая комната, которую нельзя подтвердить доказательствами, — это просто история.
Если читающая сторона выдаёт структуру, заражение проходит насквозь, и вы получаете производное произведение с дополнительными шагами и более крупным счётом за токены.
Мы этого не делали. Реализующая модель читала исходный код напрямую. Именно поэтому в README pycotovia сказано, в самом репозитории, публично:
Because the implementing AI read the GPL source, this is not a clean-room reimplementation and we make no such claim. It is a source-derived port.
(«Поскольку реализующий ИИ читал исходный код под GPL, это не переимплементация методом чистой комнаты, и мы не заявляем об этом. Это порт, производный от исходного кода.»)
Мы предпочитаем, чтобы это предложение было записано, а не отвечать на этот вопрос позже.
Что мы сделали
Мы сохранили лицензии вышестоящих проектов.
espyak распространяется под
GPL-3.0-or-later, как и espeak-ng. Это даже не сложный случай: пакет включает
файлы данных espeak-ng дословно — dictsource, phsource, lang, — и никакая
теория авторства не касается файлов, которые мы скопировали без изменений. Данные
вышестоящего проекта находятся внутри wheel-пакета, поэтому лицензия вышестоящего
проекта идёт вместе с ними.
pycotovia распространяется под GPL-3.0, как и Cotovia (GPL-3.0+). ahotts-g2p и pyAhoTTS-Iparrahotsa — под GPL-3.0, как и AhoTTS, файл лицензии которого указывает GPL-3.0+ для лингвистической обработки. pyeye — под MIT, как и EYE. Копилефт на входе — копилефт на выходе; разрешительная лицензия на входе — разрешительная на выходе.
Мы сделали это не потому, что установили, что это обязательно. Мы сделали это потому, что асимметрия принимала решение без необходимости знать ответ.
Мы всё равно публикуем как открытый исходный код. Копилефт обходится нам почти бесплатно — единственная реальная цена — это случай, когда клиент хочет встроить код в нечто проприетарное, а для этих конкретных библиотек такой случай редок. Так что быть копилефтными, когда это не было строго обязательно, стоит примерно ноль.
Другая ошибка не симметрична. Выпустить разрешительную лицензию на то, что должно было быть копилефтным, — проблема, обнаруженная поздно, публично, кем-то другим, после того как другие люди построили что-то на её основе на условиях, которые вы не имели права предлагать. Отменить это означает связаться с каждым нижестоящим пользователем.
Эта асимметрия — также причина, по которой за таким несоответствием стоит следить в целом. Структурный порт оригинала под LGPL не может просто стать Apache-2.0 из-за переписывания на другом языке — и это именно тот тип несоответствия, который легко создать и трудно заметить, потому что ничто не жалуется. Сборка проходит. Тесты проходят. Заголовок лицензии — просто файл. HermiT распространяется под LGPL, так что лицензирование нашего Python-порта этой библиотеки — один из случаев, которые мы сейчас пересматриваем, — а это обычный, правильный итог: вы проверяете и исправляете то, что нужно исправить.
При такой лопнутой асимметрии не нужно решать юридический вопрос, чтобы принять решение. Вы просто выбираете ветвь, на которой ошибиться можно пережить.
Тот же вопрос, направленный в другую сторону
Всё вышесказанное — про код, который производим мы. Та же самая логика применима к коду, который мы получаем. Кто-то открывает pull request в один из наших репозиториев. Патч написала модель. Что нам предоставляют?
Большинство проектов решают это с помощью
Developer Certificate of Origin — DCO, строки
Signed-off-by: внизу сообщения коммита. Это короткое заявление, которое
подтверждает автор при подписи: что он создал этот вклад самостоятельно, либо что
он получен из источника с совместимой лицензией, и у автора есть право предоставить
его на условиях проекта. Оно намеренно лёгкое. Никаких юристов, никакой бумажной
волокиты, одна строка на коммит. Именно так ядро Linux и QEMU, среди многих других,
устанавливают происхождение своего кода.
Для написанного машиной патча ни одно из этих двух условий не выполняется прямым образом. И развилка разрешается одинаково, какую бы ветвь вы ни выбрали.
Если у сгенерированного машиной вывода нет авторского права, у контрибьютора нет прав на него. Нечего вам лицензировать.
Если же считать его производным от обучающих данных, права — какими бы они ни были — принадлежат тому, кто написал эти данные. У контрибьютора всё равно нет ничего, что можно было бы вам предоставить.
В обоих случаях они не могут предоставить то, чем не владеют. Подпись при этом не является нечестной. Контрибьютор подписал добросовестно и проделал работу. Она просто пуста: передача того, что никогда ему не принадлежало.
Практическое следствие менее тревожно, чем звучит, и две ветви заметно различаются.
На первой ветви грант вообще не нужен. Материалом, которым никто не владеет, может пользоваться кто угодно. Принять патч — нормально, и ничего плохого не происходит. Тихо меняется другое направление: копилефт построен на авторском праве и не может закрепиться за материалом, у которого его нет. Проект под GPL, накапливающий написанные машиной патчи, накапливает части, которых его собственная лицензия, возможно, не охватывает. Лицензия по-прежнему регулирует произведение в том виде, в каком оно распространяется. Но исполнимое ядро внутри него медленно истончается, незаметно для всех.
У второй ветви есть зубы. Если модель воспроизводит запомненные обучающие данные дословно — а это случается, чаще с распространёнными идиомами и хорошо известными реализациями, чем с новаторской логикой, — то вы приняли чей-то чужой защищённый авторским правом код, на основании заверения контрибьютора, у которого не было возможности это проверить. Вся ценность DCO в том, что подписывающий был в положении, позволяющем это знать. Здесь это не так.
Debian сейчас разбирается с этим. Общая резолюция об использовании LLM вступила в фазу обсуждения 23 июля 2026 года с пятью предложениями в бюллетене. Они охватывают весь спектр: Предложение A внесло бы поправку в Общественный договор, полностью запрещающую вклад с использованием LLM в пакеты, документацию и веб-ресурсы; Предложение C просит контрибьюторов по возможности избегать LLM, требует, чтобы коммуникации проекта составлялись только людьми, и позволяет отдельным сопровождающим вводить собственные запреты; Предложения B, D и E допускают работу с помощью ИИ при определённых условиях, построенных, соответственно, на проверке лицензирования, ответственности контрибьютора, раскрытии информации и ограничениях на отправку конфиденциальных материалов в облачные сервисы. На момент написания статьи вопрос обсуждается, и ничего не решено.
Это уже вторая попытка. Более ранняя попытка в 2024 году закончилась без резолюции, и причину, по которой её остановили, стоит запомнить: возражение против действия состояло не в том, что беспокойство беспочвенно, а в том, что правило, которое никто не может обеспечить, не стоит принимать. По диффу нельзя определить, кто его написал.
Это не маргинальное беспокойство. Оно бьёт сильнее всего именно по проектам с самым тщательным происхождением кода, потому что вся модель того, откуда взялся код в проекте на базе DCO, держится на одном этом заверении.
Мы не решили, как будем с этим поступать, и мы в плохой позиции, чтобы быть строгими. Мы выпускаем порты, написанные моделью. Проект, который публикует написанный машиной код и отказывается принимать написанные машиной вклады, держит две несовместимые позиции одновременно, и нам бы этого не хотелось. Честные варианты те же самые, что взвешивает Debian, — раскрытие информации, ответственность контрибьютора или правило, которое нельзя проверить, — и мы ни один из них ещё не выбрали.
Другая ось, вдоль которой идёт спор
Дебаты Debian — про происхождение кода и лицензирование. Это не единственная ось, и вторая не имеет никакого отношения к авторскому праву.
Codeberg, FLOSS-форж, в июле 2026 года принял два одобренных участниками решения и изложил свои рассуждения в терминах, почти не касающихся лицензий. Возражения касаются затрат и усилий: потребление энергии и оборудования, перекладываемое на всех; трафик краулеров, вынуждающий небольшие форджи ставить защиты, которые заодно мешают обычным пользователям; одноразовые «вайб-кодированные» проекты, опубликованные и никогда не поддерживаемые; и нагрузку на тех, кто проводит ревью:
Maintainers are under an increased work-load due to people submitting (often well-meaning) low-effort, LLM-generated contributions that require substantial amounts of time to review.
(«Сопровождающие несут повышенную нагрузку из-за того, что люди присылают (часто из добрых побуждений) малозатратные, сгенерированные LLM вклады, которые требуют значительного времени на ревью».)
Их условия использования теперь не поощряют такие проекты — решение применяется модераторами в каждом случае отдельно, а не путём массового удаления.
Так что в обороте находятся два независимых вопроса, и проект может оказаться в любой точке этой сетки: может ли написанный машиной код вообще быть лицензирован, и способна ли экосистема выдержать объём. Debian голосует по первому вопросу и пока не пришёл к выводу. Codeberg предпринял действия по второму. Ни один из исходов не решает другой, и ответы, которые проект даёт на каждый из них, в основном не коррелируют друг с другом.
Часть, которую мы не будем притворяться решённой
Возможно, нам вообще не нужно было делать ничего из этого.
Рассмотрите три аргумента вместе. Функциональность не охраняется — так прямо постановил Суд ЕС. Чисто машинно-сгенерированный вывод может не иметь человека-автора, поэтому может не возникать нового авторского права, о котором стоит беспокоиться, и, что неловко, нашего тоже. А протокол с двумя моделями, выполненный с настоящей дисциплиной, может быть настоящей чистой комнатой, и в этом случае порт вообще не касался охраняемого выражения.
Если все три условия выполняются, некоторые из этих портов можно было бы лицензировать разрешительно с чистой совестью. Если ни одно из них не выполняется, наш консервативный выбор был просто верным. Мы не знаем, какой из вариантов верен, и мы это не проверяли. Мы не заинтересованы в том, чтобы быть тем случаем, который это решит.
Вопрос не исчезает от того, что его игнорируют. Такое портирование становится обычным делом — сейчас оно дёшево, и есть очень много неподдерживаемого кода на C, который стоит перенести туда, где его можно поддерживать. Каждый такой порт столкнётся с теми же двумя вопросами, и большинство ответит на них, просто не задавая их. Так же поступит каждый проект, который принимает патч, написанный не им, — то есть все проекты. Эти вопросы возникают независимо от того, пишете вы код или только принимаете его.