Алексей Смирнов: 
«Сейчас трудно найти программный продукт, в котором нет свободного кода»

Какое будущее ждет свободное ПО? Влияет ли свободная или несвободная разработка на качество кода? В чем преимущество свободной разработки вообще и для России в частности?

На эти и другие вопросы «Системного администратора» отвечает Председатель совета директоров Базальт СПО.

– Алексей Владимирович, сейчас в России очень много решений, основанных на СПО. С чем это связано?

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

Microsoft обычно приводят как пример проприетарной разработки, но в компании очень широко используют СПО.

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

Свободный софт – действенный способ организации сотрудничества. Можно консолидировать усилия разработчиков из разных фирм, в том числе конкурирующих, и сэкономить массу ресурсов. Но при этом необходимо договориться, как пользоваться результатами совместного труда. Свободная лицензия – это как раз такое соглашение. Мы договорились, мы вместе разрабатываем, а то, что получится, будет под лицензией MIT, GNU General Public License (GPL) или под какой-то другой.

Огромную роль в развитии свободного софта играют государства. Например, стек TCP/IP, на котором построен весь интернет, был разработан по заказу военных США университетом Беркли под свободной лицензией. Само название лицензии BSD расшифровывается как Berkeley Software Distribution licenses – «Программные лицензии университета Беркли». Во многих странах массово публикуются программы, разработанные на бюджетные деньги. В США есть порталы, где это ПО хранится, в том числе для военных. В Европе, Китае, Индии есть подобная практика.

В России такие планы есть, но пока они не реализованы. В 2022 году постановлением Правительства был запущен эксперимент по публикации софта, разработанного на бюджетные средства по госконтрактам, под свободной лицензией. Эксперимент закончился в апреле 2024 года. По результатам должен был быть составлен отчет в Правительство с предложениями по дальнейшему развитию. Но пока я его не видел.

– Можете назвать конкретные продукты, разработанные в процессе эксперимента?

– Это различные модули для платформы Гостех.

– И коды опубликованы?

– Да, всё это где-то лежит. По прямой ссылке можно зайти и скачать, мне присылали одну. Но чтобы ходили, махали флагами и призывали: «Вот новые открытые разработки, берите, пользуйтесь!» – такого нет.

Хотелось бы, чтобы у нас эта практика получила развитие. Нет никаких причин не публиковать под свободной лицензией результаты госзаказа, если на них нет грифа секретности.

– Имеет ли смысл создать государственное хранилище для подобных проектов?

– Были планы сделать такое хранилище, но под него деньги не выделили. Но вообще, вопрос не в том, где хранить. Вариантов уже сейчас существует несколько.

Например, есть Национальный фонд алгоритмов и программ. Да, он мертворожденный, но он есть.

Есть закон об обязательном экземпляре, по которому некоторое количество всех изданий направляют в Минцифры, откуда их распределяют в Российскую государственную библиотеку и т. д. По этому же закону все разработанные программы для ЭВМ должны сдаваться в НИИ «Интеграл», подведомственный Минцифры. Правда, это не выполняется, и никаких мер принуждения нет.

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

И это не потребует мощных СХД, больших серверов. Исходный код занимает очень мало места. Программа – это то, что человек руками написал. А человек руками много написать не может. И объем скачивания там не такой гигантский. Это же не социальные сети, не кино.

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

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

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

– В чем преимущество свободной разработки вообще и для России в частности?

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

– Сейчас в стране остро не хватает кадров в разработке. Широкое использование свободных лицензий позволит хотя бы частично решить эту проблему? Избежать ситуации, когда 10 человек делают одну и ту же работу независимо друг от друга?

– Безусловно!

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

По-хорошему, любое требование электронного взаимодействия с государством должно сопровождаться референсной реализацией под свободной лицензией. Должна быть выложена в общий доступ программа, которая реализует это электронное взаимодействие. Нужно не просто говорить: «Мы сделали систему, к ней подключаться надо вот так». Лучше заказать программу, которая это подключение обеспечивает, и опубликовать ее под свободной лицензией. Все будут этот код брать и использовать. Пусть он будет не идеальный, дальше участники могут дорабатывать. По крайней мере, это уже не просто требование, но еще и помощь в его выполнении.

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

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

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

– Я сошлюсь на ФСТЭК России. У них есть понятие и модель «злоумышленника». И этот условный злоумышленник обладает всей информацией о способах и методах защиты программного продукта. Система может быть признана защищенной не потому, что никто не знает, как она устроена, а потому, что она защищенная. Это требования регулятора.

Если кто-то не хочет показывать код, опасаясь, что из-за этого систему взломают, значит, система кривая, вот и все.

Есть понятие Bug Bounty, когда привлекают «белых хакеров», они стараются взломать систему, а за найденные ошибки и уязвимости получают награды. И предоставление исходников в Bug Bounty – это хороший вариант. «Вот наши исходники, смотрите. Мы в них уверены, если вы найдете, мы вам большое спасибо скажем».

– Влияет ли свободная или несвободная разработка на качество кода?

– Может быть, не всем приятно это услышать, но, на мой взгляд, зачастую свободный код написан более качественно, чем несвободный.

– Почему?

– Одно дело, если программист пишет до состояния, когда его программа заработает. Но показать этот код коллегам, тем более конкурентам, просто стыдно. Потому что так нельзя писать. И это сплошь и рядом происходит.

Да, человек написал, хорошо, если что-то документировал. У него там какие-то заплатки, костыли стоят. Сроки горели, он сделал тяп-ляп.

Есть много случаев, когда крупные фирмы объявляли об открытии исходного кода, и у них иногда уходили годы на то, чтобы привести код в состояние, в котором не стыдно его выложить.

