Аналитическая статья · Автор: Редакция AIPravo

Открытые веса и реестр российского ПО: права на продукт, лицензии и технологический контроль

Опубликовано 24 августа 2026 года
Обновлено 29 сентября 2026 года

Аннотация

Доступность весов модели не подтверждает ни принадлежность исключительного права российскому заявителю, ни соответствие программного продукта требованиям реестра. Вместе с тем использование открытых компонентов само по себе не дает достаточного основания для вывода о невозможности включения продукта. В статье разграничиваются параметры модели, программный код, самостоятельные компоненты, итоговый продукт и программно-аппаратный комплекс. Анализируются требования постановления Правительства РФ № 1236 в редакции от 13 августа 2026 года, включая финансовый критерий, локализацию средств разработки и поэтапную совместимость с доверенными операционными системами. Судебные акты о программном обеспечении в составе оборудования и о нейросетевой разработке используются для установления границ договорной и закупочной квалификации. Предлагается модель проверки, связывающая заявленный объект, происхождение прав, условия лицензий и фактическую возможность независимого сопровождения.

Ключевые слова: открытые веса; программное обеспечение; реестр российского ПО; открытая лицензия; исключительное право; нейросетевая модель; программно-аппаратный комплекс; национальный режим закупок.

Автор: Редакция AIPravo
Метод: Правовой анализ: сопоставление применимых нормативных положений с судебными актами, относящимися к вопросу статьи. Пределы выводов по конкретным делам раскрыты в тексте.
Источники: В тексте 8 нумерованных библиографических источников; ссылки ведут к полному списку ниже.

Содержание

1. Что требуется установить до обращения к реестру

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

Главная ошибка состоит в попытке ответить на вопрос о реестре одним признаком: модель скачивается бесплатно, сервер находится в России, разработчик зарегистрирован в России либо код размещен в открытом доступе. Каждый признак может быть значимым, но ни один не заменяет всей совокупности требований. Постановление № 1236 связывает включение с определенным программным продуктом и установленными условиями, а не с общим патриотическим или технологическим описанием проекта.^[1]

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

Предлагаемый подход состоит в проверке четырех связей: между названием продукта и его составом; между составом и правами заявителя; между лицензиями и фактическими операциями; между заявленной самостоятельностью и доступными средствами сопровождения. Реестровый статус при этом необходимо отличать от государственной регистрации программы как объекта авторского права и от условий допуска конкретной закупки.^{[1, 2, 4]}

2. Открытые веса — не синоним открытого исходного кода

2.1. Техническая доступность и правовой объем разрешения

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

В Open Source AI Definition 1.0 организация Open Source Initiative связывает открытость ИИ не только с параметрами, но также с кодом и достаточной информацией о данных, необходимыми для изучения и изменения системы. Это не обязательно означает передачу всех исходных обучающих данных: определение отдельно рассматривает сведения о них и способы доступа. Оно полезно для различения технических обещаний, но не является российским законом и не решает вопрос о включении в реестр.^[3]

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

2.2. Код, параметры и корпус не образуют одно право

Программа для ЭВМ охраняется по правилам статьи 1261 ГК РФ; ее модификация, использование и передача требуют учета соответствующих прав. Параметры модели, обучающий корпус, код обучения, программа исполнения и документация могут относиться к разным объектам и иметь разные основания охраны. Нельзя объявлять все эти элементы одним произведением только потому, что они передаются одним архивом.^[2]

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

Не следует и делать обратный вывод: раз правовой статус параметров обсуждается, условия их предоставления заведомо не имеют значения. Они могут действовать в договорных отношениях и сопровождать передачу иных охраняемых материалов. Юридическая проверка должна установить применимость и содержание конкретных условий, а не выбирать универсальный ответ для всех моделей.

2.3. Лицензия должна соответствовать действительной поставке

Разрешение на локальное использование компонента не обязательно охватывает передачу клиентам измененной версии. Возможность распространять программу не тождественна праву удалить требуемые уведомления или предоставить заказчику исключительное право на чужой исходный код. Для каждого существенного компонента необходимо соотнести предоставленные правомочия с планируемыми операциями.^{[2, ст. 1235, 1286.1]}

Например, Apache License 2.0 содержит условия распространения, сохранения определенных уведомлений и обозначения изменений. Это достаточно широкое разрешение, но не отсутствие обязанностей. Условия одной известной лицензии также нельзя автоматически переносить на модель, распространяемую под собственным текстом разрешения, даже если обе названы разработчиками открытыми.^[7]

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

3. Исключительное право на продукт и права на компоненты

3.1. Что требует постановление № 1236

