Минкомсвязи в конце декабря опубликовало свои взгляды в отношении внедрения свободного программного обеспечения (СПО) в госорганах. В документе перечислены преимущества свободных продуктов, главными из которых названы бесплатность и безопасность. Но так ли это на самом деле?
Свободное — значит бесплатное?
Существует распространенное мнение о том, что свободный софт является одновременно и бесплатным. В документе Минкомсвязи использован именно этот тезис:
Во-первых, это дешевизна и антикоррупционность. СПО не требует лицензионных выплат за каждый установленный экземпляр программ.
Однако IТ-эксперты, в том числе основатель движения open source Ричард Столлман, с этим не согласны. Сам Столлман на каждом своем выступлении повторяет фразу:
Free — значит свободное, но не бесплатное. И все это не равно Open Source. Это три понятия, которые смешивать не стоит.
За примерами, которые подтверждают это мнение, далеко ходить не нужно. Из недавнего — компания Dell согласилась платить Microsoft лицензионные отчисления («роялти») за использование Android и Chrome OS на своих устройствах. Корпорация из Редмонда владеет целым рядом патентов на технологии, которые использованы в открытых проектах, созданных Google.
Тот же Столлман публиковал статью, в которой призывал поддержать кампанию за «оcвобождение Android», то есть за публикацию исходных кодов операционной системы (а ее создатель, Google, делать этого не собирается).
В конечном итоге открытый софт может быть бесплатным для конечного пользователя, но в случае корпоративных продуктов и массовых инсталляций все не так просто. Компания может участвовать в разработке нужного ей продукта и отправлять свои фиксы в общий репозиторий — или (если в процессе «допиливания» продукта, произошел выход за рамки лицензии GNU) нанимать собственную выделенную команду разработчиков для поддержки форка. Как несложно догадаться, с бесплатностью этот путь имеет мало общего.
Свободный софт более безопасен
Поскольку, как мы только что выяснили, свободное ПО, бесплатное и Open Source — это три совершенно разные вещи, то кажется, что одна из них и должна быть более безопасной, чем проприетарные продукты. На самом деле это не так.
В документе Минкомсвязи сказано, что закрытые продукты менее безопасны, поскольку в них встречаются недокументированные возможности:
Многие проприетарные приложения от известных производителей содержат недокументированные функции, что является потенциальной угрозой.
Но ведь и многие из открытых (свободных, бесплатных) приложений — тоже содержат недокументированные функции. Не всегда разработчики успевают (и не всегда хотят) надлежащим образом документировать возможности своего проекта. Более того, потенциальной угрозой является и целый ряд документированных функций (например, Userialize или Bash).
Отдельный вопрос, на который нужно дать ответ — что такое «недокументированные функции», подходит ли под это определение, скажем, не описанный в документации пункт меню? Если речь идет о «недекларированных возможностях», то должен существовать процесс их декларации. Если же подразумеваются уязвимости, то это совсем другая тема.
На самом деле, для того чтобы повысить уверенность в безопасности кода, достаточно следовать простому алгоритму:
- Должен быть «крайний», кто за эту безопасность отвечает (внутренний или внешний, например производитель ПО).
- Ответственный должен получить соответствующее задание.
- Его необходимо обеспечить необходимыми средствами и инструментами!
- Нужно внедрять безопасную разработку (SDL), управление конфигурациями и уязвимостями.
В таком случае будет совершенно неважно, ведется ли работа со «свободным», «бесплатным», «платным» или «проприетарным» ПО. Наличие опубликованных исходных кодов в некоторых случаях облегчают процесс обеспечения безопасности (при этом о бесплатности речь все равно не идет), но этот факт не помогает (а иногда и мешает) найти ответственного. Более того, тотальная открытость делает бесполезным вопрос: «Кто писал эту строчку?»
В случае с бэкдором в RSA выяснилось, что компании заплатило АНБ — то есть виновника удалось найти. А вот откуда в пакете SSL взялась уязвимость Heartbleed — непонятно до сих пор.
С другой стороны, свободное ПО легче адаптировать к изменяющимся условиям. Конечно же, установка «закрытой и несвободной» Windows на HMI в системах АСУ ТП — это очевидная ошибка, которая привела к тому, что во многих системах до сих пор не закрыта уязвимость CVE-2010-2568, через которую в свое время распространялся червь Stuxnet. Использование «открытой» системы позволило бы разработать свой патч, но и для этого нужна команда разработчиков, которая стоит денег.
Должно ли государство развивать российский Open Source
Еще одна выдержка из документа Минкомсвязи, в которой звучит тезис о том, что свободный софт соответствует национальным интересам:
В-четвертых, использование СПО учитывает национальные интересы. Несмотря на то, что создание свободных программ неотделимо от мирового сообщества разработчиков, сервисные услуги по их адаптации, внедрению, поддержке и развитию, оказывают, как правило, национальные фирмы, что более выгодно государству и обществу.
Получается, что «перелицовка» Open Source (даже с нарушением GPL) — это правильно отвечает интересам страны, но создание с нуля собственной технологии, которая по каким-то причинам не является СПО — таким интересам не отвечает.
В России компаний вроде ALT Linux, которые делают все верно и по букве всех лицензий и законов открытого ПО, крайне мало. В целом же разработка «пакета свободного отечественного программного обеспечения» — задача, может быть, и светлая, но явно не первоочередная.
Здесь хотелось бы обратиться к еще одной популярной теме — к созданию «отечественной ОС».
Операционная система не нужна!
В деле импортозамещения куда логичнее обратить внимание не на создание собственных ОС и офисных пакетов, а на совсем другие направления. Начинать нужно с чего-то, что имеет конечную цель, и должна существовать возможность посчитать эффективность этого «чего-то». Операционная система — это явно не «оно».
Десктопы
Десктопы, несмотря на всю их архаичность, еще долго будут оставаться серьезным «пожирателем» IТ-бюджета в корпоративном секторе с циклом обновления в 3—5 лет. Учитывая, что существенной частью корпоративного сектора в России является госсектор и связанные с ним компании, перевод этой ниши на российские продукты вполне реален — нужно лишь волевое решение.
«Ну вот же, свой Windows!» — скажет читатель. Отнюдь нет! Начинать делать десктоп нужно с процессора. Более того, он у нас есть, и неплохой. Да, речь об «Эльбрусе».
Уже в процессе работы над собственным процессором попутно придется решать и вопросы с созданием операционных систем, языков программирования и прочих элементов экосистемы. Для того чтобы производители софта захотели писать под условный «Эльбрус», необходимо чтобы на подобные продукты был спрос, а МЦСТ мог производить достаточное количества железа.
Уже упомянутые госкомпании и их сателлиты могут составить костяк первых пользователей. Если производители ПО (тот же ALT Linux, или JetBrains) увидят перспективы и пользовательскую базу, то не откажутся создать версию под «Эльбрус» (кстати, и мы сейчас портируем PT Application Firewall на этот процессор) — заодно и совместимость с «просто Linux» и другими платформами появится.
Все в облако
Тренд на «переезд» многих привычных приложений в облако неоспорим: там уже и Excel, и Word, и «1C». Частное «офисное» облако закрыло бы нужды 90% пользователей десктопов в корпоративном секторе. В настоящий момент подобные продукты все больше и больше становятся обыкновенной подложкой под сам «интернет». Самым важным десктоп-приложением становится браузер, а создать его уже совсем не так сложно, как показывает пример Opera или Яндекс.Браузера.
Казалось бы, все переехали на Chromium — но в этом нет ничего плохого. Если взять за основу существующую платформу, навесить на нее дополнительные функции и обеспечить цикл поддержки, это позволит создать конкурентоспособный продукт. А уже параллельно можно будет заняться и созданием собственного Chromium, если это необходимо.
Железное небо
Конечно, для создания собственного облака необходимы и другие компоненты, и первая проблема здесь — отсутствие железа (особенно печальная ситуация сложилась с серверными платформами). Быстрого решения в этой области ждать не приходится, поэтому на первых этапах нет ничего зазорного в том, чтобы использовать уже имеющиеся решения.
С сетевыми «железяками» ситуация постепенно налаживается, в области NAS серьезные вещи делает RAIDIX, нельзя сбрасывать со счетов и «Т-Платформы». С софтом ситуация гораздо лучше — есть прекрасная платформа для виртуализации от Parallels и nginx, как надежная основа для серверов приложений.
Не все гладко и с СУБД (даже создатели «Эльбруса» из МЦСТ говорят об Oracle), хотя есть такие продукты, как «Линтер», Red «База данных». При этом необходимо понимать, что с MS SQL и Oracle съехать легко и просто не получится. Это, однако, не означает, что не нужно создавать собственные enterprise-СУБД: как минимум RDBMS и какое-то количество NoSQL-проектов (например, document и graph) — точно бы не помешало. Даже если брать за основу PostgreSQL, Hadoop или ElasticSearch — главное, чтобы эти продукты использовались и под них создавались приложения.
Итого
Конечно же, свободное ПО вполне можно и нужно использовать, адаптировать и развивать. Однако тезисы о его бесплатности, «лицензионной чистоте» и защищенности не выдерживают никакой критики. «Бесплатно» и «безопасно» — это просто сказки, и все знают, где бывает бесплатный сыр.
Нынешний период может стать золотым временим для IТ-отрасли в России. В деле импортозамещения стоит сделать ставку на «национальных чемпионов» в своей области, работающих в плотной кооперации, форсировать прорывные или просто необходимые проекты, предоставлять бизнесу «длинные деньги» и обеспечивать контроль и прозрачность — но это все как раз и в силах государства.
Автор: Сергей Гордейчик, по материалам личного блога (1, 2)