Например, фирма Sun заявила, что опубликует коды Star Office. Сейчас эта программа под свободной лицензией называется OpenOffice. На публикацию ушло два года, потому что они вычищали все накопившееся безобразие.

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

– Наверняка, наряду с качественными решениями в открытом доступе есть огромное количество некачественных. Как сориентироваться в этом море вариантов?

– Здесь важен профессионализм разработчика. Во-первых, есть разные проекты с разной репутацией. Во-вторых, грамотный разработчик, посмотрев код, понимает уровень.

– Но сколько нужно просмотреть похожих решений, чтобы найти хорошее? Или нужно знать, где искать, где есть предварительные проверки?

– Конечно, не обязательно просматривать всё. Есть успешные проекты, которые на слуху, с хорошей репутацией.

Например, есть четыре или пять известных реализаций почтовых клиентов. У всех свои преимущества и недостатки. И можно пользоваться ими в целом либо более мелкими кусками кода.

– Наверняка, к известным проектам очень много программистов предлагают свои улучшения. Кто их проверяет, принимает решение, включать или не включать в продукт?

– Можно сделать улучшение и собрать у себя свою версию продукта. Ее проверит ровно тот, кто написал, или тот, кого он попросит.

Но в таком случае, когда выйдет новая версия продукта, придется снова все пересобирать. Поэтому обычно имеет смысл внести улучшения в основной проект.

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

– Значит, в СПО тоже есть бюрократия?

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

Приоритет есть и у изменений по закрытию уязвимостей.

– Люди получают зарплату за проверку присланного кода или это для них общественная нагрузка обычно?

– Как правило, получают. Либо их поддерживают фонды, такие как Linux Foundation, есть Free Software Foundation, либо это сотрудники тех или иных коммерческих фирм, которые готовы вложиться в доработку своих продуктов силами сообщества. Как правило, отсматривают код действующие разработчики, которые сами что-то пишут.

И там есть разные роли: кто-то пишет документацию, кто-то красивые картинки делает и так далее.

– Получается, что свободный продукт – это результат коллективного труда. Как реализуется техническая поддержка пользователей, кто за нее отвечает? Как это зависит от уровня проекта? Разработчик, который в качестве хобби написал игру «три в ряд», и огромная корпорация – они по-разному это будут делать.

– Есть проекты более и менее ответственные. Отчасти это зависит от важности продукта.

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

Но, допустим, проект интересный, и к нему присоединились еще люди. Образовалось комьюнити. И в нем самые разные люди. Кто-то дописывает и правит код, кто-то просто дает обратную связь, сообщает, какие есть ошибки и что можно улучшить. Кто-то переводит на другие языки.

Например, я был первым переводчиком на русский язык графической оболочки KDE Mini How To, а Андрей Черепанов, который сейчас в «Базальт СПО» релиз-менеджер «Альт Образования» и «Альт Платформы», принимал мой перевод и передавал его в большой проект KDE. Он стоял на стыке между международным проектом и российскими переводчиками. Тогда мы еще не были очно знакомы.

– Но это всё еще неформально и на добровольной основе. Когда появляются коммерческие фирмы в этом процессе?

– Если проект перспективный, его участники могут создавать бизнес, связанный с этим продуктом. Причем разные участники делают это по-разному.

Например, кто-то, хорошо зная продукт, может давать отличную техподдержку. А при необходимости и добавлять функции, нужные заказчику.

Это могут быть конкурирующие фирмы. Отличный пример – PostgreSQL. В мире масса организаций, которые выпускают свои СУБД на базе PostgreSQL со своими доработками. Лицензия PostgreSQL License похожа на BSD, она позволяет в производных продуктах закрывать код и делать проприетарные решения.

И в России несколько фирм собирают и продают свои версии PostgreSQL, у них бизнес соответствующий. При этом они участвуют в разработке «материнского» проекта PostgreSQL.

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

– Значит, серьезную техподдержку оказывают коммерческие фирмы, которые входят в это комьюнити и пользуются результатами его работы?

– Да. И делают это по правилам, установленным в лицензиях. В проекте PostgreSQL договорились, что результаты совместной работы можно использовать в закрытых проектах. А где-то так нельзя. Например, в ядре Linux лицензия GPL, которая не позволяет закрывать код. Это разные договоренности.

– Какое будущее ждет свободное ПО? Его будет всё больше или всё меньше?

– Свободного ПО и так уже очень много, колоссальное количество. Сейчас трудно найти программный продукт, в котором нет свободного кода.

Если же говорить о будущем, у нас на предпоследней, XIX конференции «СПО в высшей школе» был очень интересный доклад Анатолия Якушина. Он обратил внимание на важную, но не очень приятную для свободного софта тенденцию. Сейчас увеличивается доля разработок на некопилефтных лицензиях, то есть лицензиях, позволяющих закрывать код производных продуктов, таких как BSD, а не на разновидностях GPL, которые требуют все доработки также оставлять открытыми.

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

– Тем не менее эти фирмы продолжают поддерживать свободные проекты, платят своим разработчикам, которые над ними работают.

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

Они, находясь в первой пятерке, делают 5-10% разработки. Плюс 5% своей разработки по-тихому делают и закрывают код. И получают полноценный продукт. А иначе им придется тащить все, то есть увеличить штат и расходы в 4-5 раз. Это просто не выгодно. И они кормят эту курицу, чтобы та не сдохла и продолжала нести яйца.

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

– Поскольку лицензия – это, по сути, договор о кооперации, его важно соблюдать. И наиболее болезненное и разрушительное – это ситуации, когда нарушаются свободные лицензии.

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

Ключевые слова: свободное ПО, лицензия, разработчики, разработка, Linux, свободный продукт, техподдержка

Подпишитесь на журнал

Комментарии могут оставлять только зарегистрированные пользователи