Подпункт «а» пункта 5 Правил формирования и ведения реестра устанавливает требования к принадлежности исключительного права на программное обеспечение на территории всего мира и на весь срок его действия определенным российским субъектам. Для соответствующих российских коммерческих организаций предусмотрены условия структуры контроля. Наличие российской регистрации юридического лица без проверки установленных требований не дает полного ответа.^[1]

Одновременно Правила предусматривают сведения об открытой лицензии и безвозмездном использовании. Следовательно, сама модель открытого лицензирования не является чуждой реестру. Но это не отменяет требования к правам на заявленный объект и не означает, что любой пользователь чужого открытого продукта становится его исключительным правообладателем.^{[1, п. 4, 5]}

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

3.2. Почему недостаточен подсчет «российских строк»

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

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

Особенно уязвимо расхождение между широкой рекламной формулой и узким реальным правом. Компания может обладать исключительным правом на собственный интерфейс, но продавать решение как «собственную базовую модель». Для реестра и договора необходимо описывать объект без такого расширения. Иначе документы подтверждают одно, а клиенту и уполномоченному органу предлагается другое.

3.3. Работники, подрядчики и прежние версии

Цепочка прав на собственную часть продукта также требует проверки. Для служебных программ и результатов, созданных по заказу либо при выполнении иных договоров, ГК РФ предусматривает разные правила. Универсальное условие «разработчик передает все права» не всегда объясняет, кем именно создан каждый существенный результат и какие права у передающей стороны возникли.^{[2, ст. 1295–1297]}

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

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

4. Технологическая самостоятельность — самостоятельное направление проверки

4.1. Возможность сопровождать, а не только запускать

Правила № 1236 содержат требования, связанные с отсутствием принудительного иностранного управления и обновления, возможностью сопровождения и модернизации определенными российскими субъектами, размещением исходного кода и технических средств разработки, а также средств, обеспечивающих лицензирование, активацию и распространение. Их нельзя свести к географическому расположению сервера, на котором демонстрируется продукт.^{[1, подп. «ж»–«к» п. 5]}

Программа может запускаться в России, но зависеть от недоступного заявителю внешнего управления или необходимого иностранного сервиса. И наоборот, иностранное происхождение правомерно используемого компонента не отвечает само по себе на вопрос о возможности независимого локального сопровождения. Проверять следует фактические зависимости и установленные Правилами требования.

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

4.2. Совместимость с доверенными операционными системами

Подпункт «м» пункта 5 предусматривает совместимость не менее чем с двумя доверенными операционными системами с установленными исключениями. Однако введение требования поэтапно: для офисного ПО — с 1 сентября 2026 года, для программ обслуживания — с 1 января 2027 года, прикладного ПО — с 1 июня 2027 года, промышленного ПО — с 1 января 2028 года. На дату настоящей статьи нельзя представлять все эти сроки как уже наступившие.^[1]

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

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

4.3. Обычная программа и программно-аппаратный комплекс

Правила содержат специальные требования к программно-аппаратным комплексам. В том числе выделены отдельные условия для предусмотренной ими категории комплексов, предназначенных для генеративных моделей. Нельзя переносить эти специальные условия на любой программный продукт, в котором используется ИИ, только по совпадению терминологии.^{[1, п. 5.1]}

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

5. Финансовый критерий: что означает граница в 30 процентов

Подпункт «в» пункта 5 Правил устанавливает специальное соотношение платежей в пользу указанных в норме иностранных лиц и выручки от предоставления прав использования программного обеспечения за предусмотренный период. Соответствующие платежи должны составлять менее 30 процентов. Это не критерий доли иностранного кода и не общая доля всех зарубежных расходов организации.^[1]

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

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

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

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

6. Реестр и закупка: два режима, которые нельзя объединять

6.1. Изменение нормативной рамки

Постановление № 1236 исторически связывалось с запретом допуска иностранного программного обеспечения к определенным закупкам. Однако прежние положения о таком запрете утратили силу с 1 января 2025 года в связи с постановлением Правительства РФ от 23 декабря 2024 года № 1875. Правила формирования и ведения реестров при этом продолжают действовать в измененном нормативном контексте.^{[1, 4]}

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

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

6.2. Дело № А74-5836/2022: значение фактического предмета поставки

В постановлении Третьего арбитражного апелляционного суда от 9 марта 2023 года по делу № А74-5836/2022 рассматривался спор по закупке оборудования для образовательных центров. Антимонопольный орган считал необходимым применение действовавшего тогда запрета в отношении иностранного программного обеспечения. Суд учитывал, что программа являлась функционально связанной частью поставляемого робототехнического оборудования, а не самостоятельным предметом закупки.^[5]

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

