Комплексный анализ правовых, технических и экономических рисков использования LibreOffice
в качестве основы для российского офисного ПО
П. 5(а)
Исключительные права нужны на продукт целиком
Ст. 1260
Составное произведение не даёт прав на ядро LibreOffice
1,47 МБ
На экспертизу подавали загрузчик, а не офисный пакет
OS-зависим
Состав «Свободного офиса» меняется под ALT и Astra
Правовые риски и лицензионные коллизии
Продукты на основе LibreOffice сталкиваются с фундаментальными противоречиями между
требованиями российского законодательства и условиями open-source лицензий.
1-2
Проблемы с правами и лицензиями
Риск 1: Неподтверждённость исключительных прав российского правообладателя. Риск 2: Использование LibreOffice как ключевого компонента под копилефт-лицензией.
1. Неподтверждённость исключительных прав
Требование п. 5(а) Постановления № 1236: наличие у российского правообладателя исключительных прав на программный продукт в целом.
Отсутствует надлежащее оформление прав на собственные доработки
Коллизии с вкладом внешних контрибьюторов
Реальный объём оригинального кода не позволяет квалифицировать продукт как самостоятельный объект [довод политики, не правовой нормы: закон не устанавливает порогового % кода; юридически значимо только отсутствие исключительных прав на весь продукт по п.5(а) № 1236]
2. Ключевой компонент под копилефт
Методические рекомендации ЦКИТ: ключевые компоненты не должны распространяться на условиях GPL, MPL и аналогичных лицензий.
Риск: Невозможность подтвердить выполнение требований п. 5(а) Правил
о наличии прав, достаточных для распоряжения всем продуктом.
3-4
Нарушения лицензий и условий
Риск 3: Нарушение или невозможность подтверждения соблюдения условий MPL 2.0 / LGPL v3. Риск 4: Наличие в составе иных компонентов под жёсткими копилефт-лицензиями (GPLv3, AGPL).
LGPL v3 требует обеспечения возможности замены библиотеки и доступа к объектному коду для повторной компоновки.
4. Компоненты под GPLv3/AGPL
Методические рекомендации ЦКИТ разграничивают пермиссивные лицензии (MIT, BSD, Apache 2.0) и рисковое использование сильного copyleft (GPLv3, AGPL).
Выявление в SBOM библиотек под GPLv3/AGPL, от которых продукт функционально зависит, существенно увеличивает вероятность отказа.
Отсутствие в дистрибутиве полного набора уведомлений и механизмов
получения исходников позволяет квалифицировать использование как неправомерное.
5-6
SBOM и требования регулятора
Риск 5: Недостаточный объём и качество раскрытия сведений о заимствованных компонентах (SBOM). Риск 6: Несоответствие требованиям к офисному ПО по совместимости с доверенными ОС (постановление № 1937, вступило в силу 01.09.2026).
Формирования перечня всех сторонних компонентов с указанием правообладателя и лицензии
Представления архитектурного описания, показывающего независимость российского кода
Документального подтверждения правомерности использования каждого компонента
Отсутствие полноценных SBOM (CycloneDX/SPDX) повышает риск негативной оценки со стороны Экспертного совета.
6. Несоответствие постановлению № 1937 (совместимость с доверенными ОС)
Постановление Правительства РФ от 28.11.2025 № 1937 (вступило в силу с 01.09.2026) вводит п.5(м): офисное ПО обязано подтвердить совместимость с не менее чем двумя российскими ОС из перечня доверенных. Примечание: ПП № 325 от 23.03.2017, на которое ранее ссылались аналитики, утратило силу с 01.03.2026 и в актуальной аргументации не используется.
Совместимость с двумя и более доверенными российскими ОС (из перечня, утверждённого Минцифры)
Подтверждение совместимости — через испытания в аттестованных центрах тестирования ПО (ЦТ по ПП № 1931)
LibreOffice-based продукты лишены самостоятельного контроля над ядром совместимости: патчи для российских ОС формируются TDF и/или вендорами ОС, а не российским правообладателем
Неспособность гарантировать совместимость с доверенными ОС в установленные сроки (с 01.09.2026) является самостоятельным основанием для отказа во включении в реестр или для инициирования исключения.
7-8
Заимствование и коллизии требований
Риск 7: Наличие признаков «недобросовестного» заимствования LibreOffice-кода. Риск 8: Объективная невозможность соблюсти одновременно требования MPL/LGPL и требования российского регуляторного режима.
7. Недобросовестное заимствование
В практике Минцифры и АНО ЦКИТ (дело AlterOffice) обсуждались случаи, когда:
Форк LibreOffice позиционировался как полностью оригинальный российский продукт
Не соблюдались требования MPL 2.0 по уведомлениям и раскрытию исходного кода
Архитектура и маркетинговое позиционирование вводили в заблуждение относительно объёма оригинальной разработки
Выявление аналогичных признаков повышает риск отрицательного заключения Экспертного совета.
8. Несогласуемость требований
Совокупность ограничений MPL/LGPL и требований российского режима может привести к тому, что юридически «безупречная» конфигурация продукта в принципе не достижима:
MPL: обязательное открытие модификаций, недопустимость дополнительных ограничений
Российский режим: необходимость концентрации исключительных прав у российского юридического лица, ограничение доли иностранного участия
Установление такой объективной несогласуемости даёт основание для вывода о невозможности включения LibreOffice-based решения в реестр без существенной переработки архитектуры и лицензионной модели.
9
Ст. 1260 ГК РФ: самоквалификация как «составное произведение»
Критический аргумент: Заявитель сам называет «Свободный офис» «программным комплексом (составным произведением)». Это имеет прямые правовые последствия по ст. 1260 ГК РФ.
«Составителю сборника... принадлежат авторские права на осуществлённые ими подбор или расположение материалов (составительство)» — то есть не на сами компоненты.
«Составитель не вправе запрещать авторам произведений, включённых в составное произведение, использовать эти произведения независимо.» Исключительные права на LibreOffice остаются у The Document Foundation.
КС признал неконституционным отказ в защите прав автора составного произведения только на том основании, что он использовал компоненты без разрешения. Это означает: права Базальт СПО на Surguch, CSP-плагин и SRPM-обёртки существуют и защищены — КС это подтверждает.
Важно: КС защищает права автора на его собственный вклад (подбор/расположение), но не передаёт исключительных прав на чужие компоненты. Права на LibreOffice по-прежнему принадлежат TDF — постановление КС этого не меняет. Аргумент сохраняет силу, КС лишь уточняет его: проблема не в отсутствии прав как таковых, а в том, что права существуют только на собственный вклад, но не на ядро продукта (LibreOffice).
✓ Постановление КС поддерживает альтернативный путь: Surguch + LibreOffice-plugin-altcsp могут быть включены в реестр как самостоятельные продукты — именно на них у заявителя есть полные исключительные права.
Практические последствия для реестра:
П. 5(а) Постановления № 1236 требует исключительных прав на продукт в целом - «составительство» этому не соответствует
MPL 2.0 предоставляет право использовать, но не концентрировать исключительные права на LibreOffice
Заявитель сам подтвердил, что его права ограничены «набором компонентов», а не компонентами как таковыми
Логичное следствие: в реестр следует вносить только те компоненты, на которые у заявителя реально есть права - Surguch и LibreOffice-plugin-altcsp
Вывод: Квалификация продукта как «составного произведения» определяет точный объём прав: заявитель имеет исключительные права на собственный вклад (Surguch, CSP-плагин, SRPM-спеки), но не на LibreOffice — ядро продукта. П. 5(а) Постановления № 1236 требует исключительных прав на весь продукт в целом. При открытом MPL-2.0-ядре это требование для «Свободного офиса» как офисного пакета неисполнимо. Логичное и законное следствие — регистрация исключительно собственных компонентов: Surguch и LibreOffice-plugin-altcsp.
10
ГОСТ 19.101-2024: «комплекс программ» - п.5(а) применяется к каждому компоненту
Новый аргумент (эксперт Журавлев, 2025): Базальт квалифицирует продукт как «программный комплекс» - но по ГОСТ 19.101-2024 «Свободный офис» является «комплексом программ». Различие фундаментальное: п. 5(а) Постановления № 1236 применяется к каждому компоненту по отдельности.
ГОСТ 19.101-2024 (вступил в силу 30.01.2025 - актуален для заявки 346971):
«Программный комплекс»
Единая программа с взаимосвязанными компонентами, совместно выполняющими одну задачу. Права на весь комплекс - достаточное основание.
«Комплекс программ»
Набор самостоятельных программ, решающих разные задачи. Права необходимы на каждый компонент отдельно.
DavMail (Exchange-шлюз), Zenity (UI-диалоги), LibreOffice (офис), Surguch (PDF/ЭП), Thunderbird (почта), Chromium (браузер) - самостоятельные программы с разными функциями. По ГОСТ - это «комплекс программ».
Следствие для п. 5(а) Постановления № 1236:
Если продукт - «комплекс программ», то п. 5(а) требует исключительных прав на каждый из компонентов. У заявителя нет прав на:
LibreOffice - права у TDF (Германия)
Thunderbird - права у Mozilla Foundation (США)
Chromium - права у Google (США)
DavMail - права у сообщества (Франция, GPL-2.0+)
Zenity - права у GNOME Project
Отсутствие прав хотя бы на один компонент - нарушение условия для всего «комплекса программ».
Прецедент: Ankey SIEM (Постановление АС Московского округа от 20.09.2018 № Ф05-15194/2018 по делу № А40-233720/17)
Арбитражный суд Московского округа применил п. 5(а) Постановления № 1236 к составному произведению и отказал в регистрации продукта, в состав которого входил иностранный компонент без надлежащих прав. Суд прямо указал: наличие хотя бы одного такого компонента - самостоятельное основание для отказа.
⚠️ Применимость к «Свободному офису»: прецедент касается составных произведений - именно такую квалификацию сам Базальт дал продукту в EULA п.2.1 и в заявке 346971.
⚠️ Степень уверенности в аргументе через ГОСТ: умеренная - прецедентов применения ГОСТ 19.101 экспертным советом реестра пока не зафиксировано. Прецедент Ankey SIEM через ст. 1260 ГК РФ - более твёрдая опора.
11
DavMail: обязательные обращения к github.com при работе - нарушение пп. 5(ж) и 5(и)
DavMail (компонент «Свободного офиса», шлюз Exchange) при запуске автоматически обращается к github.com - отображает актуальную версию и предлагает скачать обновление с иностранного ресурса. Два независимых эксперта (Закоржевский и Щеглов) зафиксировали это поведение. Нарушения: пп. 5(ж) и 5(и) Постановления № 1236.
Обязательные обращения к зарубежным серверам при нормальной работе ПО не допускаются. Проверка версии на github.com при каждом запуске - именно такое обращение.
Источник: два независимых эксперта
Закоржевский (2025): «DavMail при запуске обращается к github.com для отображения актуальной версии и предлагает скачать обновление». Щеглов (заявка 346971): «DavMail получает обновления с GitHub» (со ссылкой на п. 5(и)). Независимое совпадение показаний двух экспертов.
⚠️ Требует верификации логом
Для максимальной убедительности - скриншот UI DavMail с запросом обновления или захват сетевого трафика (tcpdump host api.github.com) при запуске. В текущем виде аргумент опирается на показания экспертов.
Вывод: DavMail - компонент, поставляемый в составе «Свободного офиса», - при нормальной работе устанавливает соединение с иностранным сервером (github.com). Это нарушает п. 5(и) (обязательные обращения к зарубежным ресурсам) и п. 5(ж) (обновления только с зарубежного источника).
«Нужно воздержаться от включения в реестр спорных позиций — ведь это реестр
именно российского ПО, и совершенно точно не "клонов" иностранного ПО
или части их ключевых компонентов.»
— Николай Никифоров, Председатель Экспертного совета при Минкомсвязи (2016)
Источник: digital.gov.ru, март 2016
Актуальная практика регулятора (2024-2025)
Позиция 2016 года подтверждается текущей практикой Минцифры и АНО ЦКИТ.
Дело AlterOffice (2019-2020) показало готовность регулятора исключать LibreOffice-based продукты за нарушение условий MPL 2.0 и несоответствие Постановлению № 1236. Важная оговорка: продукт был возвращён в реестр по решению суда — на процедурных основаниях (Минкомсвязи нарушило срок предоставления ответа заявителю), а не потому что был признан соответствующим требованиям по существу.
Экспертный совет продолжает требовать прозрачности об использовании open-source компонентов
Недекларирование иностранного кода рассматривается как основание для отказа
Вывод: Позиция регулятора остаётся неизменной — реестр предназначен для
российских разработок, а не для «клонов» иностранного ПО.
Риски информационной безопасности
ИБ-риски open-source компонентов выходят на первый план для государственного сектора
и корпоративных заказчиков. По данным официальных бюллетеней безопасности LibreOffice,
регулярно обнаруживаются критические уязвимости.
Структурная зависимость от upstream для закрытия CVE
Примеры уязвимостей 2024-2025 (CVE-2024-12425,
CVE-2024-12426,
CVE-2025-1080) закрыты upstream в версиях 24.8.4.2/25.2.1 (фев-март 2025) — и в заявляемой версии 25.8.3.2 уже исправлены. Однако поток новых CVE непрерывен: Базальт не контролирует ядро и зависит от TDF для каждого патча.
1
Наследование критических уязвимостей (CVE)
Кодовая база LibreOffice — миллионы строк на C/C++ с регулярно обнаруживаемыми уязвимостями.
Примеры уязвимостей (закрыты upstream в версиях 24.8.4.2/25.2.1):
CVE-2024-12425 — Arbitrary .ttf file writes via path traversal
⚠️ Уточнение: перечисленные CVE закрыты в версии 25.8.3.2 (заявка 346971). Подробный анализ эксплуатации (Codean Labs, фев. 2025) иллюстрирует тип угрозы — но не текущий статус.
Ключевой риск не в конкретных CVE, а в структурной зависимости: Базальт не контролирует ядро и полностью зависит от TDF для каждого патча. При геополитической изоляции этот канал может быть прерван.
2
Атаки на цепочку поставок
Теоретический риск внедрения нежелательного кода через иностранных контрибьюторов LibreOffice. [Умеренный по доказательности]
Примечание о доказательности:
Данный аргумент носит теоретический характер. Конкретных задокументированных случаев умышленного внедрения вредоносного кода в LibreOffice не зафиксировано. Аргумент применим к любому открытому иностранному ПО и не является специфичным для данного заявителя.
Релевантные регуляторные основания:
ФСТЭК: методика оценки угроз безопасности (2021) относит внешние цепочки поставок к источникам угроз
Для КИИ требуется проверка ПО на НДВ - 45 млн строк кода LibreOffice делают такую проверку практически нереализуемой
Отсутствие возможности полного аудита = процедурное несоответствие требованиям к защищённым системам
Более сильный аргумент: невозможность независимого аудита кода в условиях нынешней геополитики.
3
«Окно уязвимости» (Patch Lag)
Разрыв во времени между выпуском патча и его доставкой пользователям.
LibreOffice включает встроенный Python и множество сторонних библиотек с собственными уязвимостями.
Проблемы комплексных зависимостей:
Встроенный Python наследует системные разрешения (TCC bypass)
Сторонние библиотеки (например, Log4j в прошлом) добавляют дополнительные векторы атак
Сложность аудита всей цепочки зависимостей
Каждая сторонняя библиотека — потенциальная точка входа для атаки.
Оценка риска исключения из реестра
ВЫСОКИЙ
ИБ-риски с большой долей вероятности станут причиной исключения
Ужесточение требований
Минцифры и ФСТЭК внедряют требования по безопасной разработке (РБПО)
Запрет на зарубежную инфраструктуру
Hardcoded обращения к зарубежным серверам нарушают требования технологической независимости
Требования к КИИ
Продукт должен проходить сертификацию ФСТЭК
Экономические и этические аспекты
Использование LibreOffice создаёт несправедливое конкурентное преимущество
и препятствует развитию отечественных технологий.
1
Отток финансовых ресурсов
Компании монетизируют чужой интеллектуальный труд, отбирая долю рынка у разработчиков собственных решений.
3,5 трлн ₽
Инвестиции в инновации (2023)
291,4 млрд ₽
Затраты на разработку ПО
Подобные инвестиции оправданы только при создании собственных технологий,
а не при коммерциализации иностранного open-source.
2
Недобросовестная конкуренция
Использование готового иностранного кода создаёт несправедливое преимущество над компаниями с собственными разработками.
Компании с оригинальными разработками:
МойОфис — разработка «с нуля», сертификация ФСТЭК, ФСБ, МО РФ
Р7 офис — собственное ядро, внедрение в «Россети», ДГК
В 2024 году Р7 в 1,6 раза превзошёл МойОфис по выручке —
коммерческий успех оригинальных разработок.
3
Нецелевое использование бюджета
Использование бюджетных средств для коммерциализации иностранного кода вместо создания собственных технологий.
8,3 млрд ₽
Третья волна особо значимых IT-проектов (2025)
Использование этих средств для коммерциализации иностранного open-source
вместо создания собственных технологий является этически сомнительной практикой.
4
Ловушка избыточной фрагментации
Проблема критической массы: 10 игроков не смогут инвестировать в R&D достаточно, чтобы догнать Microsoft Office.
В нишах, где важна сетевая связность:
Эффект масштаба критичен
Совместимость — вопрос нацбезопасности
Ресурсы (разработчики) ограничены
Стратегия «пусть расцветают сто цветов» ведёт к поражению.
5
Репутационные риски для заказчиков
Включение LibreOffice-based решений в реестр создаёт прецедент, заниженный технологический порог для всего рынка отечественного ПО.
Системный эффект:
Если LibreOffice-based продукт получает статус «российского ПО», создаётся прецедент: любой интегратор может упаковать иностранный open-source в RPM-пакет, добавить 2 утилиты и претендовать на место в реестре. Это девальвирует реестр как инструмент реального импортозамещения.
Индикатор проблемы:
Конкуренты с оригинальными разработками (МойОфис, Р7) инвестировали годы в написание собственного кода
Стоимость «входа» через упаковку LibreOffice - несопоставимо ниже
При равном статусе в реестре конкурентные позиции оригинальных разработчиков искусственно занижаются
Это экономический аргумент в пользу более строгого применения критериев реестра, а не фактическое основание для отказа в конкретном случае.
6
Скрытые издержки поддержки
Экономия на лицензиях компенсируется затратами на интеграцию, обучение и доработку.
Факторы, увеличивающие TCO:
Несовместимость с макросами MS Office требует переработки документов
Необходимость обучения пользователей новому интерфейсу
Затраты на доработку под специфические требования заказчика
Риски простоя из-за критических уязвимостей
Исследования показывают, что полная стоимость владения open-source
решениями часто сопоставима с коммерческими продуктами.
Угрозы цифровому суверенитету
Использование LibreOffice противоречит целям государственной политики импортозамещения
и создаёт препятствия для развития суверенных технологий.
«Цифровой суверенитет означает, что государству не могут диктовать условия
под угрозой отключения от цифровых сервисов.»
— Сергей Кириенко, Первый заместитель руководителя Администрации Президента РФ
Источник: interfax.ru, сентябрь 2025
1
Отсутствие контроля над кодом
Российские разработчики не контролируют базовую архитектуру и ключевые компоненты LibreOffice.
Решения о развитии проекта принимаются зарубежным сообществом
Ключевой функционал и интеллектуальные права принадлежат иностранной организации.
2
Геополитические риски
В 2022 году The Document Foundation приостановила членство аффилированной с Astra Linux компании RusBITech в Консультативном совете по политическим причинам.
Прецедент 2022 года (точная квалификация):
TDF приостановила членство RusBITech (материнская компания Astra Linux) в Advisory Board (Консультативном совете). Это управленческий орган, а не разработческая инфраструктура.
Официальное заявление TDF —
28 февраля 2022 года. Причина: «apparent involvement with the Russian Federation's military complex».
Важно: Техническая возможность делать коммиты не была закрыта (это открытый проект). Однако прецедент показывает: иностранная НКО может в любой момент ограничить участие российских организаций в управлении проектом, от ядра которого зависит «Свободный офис».
3
Замедление развития компетенций
Вместо формирования экспертизы компании получают готовую архитектуру.
Лишает мотивации к глубоким исследованиям
Создаёт технологическую зависимость
Препятствует инновациям
Революционные решения создаются «с чистого листа», а не при модификации существующих продуктов.
5
Риск «заморозки» кода из-за санкций
Ужесточение санкций может привести к блокировке доступа к обновлениям LibreOffice для российских пользователей.
Сценарии развития событий:
Блокировка доступа к репозиториям исходного кода
Запрет на скачивание бинарных сборок с официального сайта
Исключение российских разработчиков из процесса code review
Введение санкций против The Document Foundation
Прецедент с Astra Linux (2022) показал, что политические решения
могут быть приняты в одностороннем порядке.
4
Требования к совместимости с доверенными ОС (ПП № 1937)
С 01.09.2026 офисное ПО обязано подтвердить совместимость с не менее чем двумя российскими ОС из перечня доверенных (ПП № 1937).
Подтверждённая совместимость с не менее чем двумя российскими ОС из перечня доверенных
Совместимость подтверждается испытаниями в аттестованных центрах тестирования ПО (ЦТ) согласно ПП № 1931
Требование контроля над функциональным ядром: LibreOffice-based решения не могут самостоятельно гарантировать совместимость - она определяется TDF и/или вендорами ОС
Это требование принципиально отличается от утратившего силу ПП № 325: фокус сместился с функциональных требований к ПО на требование совместимости с суверенной инфраструктурой ОС.
6
Реестр доверенного ПО как закупочный барьер (ПП № 1931)
С 01.03.2026 заказчики обязаны отдавать приоритет ПО из перечня доверенного. LibreOffice-based продукты лишены практической возможности получить этот статус.
Постановление Правительства РФ от 28.11.2025 № 1931 вступило в силу 01.03.2026 и создаёт перечень доверенного ПО с обязательным приоритетом при государственных закупках. Ключевые последствия для LibreOffice-based продуктов:
Закупочный приоритет: заказчики обязаны приобретать ПО из перечня доверенного в первую очередь - продукты вне перечня конкурентно уязвимы
Архитектурный барьер: для включения в перечень требуется прохождение испытаний в аттестованных центрах тестирования (ЦТ); LibreOffice-based продукты не могут подтвердить независимость функционального ядра - ключевое условие аттестации
Практическая блокировка: по состоянию на апрель 2026 г. ни один ЦТ не аттестован и не функционирует - инфраструктура не сформирована, путь к статусу фактически закрыт для всех претендентов, включая LibreOffice-based решения
Даже при формировании инфраструктуры ЦТ архитектура LibreOffice-based продуктов делает получение статуса «доверенного» практически невозможным: TDF контролирует функциональное ядро, а не российский правообладатель.
•Маркетинг вводил в заблуждение об объёме оригинальной разработки
Выводы из кейса
•Использование LibreOffice не исключает включения в реестр при полном соблюдении условий
•Необходима прозрачность и правомерность использования кода
•Пробелы в OSS-compliance дают формальные основания для отказа
•Повторение ошибок AlterOffice = высокий риск отказа
Критическое предупреждение
Для LibreOffice-based продукта, воспроизводящего модель AlterOffice на новом витке,
риски отказа объективно высоки при повторении ошибок по заметанию OSS-следа
и неполному выполнению MPL/LGPL.
Международный опыт использования LibreOffice
Анализ подходов различных стран к использованию open-source ПО и LibreOffice в государственном секторе.
Ключевой тренд — стремление к цифровому суверенитету и независимости от проприетарных вендоров.
«Цифровой суверенитет — это способность государства независимо управлять своими цифровыми активами
и избавиться от vendor lock-in.»
— Общая позиция европейских правительств, 2024-2025
Источник: 2-data.com, анализ трендов цифрового суверенитета ЕС
🇩🇪
Германия
Земля Шлезвиг-Гольштейн: миграция 30 000 ПК на LibreOffice и Linux ради цифрового суверенитета.
Вывод для России: ЕС видит в LibreOffice инструмент суверенитета,
но для России использование иностранного open-source создаёт обратную проблему —
зависимость от западной инфраструктуры.
🇪🇺
Европейская Комиссия
Стратегия open source: равноправие при закупках, снижение зависимости от проприетарных вендоров.
Равноправие open source при государственных закупках
Поощрение совместного использования и повторного использования ПО
Инвестиции в европейские open-source проекты
Примечание: ЕК продвигает open source как инструмент
европейского суверенитета, но при этом сама LibreOffice критикует ЕК
за недостаточную поддержку в пользу проприетарных решений.
🇬🇧
Великобритания
Обязательный стандарт ODF 1.2 и признание LibreOffice как совместимого инструмента.
Правительство UK обязало использовать формат ODF 1.2 для обеспечения совместимости и безопасности.
Позиция правительства:
ODF — обязательный стандарт для госорганов
LibreOffice указан как совместимый инструмент
С 2014 года планы перехода на open source (реализованы частично)
Контекст: UK следует принципу «открытые стандарты важнее открытого кода» —
формат ODF обязателен, но конкретное ПО может быть любым.
🇫🇷
Франция
Сильная политика в пользу свободного ПО. Государственные учреждения активно используют LibreOffice.
Франция имеет одну из самых продвинутых политик в области open source в ЕС. Государственные учреждения активно используют LibreOffice.
Особенности подхода:
Приоритет open source в госзакупках
Развитие собственных open-source решений (например, XWiki)
Финансирование развития LibreOffice через французские компании
Ирония: При всей поддержке open source, в 2025 году Лион
отказался от OnlyOffice (российского продукта) именно из-за вопросов происхождения ПО.
🇨🇳
Китай
Импортозамещение: замена иностранного ПО на отечественные Linux и офисные пакеты до 2027 года.
Использование open source (LibreOffice) только как временная мера
Цель — полная технологическая независимость
Параллель с Россией: Китай, как и Россия, стремится к суверенитету,
но при этом использует LibreOffice только как промежуточное решение,
активно развивая собственные альтернативы.
🇮🇳
Индия
Национальная политика open source: предпочтение свободному ПО при равных условиях.
Активное использование LibreOffice в госучреждениях
Развитие собственных open-source проектов
Сотрудничество с международным сообществом
Отличие от России: Индия видит в open source возможность
для развития собственной индустрии без геополитических ограничений,
в отличие от санкционного контекста России.
Сравнительный анализ подходов
Западный подход (ЕС, Германия, Франция)
• LibreOffice как инструмент цифрового суверенитета
• Защита от доминирования Microsoft
• Поддержка европейских open-source проектов
• Никаких запретов на использование — только поощрение
Российский контекст
• LibreOffice — иностранный продукт (Германия/ЕС)
• Зависимость от западной инфраструктуры разработки
• Санкционные риски (прецедент Astra Linux)
• Необходимость собственных разработок (как у Китая)
Ключевой вывод: В то время как ЕС использует LibreOffice для защиты от американского доминирования,
для России использование того же LibreOffice создаёт зависимость от западной экосистемы.
Параллель с Китаем: обе страны стремятся к технологическому суверенитету,
но Китай активно развивает собственные альтернативы, а не полагается на западный open source.
Аргументация «Свободного офиса»: анализ и опровержение
Разбор заявлений разработчиков «Свободного офиса» с кликабельными ссылками на первоисточники
и выявление слабых мест в их аргументации.
Элевейтор-тест: 5 шагов к отказу
Логическая цепочка, опирающаяся исключительно на документы самого заявителя
1
Ядро продукта - в иностранном репозитории
LibreOffice (~45 млн строк кода) разрабатывается исключительно в gerrit.libreoffice.org, принадлежащем немецкому фонду The Document Foundation. Репозитории altlinux.org хранят только spec-файлы (упаковочные инструкции), а не исходный код LibreOffice. В заявке 346971 runtime-скачивание с TDF убрано: freeoffice-installer теперь вызывает apt-get install freeoffice из Сизифа. Однако на уровне сборки (SRPM Source:) исходники LibreOffice по-прежнему берутся с серверов TDF - это неустранимо, пока ядро разрабатывается там.
2
Зависимость от иностранной инфраструктуры подтверждена самим заявителем
Заявитель прямо указывает в документах: «Разработчики Базальт СПО осуществляют регулярные коммиты в апстрим» с ссылкой на gerrit.libreoffice.org/q/owner:nuke@altlinux.org. Исправление в Thunderbird также отправлено в репозиторий Mozilla. Таким образом, зависимость от иностранной инфраструктуры не устранена - она структурно встроена в процесс разработки.
3
Предложенный продукт - набор обёрток и плагинов (2 из 7 компонентов «собственные»)
Ст. 1260 ГК РФ: заявитель сам квалифицировал продукт как «составное произведение»
Заявитель прямо называет «Свободный офис» «программным комплексом (составным произведением)». По ст. 1260 ГК РФ, автор составного произведения обладает авторским правом лишь на осуществлённые им подбор и расположение материала, но НЕ на компоненты (п. 3 ст. 1260 ГК РФ). Исключительные права на LibreOffice остаются у The Document Foundation. Следовательно, у заявителя отсутствуют исключительные права на продукт в целом, требуемые п. 5(а) Постановления № 1236.
5
Вывод: включить плагины, а не офисный пакет
Если у заявителя нет исключительных прав на LibreOffice (ст. 1260 ГК РФ + MPL 2.0), то логично рассматривать внесение в реестр только тех объектов, на которые у него такие права есть: Surguch (утилита для работы с PDF и ЭП) и LibreOffice-plugin-altcsp (плагин КриптоПро). Это отдельные, самостоятельные программы, подпадающие под соответствующие классы реестра. Включение «Свободного офиса» как офисного пакета некорректно, поскольку ядром офисного функционала является LibreOffice, права на который заявитель не может подтвердить в полном объёме.
«Регулярная отправка переводов в upstream» — это не доказательство суверенитета,
а наоборот: признание зависимости от иностранной инфраструктуры и передача
результатов работы в иностранную юрисдикцию.
Разработчики признают, что исходный код LibreOffice формируется
за пределами России на инфраструктуре
The Document Foundation.
Противоречие требованиям реестра:
П. 5(а) Постановления № 1236
требует наличия у российского правообладателя исключительных прав
на программный продукт в целом.
Если код формируется за границей — это нарушает суверенитет.
3
Лицензионные требования MPL 2.0
Компоненты «Свободного офиса» распространяются под
MPL 2.0
и LGPL v3.
«Предлагается вынести заявку на очное заседание экспертного совета
для определения её соответствия требованиям Правил»
Что это означает:
Эксперт не смог подтвердить соответствие ни одному из ключевых требований
постановления № 1236. Все вопросы требуют коллективного обсуждения
на заседании Экспертного совета.
6a
Признание: зависимость не только от LibreOffice, но и от Mozilla
Исправление отправлено в репозиторий Mozilla Foundation (США). Таким образом, заявитель зависит не от одного иностранного репозитория, а минимум от двух: gerrit.libreoffice.org (TDF, Германия) и hg-edge.mozilla.org (Mozilla, США). Возможность отзыва доступа продемонстрирована прецедентом с Astra Linux в 2022 году.
Системный вывод:
Продукт стратегически зависит от нескольких иностранных организаций, ни одна из которых не подконтрольна российскому праву. «Отечественный репозиторий Сизиф» - это только сборочная инфраструктура, не меняющая юрисдикцию исходного кода.
Репозиторий «Сизиф» (пакет libreoffice)
— это дистрибутивный репозиторий ALT Linux, а не разработческий репозиторий LibreOffice. В заявке 346971 пакет переименован из LibreOffice-still в libreoffice (строчные), версия libreoffice-25.8.3.2-alt2 (ноябрь 2025).
Исходный код по-прежнему формируется за границей РФ.
На странице «Проект Сизиф» на сайте Базальт СПО в инфографике явно указано: «В репозиторий проекта входят: собственные разработки ALT Linux Team + разработки международных проектов свободного ПО». В списке международных проектов на схеме прямо изображён LibreOffice — наряду с Linux Kernel, Wine, glibc и другими.
Это означает: сам Базальт публично признаёт, что LibreOffice - это международный проект, а не собственная разработка. Утверждение в форме реестра о «собственной разработке» всего продукта противоречит собственному сайту заявителя.
На экспертизу подан не продукт, а скрипт загрузки (заявка 342570)
Технически доказано
Из экспертного заключения по заявке 342570 (эксперт Щеглов П.Е.):
«На экспертизу предоставлен файл freeoffice-installer.tar.xz размером 1,47 МБ, который не содержит никаких заявленных функций, а является оболочкой для скрипта, осуществляющего загрузку различных пакетов из репозитория Сизиф, в частности - LibreOffice-still (packages.altlinux.org/...freeoffice/specfiles/)»
Критическая находка в spec-файле LibreOffice-still:
# Get Source0-3 from http://download.documentfoundation.org/libreoffice/src/$ver/
# Get Source10 (with selected components) from https://dev-www.libreoffice.org/src/
# Security fixes from https://www.libreoffice.org/about-us/security/advisories/
Вывод эксперта: «хранилище исходных кодов Сизиф зависит от исходного "исходного кода", который хранится на серверах немецкой организации The Document Foundation» - нарушение п. 5(и) Правил.
«Модификация исходного кода осуществляется сообществом LibreOffice, которое не имеет статуса российской коммерческой или некоммерческой организации без преобладающего иностранного участия. Куратором является немецкая НКО The Document Foundation.»
Обновление по заявке 346971 (Инструкция по установке, 2025):
freeoffice-installer теперь - графическая GUI-утилита, которая запускает системный менеджер пакетов. Диалог аутентификации раскрывает реальную команду:
Это устраняет явное скачивание с TDF на уровне установщика - пакет теперь берётся из Сизифа. Однако LibreOffice в Сизифе собирается из исходников TDF - зависимость переместилась на уровень сборки пакета, но не исчезла.
Лицензионное соглашение Базальт СПО: ключевые признания
Собственный документ заявителя
Лицензионное соглашение на «Свободный офис» (basealt.ru/alt-office) содержит признания, существенные для оценки правовой позиции:
П. 2.1 — самоквалификация в юридически обязывающем документе: «авторские права на ДИСТРИБУТИВ как составное произведение»
Базальт квалифицирует продукт как «составное произведение» не только в форме реестра, но и в собственном EULA — публичном договоре с каждым пользователем. Это закрепляет применение ст. 1260 ГК РФ: авторские права Базальт распространяются только на подбор и расположение компонентов, но не на LibreOffice как таковой.
П. 2.1 — разрешения, а не приобретение прав: «получены разрешения правообладателей»
Применительно к несвободным компонентам EULA признаёт: Базальт лишь получил разрешение на распространение от правообладателей — но не приобрёл сами исключительные права. Для LibreOffice и других свободных компонентов «разрешением» является открытая лицензия (MPL 2.0, LGPL), которая также не передаёт исключительных прав. Это означает, что Базальт физически не может предъявить исключительные права на LibreOffice — их просто не существует у него как у субъекта.
Итог:
Собственный EULA Базальт СПО подтверждает: Базальт имеет права только на составительство (ст. 1260 ГК РФ), на LibreOffice — лишь разрешение от MPL 2.0, но не исключительные права. П. 5(а) Постановления № 1236 требует именно исключительных прав на продукт в целом.
Три неверных утверждения Базальт СПО в «Справке для эксперта»
Опровергнуто экспертом
Утверждение Базальт: «Мы соответствуем всем пунктам кроме и)»
Факт: нарушение выявлено по п. 5(и)И по п. 5(з). Экспертиза была остановлена досрочно по факту выявления существенного нарушения - остальные пункты не проверялись.
Утверждение Базальт: «В заключении речь шла о сборке из исходников»
Факт: была выявлена зависимость хранилища исходного кода от иностранных источников. Замечаний к процедуре сборки не было.
Утверждение Базальт: «Была найдена ссылка на проект LibreOffice»
Факт: найдены не «ссылки», а инструкции по загрузке исходного кода LibreOffice с сайта The Document Foundation. Это принципиально разные вещи.
Дополнительно: манипуляция шаблоном заключения
Эксперт обращает внимание: если в поле шаблона при отрицательном заключении нет текста, система по умолчанию проставляет «соответствует». Базальт СПО использует это как «доказательство» соответствия по незаполненным пунктам. Рекомендация эксперта: при отрицательном заключении включать только заполненные пункты или менять формулировку «соответствует» на «комментарии не предоставлены».
Стратегия обфускации между заявками: устранение симптома, а не причины
Заявки 342570 → 346971
Из справки эксперта Щеглова П.Е.:
«Обращает на себя внимание тот факт, что для следующей заявки для ПО "Свободный Офис" был предоставлен другой дистрибутив, в котором Заявитель внёс изменения, разрывающие прямую связь с оригинальным источником кода LibreOffice.»
Что изменилось между заявками:
Заявка 342570
freeoffice-installer.tar.xz с прямыми ссылками на download.documentfoundation.org в spec-файле
Заявка 346971 (14.12.2025)
freeoffice-installer переписан как полноценный RPM-пакет (v1.0.0-1.1.0, сентябрь 2025, 11+ итераций). LibreOffice переименован из «LibreOffice-still» в «libreoffice» (строчные). Прямая ссылка на TDF скрыта на уровне установщика, но SOURCE-зависимость SRPM-spec от download.documentfoundation.org сохраняется.
Почему это не устраняет нарушение:
Скрытие прямой ссылки в установщике не меняет факта: исходный код LibreOffice по-прежнему разрабатывается и хранится на серверах TDF в Германии. Обфускация цепочки зависимости - это сокрытие нарушения, а не его устранение. Именно поэтому заявка 346971 также получила отрицательную оценку по большинству пунктов п. 5 Правил.
Юридическое противоречие внутри заявки 346971
Reestr 346971 · Внутреннее противоречие
В одной и той же заявке заявитель одновременно указывает два взаимоисключающих правовых основания:
Краткое описание ПО:
«программный комплекс (составное произведение)»
→ ст. 1260 ГК РФ: права только на подбор/расположение, не на LibreOffice
Основания прав правообладателя:
«Собственная разработка»
→ ст. 1295 ГК РФ: создано силами и средствами самого заявителя
Правовая несовместимость:
«Составное произведение» (ст. 1260 ГК РФ) означает, что продукт создан из чужих компонентов - это прямо исключает квалификацию всего продукта как «собственной разработки». Применительно к LibreOffice - исходный код которого создан тысячами разработчиков по всему миру под управлением немецкой НКО TDF - заявление о «собственной разработке» ложно. Это не просто правовая коллизия, а факт, подлежащий проверке регулятором.
Как проверить: убрали ли реально зависимость от TDF?
Методология верификации
Базальт СПО утверждает, что убрала явное скачивание кода с серверов TDF. Существуют три уровня зависимости, каждый из которых проверяется независимо:
Уровень 1 - Пользовательский (Runtime)ВЕРОЯТНО УСТРАНЁН
Что было: freeoffice-installer.tar.xz (1.47 МБ) - shell-скрипт, скачивавший пакеты при установке.
Что сейчас: freeoffice-installer v1.1.0-alt1 - полноценный RPM-пакет в Сизифе. Конечный пользователь больше не видит прямого скачивания с TDF.
Проверка: Установить freeoffice-installer на ALT Linux и проследить сетевые соединения через tcpdump/ss.
Уровень 2 - Сборочный (Build-time)НЕ УСТРАНЁН
Что проверять: SRPM-spec libreoffice (libreoffice-25.8.3.2-alt2.src.rpm) - директивы Source0/Source1 указывают откуда берётся исходный код LibreOffice при сборке.
Признак нарушения: Наличие строк download.documentfoundation.org или dev-www.libreoffice.org в Source-директивах SRPM-spec.
Проверка:rpm -qp --queryformat "%{SOURCE}" libreoffice-*.src.rpm или смотреть git.altlinux.org/gears/l/libreoffice.git → libreoffice.spec.
Уровень 3 - Правообладание (Copyright)НЕУСТРАНИМО
Даже если Базальт СПО поднимет собственное зеркало исходников TDF - исключительные права на код LibreOffice принадлежат TDF и тысячам контрибьюторов. Зеркало не меняет авторство. Ст. 1260 ГК РФ это прямо подтверждает.
Проверка: Поиск на gerrit.libreoffice.org коммитов от @altlinux.org / @basealt.ru - если они продолжают коммитить в upstream, развитие продукта зависит от иностранной инфраструктуры.
Вывод по верификации:
Устранение видимого симптома (runtime-скачивание) не устраняет ни build-time зависимость от TDF-серверов как источника исходного кода, ни правообладание TDF на LibreOffice. П. 5(а) Постановления № 1236 требует исключительных прав на весь продукт - этого у заявителя нет и быть не может при MPL 2.0.
Опровержение: «ОС Эльбрус уже в реестре с офисными приложениями»
Аргумент Базальт СПО
Позиция Базальт СПО (предполагаемая):
«ОС Эльбрус уже включена в реестр с классом "Офисные приложения", в её состав входит LibreOffice - значит, аналогичный подход должен быть применён и к "Свободному офису"».
Факт: класс удалён из реестровой записи (эксперт Закоржевский, 2025)
Реестровая запись ОС Эльбрус № 3199: класс 04.03 «Офисные приложения» удалён из записи 05.09.2022. Таким образом, на момент рассмотрения заявки «Свободного офиса» (2025-2026) ОС Эльбрус уже не числится в реестре с классом офисных приложений.
Включение ОС (операционной системы) в реестр с офисными приложениями в составе не является прецедентом для отдельного офисного пакета: ОС подаётся как системное ПО (класс 02.xx), а «Свободный офис» претендует именно на класс офисного ПО (05.02 или 06.03), где требования к исключительным правам на ядро применяются напрямую.
⚠️ Степень уверенности
Факт удаления класса 04.03 из записи № 3199 указан экспертом Закоржевским с конкретными датой и номером. Проверяется напрямую на сайте реестра. До независимой верификации - маркировать как «требует проверки в реестре».
Материалы Астры не оправдывают «Свободный офис», а показывают другой сценарий допуска
Сравнение кейсов
Из пояснений ООО «РусБИТех-Астра» к заявкам №№ 346971 и 351219:
Объект заявки у Астры - Astra Linux Special Edition, а не отдельный офисный пакет. LibreOffice, Thunderbird и криптоплагины описаны как компоненты в составе ОС; в обосновании отдельно подчеркнуты лицензия ФСБ и тематическое заключение ФСБ России № 149/3/2/1-2768 от 06.10.2021 по совместной работе со СКЗИ КриптоПро CSP.
Что доказывает Астра
Материалы Астры подтверждают только то, что LibreOffice может использоваться внутри сертифицированной российской ОС совместно с отечественными криптосредствами и собственными интеграционными модулями. Это аргумент о доверенной среде эксплуатации, а не о том, что права на LibreOffice «переходят» к российскому вендору.
Что Астра не доказывает
Ни лицензия ФСБ/ФСТЭК, ни тематическое заключение по СКЗИ не снимают требования п. 5(а) Постановления № 1236 к правам на заявляемый продукт. В таблице Астры LibreOffice и Thunderbird прямо названы теми же внешними компонентами, что и у Базальта. Значит, даже по логике Астры спор идёт не о «российскости» ядра LibreOffice, а о допустимости его использования внутри другого, более крупного и сертифицированного продукта.
Практический вывод для допуска
Если кейс Астры вообще релевантен, то он поддерживает не регистрацию отдельного LibreOffice-based офиса, а только сценарий «российская ОС + собственные криптоинтеграции + подтверждённая совместимость». Для «Свободного офиса» это работает скорее против заявки: допустимый объект реестра тогда - сама ОС или самостоятельные российские модули (Surguch, CSP-плагины), а не отдельный офисный пакет, в котором ядро остаётся LibreOffice.
Презентация Базальта и таблица разногласий не снимают замечания по существу
Смысл материалов Минцифры
Прямое признание OS-зависимого состава
В презентации Базальта указано, что для ALT архив не включает Chromium и Thunderbird, потому что они уже входят в ОС, а для Astra Linux архив должен быть иным - в формате deb и со «всем необходимым ПО». Это означает, что состав «Свободного офиса» меняется в зависимости от целевой ОС. Такой продукт трудно считать единым самостоятельным офисным пакетом; он выглядит как установщик и интеграционная обвязка вокруг ОС-специфичных компонентов.
Сертификация ФСТЭК у Базальта относится к ОС, а не к ядру «Свободного офиса»
Базальт отдельно ссылается на то, что компоненты уже находятся в составе дистрибутивов ОС ALT, включая сертифицированную версию по требованиям ФСТЭК. Это усиливает только доверие к платформе ALT Linux, но не устраняет вопрос: кому принадлежат права на LibreOffice/DavMail/Thunderbird в заявляемом офисном продукте. По существу это та же логика, что у Астры: доверенная ОС не превращает LibreOffice в собственную разработку заявителя.
Что реально показывает таблица разногласий Минцифры
«Таблица ответов заявителя на замечания экспертов» - это не акт согласия Минцифры с позицией Базальта, а процессуальный документ, где спор сводится к одному тезису: заявитель считает, что прав на составное произведение по ст. 1260 ГК РФ достаточно. При этом сама таблица фиксирует, что замечания по LibreOffice, DavMail, товарному знаку, хранению исходников, обращениям к github.com и OS-зависимому составу никуда не исчезли - на них дан лишь единый ответ через концепцию составного произведения.
Юридическое последствие
После изучения презентации и таблицы спор становится уже, а не слабее: вопрос теперь звучит так - можно ли допустить в реестр отдельный офисный пакет, если заявитель признаёт, что его ядро состоит из чужих программ, а свои права обосновывает только подбором и интеграцией? Именно на этом узком вопросе Базальт пока не даёт нового факта, а только повторяет прежнюю правовую квалификацию.
Документальные врезки: ключевые фрагменты из PDF
Ниже не пересказ, а прямые фрагменты спорных материалов. Каждая карточка отвечает на отдельный вопрос: что именно заявлено, что именно признаёт Базальт, и что именно показывают экспертные возражения.
Астра, стр. 1Объект заявки = ОС
Астра описывает не отдельный офисный пакет, а сертифицированную ОС с офисными компонентами
Источник: «Сравнение для экспертов_Астра.pdf», стр. 1.
«ООО "РусБИТех-Астра" подано заявление ... программному обеспечению: "Astra Linux Special Edition"... подтверждения применения офисных программ в составе операционной системы...»
Что это доказывает: кейс Астры отвечает на вопрос о доверенной российской ОС и совместимости со СКЗИ, но не на вопрос о переходе исключительных прав на ядро LibreOffice.
Презентация Базальта, стр. 3OS-зависимый состав
Базальт сам признаёт, что состав архива меняется под конкретную ОС
«При этом в архив не входят Chromium и Thunderbird... Для других ОС, например, Astra Linux, архив будет содержать пакеты в формате deb, а не rpm и все необходимое ПО...»
Что это доказывает: заявленный продукт ведёт себя не как единый офисный пакет, а как инсталлятор и интеграционная сборка, состав которой зависит от целевой ОС.
Презентация Базальта, стр. 4Ответ сводится к ст. 1260
Ключевой ответ Базальта: достаточно прав на составное произведение в целом
«Права на составное произведение "Свободный Офис" принадлежат Заявителю в соответствии со ст. 1260 ГК РФ... Достаточно наличия исключительных прав на составное произведение в целом...»
Что это доказывает: после всех ответов спор сужается до одной правовой конструкции: Базальт не доказывает права на ядро LibreOffice, а доказывает достаточность прав на подбор и интеграцию.
Таблица разногласий, стр. 8Официальная процессуальная позиция
В таблице разногласий Базальт повторяет ту же схему: open-source допускается, если есть права на структуру и интеграцию
Источник: «Таблица разногласий_итог.pdf», стр. 8.
«Использование программ третьих лиц... само по себе не исключает наличие исключительных прав на составное произведение в целом... правообладатель которого обладает правами на его структуру, интеграцию и собственные модули...»
Что это доказывает: таблица разногласий не снимает экспертные замечания, а фиксирует официальный ответ заявителя: права на ядро не подтверждаются, вместо этого подтверждаются права на интеграцию.
Журавлёв, стр. 3Прецедент Ankey SIEM
Экспертный контраргумент: суд уже подтверждал, что прав на составное произведение может быть недостаточно для реестра
Источник: «Свободный_офис_Журавлев.pdf», стр. 3.
«...ПО представляет собой составное произведение... но в то же время заявитель не обладает исключительным правом на ПО... ПО не соответствует требованиям ... и не может включаться в Реестр».
Что это доказывает: враждебный для Базальта прецедент уже существует: сама по себе квалификация по ст. 1260 ГК РФ не гарантирует соответствие реестровому критерию исключительных прав.
«Собственной разработкой "Базальт СПО" являются: инсталлятор пакетов... инструменты для работы с электронной подписью... Ключевые компоненты... LibreOffice, DavMail, Chromium, Thunderbird».
Что это доказывает: собственный вклад Базальта находится на периферии продукта, а основная офисная функциональность реализуется чужими компонентами.
Закоржевский, стр. 3Нет значимых модификаций ядра
По экспертной оценке, модификации LibreOffice и DavMail минимальны, а код формируется вне РФ
«Не обнаружены модификаций кода DavMail... заявитель не в полном объеме обладает исключительным правом... код формально хранится на отечественных серверах, но фактически "подтягивается" с зарубежных репозиториев».
Что это доказывает: если существенной переработки ядра нет, то тезис о собственном офисном пакете становится ещё слабее и уходит в плоскость переупаковки и локальной интеграции.
Итоговый вывод по аргументации «Свободного офиса»
•«Регулярные коммиты в upstream» и «отправка переводов» — признание зависимости от иностранной инфраструктуры
•Экспертное заключение 2025 прямо указывает: «код формируется за границей РФ на инфраструктуре TDF»
•Экспертное заключение 2026: ни одно требование не подтверждено, всё «на обсуждение»
•MPL 2.0 требует открытия модификаций — но где публичный репозиторий с полным форком?
•«Собственные разработки» — это плагины и обёртки, а не ядро офисного пакета
•Заявка 342570: предоставлен не продукт, а 1.47 МБ-скрипт загрузки; spec-файл Сизифа прямо указывает на download.documentfoundation.org как источник исходников
•Три ложных утверждения Базальт СПО в «Справке для эксперта» опровергнуты документально экспертом Щегловым П.Е.
•Между заявками 342570 и 346971 применена стратегия обфускации: прямая ссылка на TDF скрыта в установщике, но зависимость от иностранных исходников не устранена
•EULA п.2.1: в собственном лицензионном соглашении Базальт прямо называет продукт «дистрибутивом как составным произведением» и указывает, что на компоненты лишь «получены разрешения» — то есть признаёт отсутствие исключительных прав в юридически обязывающем документе
•Сайт Базальт СПО: на странице «Проект Сизиф» LibreOffice явно изображён как «международный проект» — прямо противоречит заявленной «собственной разработке» в форме реестра
•Контекст: Ростелеком (конец 2025): приобрёл 25% Базальт СПО — Ростелеком российская государственная компания, поэтому п.5(б) об иностранном участии не затрагивается. Фактически это означает усиление государственного участия в структуре, что для целей реестра нейтрально или положительно. [Фактический контекст, не правовой аргумент против заявки]
•Состав дистрибутива 346971: Chromium и Thunderbird фактически не входят в дистрибутив - они устанавливаются отдельно после freeoffice-installer. Установщик также удаляет LibreOffice из ALT OS 11 при запуске (эксперт Щеглов П.Е.). Таким образом, декларируемый в заявке состав продукта расходится с фактическим содержимым дистрибутива.
•«LibreOffice Community» маркировка: TDF ввела это обозначение специально для отказа от обязательств по enterprise-поддержке. Базальт использует именно эту маркировку - тем самым признавая, что сборка не имеет статуса поддерживаемого enterprise-дистрибутива TDF. Это усиливает аргумент о структурной зависимости: без enterprise-статуса TDF Базальт лишён гарантированного SLA на патчи CVE.
•Кейс Астры не подтверждает допустимость отдельного LibreOffice-based офиса: он описывает другой объект реестра - сертифицированную ОС со встроенными офисными компонентами и собственными криптоплагинами. Это аргумент за доверенную среду, а не за права на ядро LibreOffice.
•Презентация Базальта и таблица разногласий Минцифры сужают спор до одной точки: заявитель не опровергает иностранное происхождение ключевых компонентов, а лишь утверждает, что прав на составное произведение достаточно. Именно этот тезис и должен оцениваться на соответствие п. 5(а) № 1236.
Источники и ссылки
Первоисточники, официальные документы и аналитические материалы, использованные в дешборде.
Пояснения ООО «РусБИТех-Астра» к заявкам №№ 346971 и 351219
Использовано для разграничения двух сценариев: сертифицированная ОС с компонентами LibreOffice внутри и отдельный офисный пакет как самостоятельный объект реестра.
