В начале октября в Переславле-Залесском состоялась двадцатая юбилейная конференция разработчиков свободных программ. Организаторы мероприятия — компания «Базальт СПО» и Институт программных систем им. А.К. Айламазяна Российской академии наук.
С приветственным словом к участникам обратился председатель совета директоров «Базальт СПО» Алексей Смирнов. Он отметил, что за 20 лет свободное программное обеспечение в России прошло путь от почти полной неизвестности до важнейшего средства кооперации конкурирующих проектов. В настоящее время практически все крупные корпорации используют свободный софт, а многие принимают участие в его разработке.
За три дня работы конференции было представлено 27 докладов. Расскажем о нескольких самых интересных.
Свободное программное обеспечение в здравоохранении
В указе Президента РФ «О национальных целях развития Российской Федерации на период до 2030 года и на перспективу до 2036 года» здравоохранение названо приоритетной отраслью. Именно применению свободного ПО в медицине был посвящён первый доклад свободного аналитика и практикующего хирурга Анатолия Якушина.
Эксперт отметил, что СПО достаточно редко используется в отечественном здравоохранении. Он назвал две основные причины такого положения вещей.
Со стороны сообщества разработчиков интерес к деятельности в области здравоохранения относительно невысок. Это обусловлено высоким порогом вхождения в отрасль, связанным со специальной терминологией, «цеховыми» представлениями и некой сакрализацией врачебного искусства.
Вторая причина — невысокая общая компьютерная грамотность медицинских работников. В общем случае она сводится к умению работать в нескольких проприетарных специализированных приложениях и поверхностному знанию офисного пакета, клиента электронной почты и мессенджера.
При этом, системное свободное программное обеспечение может быть успешно использовано в любых отраслях, включая здравоохранение. В частности, в Москве сервис ЕМИАС, охватывающий все поликлиники мегаполиса, несколько лет работал под управлением OpenSuSE.
На сегодняшний день основа любого решения в здравоохранении — медицинская информационная система. Как правило, она состоит из стандартных для любого учреждения компонентов: учёт кадров и ресурсов, контроль исполнения поручений, анализ деятельности и т. п.
Существует ряд свободных медицинских информационных систем: OpenEMR, FreeMED, OpenMSR, GNUmed и др. Они выполняют все функции, предписанные подобным решениям. Однако, есть одно серьёзное обстоятельство, препятствующее их использованию в России. Все они разработаны для американского или европейского здравоохранения.
Разница в структуре отечественных и зарубежных медицинских учреждений настолько велика, что их использование в нашей стране практически невозможно. Попытки адаптации FreeMED и GNUmed для российского рынка завершились неудачно. Объём работ таков, что проще написать аналогичное решение с нуля.
Тем не менее, выполнение повседневных задач медицинского работника зачастую не требует специализированных решений. Докладчик отметил как он сам, так и некоторые его коллеги активно используют СПО. Типичный набор приложений таков: Firefox, Emacs, LibreOffice, Dia, Runa WFE, The GIMP и Blender.
Впрочем, речь в данном случае идёт о явно немасштабируемом опыте, поскольку требует от пользователя высокого уровня компьютерной грамотности. К сожалению, рассчитывать на сколько-нибудь заметное улучшение этого показателя не приходится. За последние
Основная проблема здравоохранения с точки зрения разработчика ПО заключается в широком использовании готовых аппаратно-программных комплексов. Это томографы, лабораторные анализаторы, прикроватные блоки, аппараты УЗИ и т. п. Как правило, все эти устройства проприетарны и имеют закрытый формат обмена данными.
Несмотря на это, уже сегодня возможно применять свободное ПО для визуализации изображений в рентгенологии, травматологии, ангиохирургии. Существует открытый стандарт графических изображений DICOM, который используется во многих свободных программных решениях. Причём, по функциональности они зачастую превосходят проприетарные аналоги.
В заключении докладчик выделил ряд наиболее востребованных направлений, связанных с применением СПО в отечественном здравоохранении:
- продолжение работ по созданию специализированных кроссплатформенных приложений или веб-решений для медицины;
- разработка свободного специализированного ПО для ситуаций, в которых применение стандартных программных средств не приносит соответствующих результатов;
- создание учебных пособий и курсов по использованию СПО в медицине.
Отображение и анализ групповых политик
Анализ применяемых групповых политик широко используется системными администраторами при решении проблем, возникающих в доменной инфраструктуре. Доклад Марии Алексеевой (ООО «Базальт СПО») был посвящён утилите GPResult, разработанной для проведения подобного анализа.
В крупных организациях со сложной инфраструктурой определение применимости групповых политик сопряжено с определёнными трудностями. Например, с неочевидностью порядка их назначения.
В настоящее время в решениях «Базальт СПО» для применения групповых политик как на системном уровне, так и для отдельных пользователей применяется утилита GPUpdate, хранящая информацию о уже применённых политиках в неструктурированной бинарной базе данных формата GVDB. Таким образом, даже просмотр данных представляет собой достаточно непростую задачу, что привело к необходимости создания инструмента, позволяющего предоставлять информацию в легко читаемом формате.
Текущая версия утилиты GPResult позволяет собрать и отобразить сведения о применённых групповых политиках для текущего пользователя и локальной машины. Это позволяет администратору максимально быстро получить информацию, необходимую для решения возможных проблем доменной инфраструктуры.
Поскольку системному администратору проще работать в консоли, утилиту не стали утяжелять графическим интерфейсом и необязательными опциями. Разработчики сочли достаточным только выбор формата вывода, выдачу информации о применённой групповой политике и указание типа объекта.
В перспективе планируется реализовать поддержку удалённых пользователей, предоставление информации о перезаписанных ключах и приоритетах политик, а также разработать механизм генерации html-отчёта.
Как сделать хороший дистрибутив
Судя по высокому интересу аудитории к докладу Аркадия Шейна («Инферит», проект ОС «МСВСфера») проблемы создания дистрибутивов продолжают оставаться актуальными. Докладчик поделился личным опытом создания различных дистрибутивов Linux в России и рассказал о проблемах решений, основанных на Red Hat Enterprise Linux.
В настоящее время за рубежом существует множество дистрибутивов, основанных на пакетной базе RHEL: Oracle Linux, AlmaLinux, Rocky Linux, EuroLinux, MiracleLinux, CloudLinux. В России дела обстоят иначе. До недавнего времени в нашей стране не существовало систем, основанных на RHEL-8,9. Это вызвано тем, что предыдущие версии самого популярного корпоративного продукта собирались относительно легко, для чего использовалась система CentOS. С новыми версиями всё обстоит значительно сложнее.
В частности, сборка дистрибутива «МСВСфера-8» потребовала восьми месяцев. Правда, в результате отечественная система не только полностью повторяет пакетную базу RHEL, но и включает в себя множество дополнений, которые позволяют успешно применять систему не только на серверах, но и на рабочих станциях.
На основании личного опыта докладчик пришёл к следующим выводам о том, что нужно для создания собственного отечественного дистрибутива, а не слегка перелицованного клона.
Во-первых, система контроля версий для хранения исходных текстов. Она должна быть доступна всему сообществу, иначе никакой открытой разработки не получится.
Во-вторых, система сборки. Причём, она должна включать в себя инструментарий сборки модульных пакетов.
В-третьих, багтрекер. Без помощи сообщества найти все ошибки в решении практически невозможно.
В-четвёртых, непосредственно репозиторий. Разумеется, не только для бинарных пакетов, но и для исходных текстов.
В-пятых, документация. Желательно полная и на русском языке.
В-шестых, система тестирования. Наивно считать, что все ошибки найдёт сообщество и напишет про них в багтрекере.
В седьмых, запись в реестре и сертификация ФСТЭК. В противном случае рассчитывать на внедрение не стоит.
В-восьмых, совместимость с уже существующими отечественными решениями. В том числе и проприетарными.
Наконец, нужна хорошая команда. И следует отправлять важные изменения в upstream.
Модульная платформа для разработки Telegram-ботов «Каркас»
Социальные сети в настоящее время востребованы как бизнесом, так и обществом. Про открытую платформу для создания Telegram-ботов рассказал Семен Фомченков (ИАТЭ НИЯУ МИФИ).
Причиной для создания платформы послужила проблема существующих решений, представляющих собой монолитные системы с ограниченными возможностями кастомизации и расширения функциональности. К тому же, наиболее популярные чат-боты для Telegram являются сервисами и пользователь не представляет, что происходит «на той стороне».
Платформа «Каркас» — это решение self-hosted. Оно предназначено пользователям, стремящимся к расширенной функциональности и имеющим повышенные требования к защите обрабатываемой и хранимой информации.
Благодаря модульности «Каркас» позволяет создавать готовые решения «под ключ» и расширять функциональность за счёт подключения дополнительных, в том числе и самостоятельно написанных, блоков. Лицензия GNU GPL v3 даёт возможность как предлагать сообществу собственные разработки, так и пользоваться результатом работы других разработчиков.
Код приложения открыт для изучения и анализа, а как само решение, так и передаваемые ему данные, хранятся на собственных ресурсах. Таким образом, компании могут использовать данный чат-бот в Telegram-каналах, созданных для внутренних коммуникаций, не опасаясь за возможные утечки данных.
«Каркас» — активно развивающийся проект. В планах разработчиков: интеграция функциональности CRM-систем и поддержка протокола CalDAV.
Защита лицензий на свободное программное обеспечение
Свободные лицензии уже давно не воспринимаются обществом, как позволяющие всё, что угодно. Владимир Харин (Университет им. О. Е. Кутафина) познакомил участников конференции с возможными нарушениями свободных лицензий и предложил методы защиты.
Несмотря на продолжительную историю отечественного СПО, в России не развита практика защиты прав на свободные программы. Это создаёт у потенциальных нарушителей ощущение безнаказанности.
По мнению докладчика, самое распространённое нарушение свободных лицензий — плагиат. Причём, в данном случае речь идёт не просто о присвоении авторства, но и о смене лицензии на проприетарную.
В подтверждение своих слов докладчик сослался на исследование компании Synopsys, проведенное в 2022 году. Оно показало, что 98% всех компьютерных программ содержат фрагменты открытого кода, причём средний объём этого кода составляет 75%. Возможно, в России данные будут несколько иные, но по мнению Владимира Харина если отличия есть, то небольшие.
Разумеется, в значительной части случаев заимствование происходило на законном основании. Но вследствие распространённости явления резонно предположить, что нарушения всё-таки имеют место. А поскольку факт нелегального использования свободного кода сложно обнаружить, существует высокая вероятность того, что масштаб проблемы значительно больший, чем нам кажется.
Второе возможное нарушение — нелегальное перелицензирование, а именно использование исходного кода в другом свободном проекте, лицензия на который несовместима с лицензией копируемого кода. Таким образом нарушаются сразу две лицензии. Впрочем, статистики по неправомерному перелицензированию нет, поэтому угроза пока является умозрительной.
Наконец, существуют лицензии, разрешающие использование кода в проприетарных решениях, но только после внесения определённой оплаты авторам. Поскольку технических препятствий бесплатному копированию нет, существует серьёзный соблазн нарушения.
К сожалению, судебная защита от плагиата и бесплатного использования свободного кода крайне затруднительна. Причина этого в том, что доказать заимствование открытого кода в проприетарных программах можно путём судебной экспертизы, для назначения которой у суда должны быть веские основания.
В качестве действительно эффективной меры защиты докладчик рассмотрел принудительную регистрацию всех программ с проверкой их исходного кода. Однако, такой процесс весьма ресурсозатратен и увеличивает нагрузку на государственные органы без видимой пользы для самого государства.
По мнению докладчика возможна и техническая защита кода. Она заключается в преднамеренно нелогичном кодировании отдельных фрагментов, которое будет бросаться в глаза даже при беглом просмотре. Впрочем, эффективность такого метода вызвала у аудитории большие сомнения.
Возможно, с нарушениями свободных лицензий сможет бороться некая негосударственная ассоциация. Если, конечно, таковая будет создана, вероятность чего не слишком велика.
Таким образом, вывод из доклада неутешительный. Действенного метода противодействию нарушениям свободных лицензий на сегодняшний день не существует.