Этот акт нельзя использовать как универсальное разрешение обходить действующие ограничения включением программы в комплект оборудования. Он относится к определенному предмету и нормативной рамке 2022–2023 годов. После изменения правил закупок требуется новый анализ. Сохраняет методологическое значение лишь необходимость исследовать фактический объект, а не ограничиваться названием позиции.

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

7. Договор на нейросетевую разработку: что подтверждает судебный акт

7.1. Дело № А46-8181/2024

Постановление Суда по интеллектуальным правам от 16 апреля 2025 года № С01-347/2025 по делу № А46-8181/2024 касается спора об оплате разработки нейросетевого программного продукта. В судебном акте отражено развернутое техническое задание: программное решение, работа с наборами данных, обучение, документация, требования к компонентам и их лицензиям, включая упоминание GPL и Apache.^[6]

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

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

7.2. Почему условия о лицензиях должны стать частью приемки

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

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

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

7.3. Заверение о возможности включения не равно решению о включении

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

Поэтому существенны содержание заверения, исходные сведения и распределение последствий отказа. Если отказ вызван известным исполнителю ограничением компонента, ситуация отличается от изменения регулирования после завершения работ или непредоставления заказчиком необходимых корпоративных документов. Эти различия целесообразно отразить заранее, а не объединять все причины формулой «реестровый риск несет другая сторона».^{[8, ст. 431.2]}

8. Предлагаемая последовательность правовой проверки

8.1. Определить заявленный объект

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

В отношении модели отдельно указываются параметры, код исполнения и иные материалы, реально входящие в поставку. Не следует приписывать заявителю права на полный обучающий корпус только потому, что он получил обученные параметры. Равным образом наличие собственной базы знаний не доказывает авторство базовой модели. Разграничение не умаляет ценности продукта; оно делает правовую позицию точной.

8.2. Сопоставить объект с основаниями прав

Для собственной части устанавливается цепочка приобретения прав, для внешних компонентов — применимые разрешения и ограничения. Далее проверяется соответствие этой структуры тому праву на программное обеспечение, которое заявляется по Правилам № 1236. Нельзя компенсировать пробел в цепочке прав письмом разработчика без анализа его полномочий.

Здесь полезно раздельно фиксировать установленные обстоятельства и спорные вопросы квалификации. Например, наличие договора и текста лицензии — проверяемый факт. Вывод о достаточности этих документов для определенного правомочия требует юридической оценки. Их объединение в одну отметку «права есть» скрывает предмет возможного возражения.

8.3. Проверить фактическую самостоятельность

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

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

8.4. Применить финансовые и специальные требования

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

Завершающий результат проверки — не рекламный вывод «полностью российское», а обоснование соответствия конкретного продукта конкретным требованиям с обозначением подтверждающих документов и остающихся вопросов. Именно такое обоснование пригодно для исправления дефектов и последующего рассмотрения; общий положительный эпитет ничего не сообщает о его основаниях.

9. Возражения: не ведет ли такой подход к запрету открытых технологий

Наиболее сильное возражение состоит в том, что требование установить права на весь продукт может быть истолковано как необходимость самостоятельно переписать каждый компонент. Такое толкование нельзя выводить только из слова «исключительное», игнорируя структуру программного продукта и содержащиеся в Правилах положения об открытых лицензиях. Однако и противоположный вывод о безусловной достаточности любой открытой лицензии также не следует из регулирования.^{[1, 2]}

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

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

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

Заключение

Открытые веса не подтверждают реестровое соответствие автоматически, но и не образуют самостоятельного универсального препятствия. Ключевой вопрос — какой продукт заявляется, какими правами располагает заявитель, какие условия сопровождают компоненты и способен ли он выполнять предусмотренные требования к сопровождению и контролю.

Редакция Правил № 1236 требует аккуратного учета действующих и будущих условий. Финансовую границу нельзя превращать в процент иностранного кода; поэтапную совместимость — объявлять уже обязательной для всех классов; специальные требования к программно-аппаратным комплексам — переносить на любой ИИ-продукт. Реестровую проверку необходимо отделять от национального режима конкретной закупки.

Рассмотренные судебные акты показывают ценность точного определения предмета поставки и договорного результата. Они не дают готового разрешения для всех моделей с открытыми весами. Практически убедительная позиция строится на согласованности технического состава, правовых оснований и фактической самостоятельности — а не на одном слове «открытый» или «российский» в описании продукта.

Источники

Судебные акты из СПС «КонсультантПлюс» указаны с полными реквизитами. Доступ к отдельным текстам может требовать подписки.

История редакции

24 августа 2026 года — первая публикация.
21 сентября 2026 года — Существенная редакционная переработка; исходная тема сохранена.
29 сентября 2026 года — Добавлены сведения об издании; текст исследования не менялся.