Опубликовать инициативу
Всего
инициатив:

Инициатива №
64Ф32959
Уровень инициативы:
Федеральный

Делать программное обеспечение, разрабатываемое за счёт бюджетных средств, свободным

В настоящий момент немалое количество бюджетных средств тратится на разработку программного обеспечения (ПО) для нужд различных ведомств. При этом исполнители, занимающиеся разработкой или сопровождением ПО (далее — «разработчики»), зачастую вынуждены повторять работу, уже проделанную ранее другими исполнителями в рамках других проектов. Очевидно, что такой подход является неэффективным.
Одной из базовых концепций разработки ПО является повторное использование кода. Наиболее эффективно оно реализуется в свободном программном обеспечении (допускающем использование, изучение, модификацию и дальнейшее распространение). Поэтому свободное ПО в виде программных библиотек (модулей), целых программ и операционных систем широко используется повсеместно, в том числе и в государственных и бюджетных организациях. Для достижения наибольшей эффективности повторного использования кода имеет смысл все программные разработки, финансирующиеся из бюджетных средств, делать свободными.
При правильном подходе это принесёт и дополнительные преимущества, такие как повышение качества кода и снижение затрат на его поддержку. Для этого необходимо взаимное сотрудничество разработчиков с независимым сообществом. С одной стороны, при использовании стороннего свободного ПО, вокруг которого существует ранее сложившееся сообщество, необходимо осуществлять возврат сообществу сделанных доработок и взаимодействовать с ним для решения выявленных проблем. С другой стороны, при разработке нового программного обеспечения необходимо предоставить всем, кто может иметь заинтересованность, возможность участия в проекте: сообщения об обнаруженных ошибках (в том числе уязвимостях), предложения собственных исправлений и улучшений, запроса новой функциональности и улучшения существующей.
Переход от проприетарного ПО к свободному является общемировой тенденций, хотя законодательно закреплён пока только в некоторых странах. В частности, требование публикации вновь разрабатываемого за государственный счёт ПО как свободного или открытого существует в Болгарии и США. Безусловно, их опыт следует принять во внимание.
В Болгарии с 1 июля 2016 года вступили в силу поправки к Акту об электронном правительстве. В соответствии со статьёй 58a новой редакции, при разработке нового программного обеспечения обязательно должно выполняться требование соответствия его критериям открытого программного обеспечения (очевидно, здесь используется терминология Open Source Initiative, и название «открытое программное обеспечение» следует трактовать как аналог свободного ПО).
В США 8 августа 2016 года опубликован меморандум о федеральной политике исходных кодов. В соответствии с этой политикой исходные коды ПО, разрабатываемого для федеральных агентств, должны быть доступны для повторного использования другими агентствами. Также запускается пилотный проект по открытию исходных кодов, в рамках которого должны быть открыты коды не менее 20% вновь разрабатываемого ПО, и рекомендуется рассмотреть вопрос об открытии ПО, разработанного ранее. Причём речь идёт не только о публикации исходных кодов, но и о предоставлении средств для формирования сообщества вокруг этого кода, обратной связи и участия в разработке. Кроме того, государственным служащим и работающим по контракту рекомендуется участвовать в сообществах существующих проектов открытого ПО. В меморандуме уточняется, что под «открытым ПО» понимается ПО, соответствующее определению Open Source Initiative, и/или определению «свободного ПО» Free Software Foundation. Код, открытый в рамках пилотной программы, доступен через веб-сайт.
В России действует ГОСТ Р 54593-2011 «Информационные технологии. Свободное программное обеспечение. Общие положения», однако он имеет ряд недоработок. Для реализации настоящей инициативы потребуется исправить в нём следующие ошибки:
- стандарт определяет исходный код программы как «компьютерную программу в текстовом виде на каком-либо языке программирования». Однако такое определение некорректно, поскольку ему соответствует код, подвергшийся обфускации (преднамеренному запутыванию), минификации (уменьшению объёма с ущербом для читаемости), генерации или трансляции на другой язык программирования. Более удачным и общепринятым является следующее определение: исходный код — это форма произведения, являющаяся предпочтительной для внесения изменений. Оно к тому же более универсально, так как может распространяться не только на исполняемый код, но и на данные в различных форматах;
- в разделе стандарта 4.2 «Инфраструктура разработки и использования программного обеспечения» фактически описана инфраструктура поставки ПО, но не его разработки. Инфраструктура разработки должна включать в себя систему контроля версий, систему аудита изменений, систему отслеживания ошибок и систему автоматического тестирования.

Практический результат

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

Решение

Законодательно закрепить требование, в соответствии с которым исходные коды ПО, разработка которого финансируется из бюджетных средств, должны публиковаться на условиях лицензии свободного ПО.
Обязать исполнителей, осуществляющих разработку или поддержку свободного ПО за счёт бюджетных средств (далее — «разработчиков»), обеспечить публичную инфраструктуру для доступа к исходным кодам (в том числе системе контроля версий), сообщениям об ошибках (с возможностью временного сокрытия информации о неисправленных уязвимостях), предложения изменений в исходные коды, автоматического тестирования таких изменений и их рецензирования.
Установить регламенты, в соответствии с которыми разработчики должны в разумные сроки реагировать на поступившие сообщения об ошибках (в частности, выявленные уязвимости должны устраняться не более чем за 10 рабочих дней) и предложения изменений, выполнять рецензирование предложенных изменений и принимать решения об их принятии или отклонении.
Рекомендовать разработчикам сотрудничать с существующими сообществами свободного ПО, используемого в проекте, а именно сообщать об обнаруженных ошибках, предлагать свои изменения, при необходимости приводить изменения в соответствие с требованиями рецензентов.
Подготовить новую редакцию ГОСТ Р 54593, в которой будут исправлены существующие ошибки.

К началу списка инициатив