Антон Сметанин о том, почему Минкомсвязь России рекомендует госорганам перейти на свободное ПО

В конце августа Министерством связи и массовых коммуникаций Российской Федерации утвердило Методические рекомендации по использованию свободного ПО при осуществлении деятельности госорганов и бюджетных организаций. Стоит ли ожидать массового перехода госорганов на свободное ПО (СПО)? С какими трудностями могут столкнутся чиновники при использовании СПО? Какие нюансы СПО Минкомсязи не учло в своих рекомендациях? Ответы на эти вопросы в эксклюзивном интервью DR c автором текста рекомендаций – Антоном Сметаниным.

Почему методрекомендации были утверждены именно сейчас?

История разработки и принятия этого документа довольно длинная. Его первая редакция была написана еще в 2008 году, и тогда он назывался «Методические рекомендации по разработке и приобретению программного обеспечения для использования в органах государственной власти и бюджетных учреждениях». Консалтинговой компании, в которой я тогда работал, было поручено разработать эти рекомендации «в нагрузку» к госконтракту на выполнение научно-исследовательской работы по правовым вопросам использования свободного ПО в госорганах. Задача написать документ именно об СПО перед нами не ставилась – нужно было просто разработать документ, соответствующий указанному названию, какая-либо конкретика не уточнялась. Однако, хорошо понимая все преимущества использования свободного ПО, мы постарались сделать все возможное, чтобы в результате утверждения этого документа госорганам было рекомендовано использовать в своей деятельности именно СПО, поэтому документ и получил соответствующую направленность.

Поручение о разработке методрекомендаций было дано одновременно с поручением о разработке небезызвестного Плана перехода федеральных органов исполнительной власти и федеральных бюджетных учреждений на использование свободного программного обеспечения[1] (далее – План перехода), их разработка и согласование шли параллельно, поэтому ориентированность рекомендаций использование СПО выглядела вполне логично и не вызвала возражений.

К сожалению, довести процесс утверждения методрекомендаций до логического завершения на тот момент не удалось по целому ряду причин, главная из которых – отсутствие необходимых правовых оснований для принятия Минкомсвязью приказа об их утверждении. Теперь же такие основания появились: подготовка и утверждение методических рекомендаций по использованию свободного программного обеспечения в деятельности федеральных органов исполнительной власти была прямо предусмотрена Планом мероприятий («дорожной картой») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утвержденным Распоряжением Правительства Российской Федерации от 9 июня 2014 года №991-р (п. 59).

Кроме того, Минкомсвязью были озвучены планы по возобновлению перехода госорганов на СПО. Так, на сайте Минкомсвязи выложена информация о том, что в ближайшее время должна быть подготовлена новая редакция утвержденного ранее Плана перехода, который на практике практически не выполнялся (единственным ведомством, которое выполнило план перехода на СПО, стала служба судебных приставов). Думаю, не последнюю роль в утверждении методрекомендаций сыграла и реализуемая в настоящий момент политика импортозамещения программного обеспечения.

Какие задачи ставились при подготовке документа?

Проект методрекомендаций, подготовленный министерством на основе старой редакции документа, вызвал много критики, значительная часть которой была обусловлена тем, что многие его положения были привязаны к мероприятиям Плана перехода, которые на практике не были реализованы, в результате чего смысл этих положений оказывался непонятен. Поэтому основной задачей было устранить привязку к Плану перехода, подготовив независимый по смыслу документ. Кроме того, предыдущая практика согласования методрекомендаций показала, что принцип максимального соответствия текста как материалам The Free Software Foundation (далее – FSF), так и терминологии российского законодательства об авторском праве, дает на выходе чрезвычайно сложные конструкции и формулировки, понять которые непросто даже специалисту в области авторского права.

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

Методрекомендации включают в себя определения свободного и проприетарного ПО. Насколько они точны, и каково их практическое значение?

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

Не обошлось без этого и в утвержденных министерством методрекомендациях. Так в результате описанных выше упрощений была утрачена довольно важная мысль, которая была отражена в старой редакции документа. Это мысль о том, что свободное ПО – это не только свободные лицензии, но и открытый исходный код. В утвержденной в итоге редакции документа об этом не говорится. Вместо этого в определении СПО (п. 4) указано, что свободная лицензия позволяет изучать исходные коды программы.

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

Причем требования раскрытия исходного кода содержаться только в copyleft лицензиях, таких как GPL, MPL и т.д. Простые разрешительные лицензии, такие как BSD, X11 и т.д., подобных требований вообще не содержат, поэтому их исходный код может быть беспрепятственно закрыт.

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

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

В то же время, нужно отметить, что это упущение в определении СПО с лихвой компенсируется на практике поистине беспрецедентным шагом, на которое пошло министерство при утверждении документа. Заключается он в том, что в тексте методрекомендаций (п. 7) была сохранена предложенная мной прямая ссылка на раздел сайта FSF, содержащая наиболее полный и актуализированный перечень всех известных на сегодняшний день свободных лицензий, их краткое описание, сведения о совместимости с другими лицензиями, в том числе GPL. Честно признаюсь, я не очень рассчитывал, что эта ссылка сохранится в тексте. Однако она была сохранена, и теперь госслужащие всегда смогут гарантированно определить, что перед ними именно свободная лицензия, просто найдя ее название на сайте FSF и сверив тексты лицензий. Так что это положение методрекомендаций имеет, на мой взгляд, ключевое значение.

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

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

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

Что касается определения проприетарного ПО (п. 4), то оно изложено предельно конкретно, ровно так, как это сделано на сайте FSF (проприетарное ПО – это ПО, не являющееся свободным). Приятно радует, что здесь не было сделано попыток добавить какие-то дополнительные квалифицирующие признаки, которые бы только осложнили понимание вопроса.

В чем значимость меторекомендаций для отрасли? Какие положения стоит особо отметить? Есть ли в документе недоработки?

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

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

Также в методрекомендациях освещена важная проблема несовместимости лицензий (п. 9), характерной для copyleft лицензий, каждая из которой требует, чтобы все производные программы распространялись только на ее условиях, что делает невозможным совместное использование компонентов с разными copyleft лицензиями. К сожалению, в российской практике этому вопросу уделяется мало внимания, в результате чего в готовом программном решении, разработанном по госконтракту, могут оказаться компоненты с несовместимыми лицензиями, что сделает его дальнейшее распространение неправомерным. Поэтому для решения этой проблемы в документе приводятся соответствующие рекомендации (п.п. 10, 13).

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

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

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

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

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

Можно ли сказать, что этот документ рекомендует всем госорганам использовать СПО в приоритетном порядке?

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

Также в документе указывается, что для использования свободных программ совершенно не обязательно покупать их дистрибутивы (п. 16), что является довольно распространенной практикой при реализации государственных программ по переходу на СПО. Вспомнить ту же историю с внедрением СПО в российских школах, когда на закупку и распространение таких дистрибутивов были потрачены огромные деньги, при том что все это ПО можно было просто загрузить по сети: благо, уровень проникновения и доступности Интернета в России сейчас очень высокий.

Каково будущее СПО в российских госорганах?

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

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

С текстом Методических рекомендаций можно ознакомится здесь.

[1] План перехода федеральных органов исполнительной власти и федеральных бюджетных учреждений на использование свободного программного обеспечения (2011 — 2015 годы),  утв. распоряжением Правительства Российской Федерации от 17 декабря 2010 г. № 2299-р.