Банки и Информационные технологии

В сентябре 2015 г. США ввели санкции еще против пяти российских компаний. Теперь уже из-за нарушения американского закона о нераспространении оружия массового поражения. Источники агентства Reuters сообщают о возможности введения новых санкций против России из-за атак российских хакеров. Так что война санкций продолжается.

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

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

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

Эскроу в российском законодательстве

Само понятие»условное депонирование» (эскроу) появилось в российском законодательстве совсем недавно. 1 июля 2014 г. вступили в силу новые положения Гражданского Кодекса РФ, предусматривающие возможность осуществления расчетов посредством заключения договора счета эскроу (договора условного депонирования денежных средств).

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

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

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

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

Основные шаги при организации условного депонирования ПО

На Западе эскроу используется давно и широко распространено в ИТ. Условное депонирование ПО — это как брачный договор. Изначально вы думаете, что он никогда не понадобится. Но иногда ошибаетесь. И когда отношения в браке начинают ухудшаться, понимаете, что заключение брачного договора было правильным решением.

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

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

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

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

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

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

Заключение договора и сопровождение работ

Третий шаг — определение бюджета сделки по депонированию. Нужно понимать, что придется оплачивать не только непосредственно депозитный гонорар эскроу-агента, но и работы по проверке депозита и юридические услуги. Какова цена вопроса? Готовы ли вы выложить требуемую сумму? Во сколько вам обойдется отказ депонируемых систем и насколько велики риски наступления «развода» — дня «Ч»?

Четвертый шаг — выбор эскроу-агента. У него должна быть лицензия. И это должна быть действительно нейтральная компания, которой должны доверять обе стороны — и заказчик, и продавец-разработчик. Заказчик должен быть уверен, что в день «Ч» агент непременно выполнит то, что прописано в договоре. А разработчик — что агент не сольет депонируемые исходники кода третьим лицам.

Следующие два шага — организационно-юридические. На пятом шаге идет согласование договора со всеми сторонами. С депонентом (вкладчиком) — разработчиком ПО или лицензиаром, с заказчиком — бенефициаром и с эскроу-агентом.

А на шестом — непосредственно заключение соглашения. На этом этапе особенно важна работа юристов, проверяющих выполнимость заложенных в договоре условий. Например, не пропустить приписанное на этапе согласования требование «когда рак на горе свистнет».

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

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

Этому вопросу часто не уделяется должного внимания. А зря. По данным Iron Mountain, одного из лидеров на рынке эскроу, 80% передаваемых эскроу-агенту на депонирование документов не содержат всех необходимых материалов для восстановления ПО, а 90% требуют при восстановлении дополнительного участия разработчика. И эти недостатки нужно выявить до наступления времени «Ч». Да и обратиться с требованиями об устранении недостатков лучше, когда фирма еще работает, а не когда она уже перестала существовать или заниматься нужным вам бизнесом.

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

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

Немного о типах соглашений

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

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

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

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

— Генеральное двухстороннее соглашение. Отличается от двухстороннего соглашения тем, что депонируется сразу несколько программных продуктов.

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

Как депонировать SaaS-приложения?

Традиционно ПО передавалось разработчиком на физических носителях, например на DVD-ROM. Эти носители и депонировались эскроу-агентом. И в случае наступления условий, оговоренных в договоре, передавались бенефициару.

А что делать, если разработанное ПО реализовано в облаке? Несмотря на сомнения скептиков, бизнес-критические приложения все чаще размещаются в облаках, например системы интернет-банкинга или даже банковские АБС.

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

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

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

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

По сути получается гибрид эскроу с системой резервного копирования в реальном времени. Примером может служить система SaaS Protect Escrow Service компании Iron Mountain. Если облачный провайдер за оговоренное в договоре время не может восстановить доступ к SaaS-приложению, то абонент связывается с эскроу-агентом и начинает работать на резервной копии приложения. При этом эскроу-агент передает бенефициару объектный код и документацию, необходимую для разворачивания бенефициаром приложения в другом облаке или на своих мощностях. А если фирма разработчик SaaS-приложения совсем прекратила его поддержку и наступило время «Ч», то у бенефициара останется работоспособная версия со всеми данными, исходными кодами и требуемой документацией.

Нужно ли это России? Поможет ли эскроу против санкций?

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

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

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

Что касается санкций, то это вопрос сложный и запутанный. С одной стороны, эскроу-агент по сути выступает страховой компанией. Он не поставляет ПО компании, попавшей под санкции, а просто «выплачивает страховку». Если, конечно, попадание под санкции как «страховой случай» и основание для передачи депонированного ПО были прописаны в договоре. Да и если такого пункта нет, а сама фирма разработчик разорилась или сменила деятельность — то «страховой случай» наступил. И ПО должно быть передано, даже если бенефициар попал под санкции.

С другой стороны, реальных кейсов еще не было и непонятно, как поведут себя эскроу-агенты в такой ситуации. Особенно, если эти эскроу-агенты находятся в юрисдикции США.

Да и ответы западных юристов — специалистов по эскроу ПО довольно уклончивы. Так, Дмитрий Дубограев, американский адвокат и руководитель международной юридической фирмы femida.us, представляющей интересы ИТ-компаний на западных рынках, в ответ на наш вопрос, можно ли использовать эскроу программного обеспечения, как страховку от санкций, прописав введение санкций как страховой случай в договор, ответил: «Думаю, да — санкции могут быть, например, форс-мажором».

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

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

Что дальше?

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

Но то, что система условного депонирования ПО, да и вообще технологий, пригодится и в нашей стране, сомнений у экспертов вызывает. Проблема эскроу актуальна, хотя в основном для нестандартных систем. Первоочередное — доверие к разработчику. И все, что это доверие повышает, — полезно. «Если эскроу прижилось в США, то скорее всего приживется и в России», — пояснил нам Андрей Бешков, Security Program Manager for CEE и CIS компании Microsoft.

Действительно, если это есть и востребовано на Западе, почему бы не использовать и у нас? Вот только наше законодательство здесь сильно отстает. Есть надежда на новую редакцию Гражданского кодекса, в проекте которого понятие эскроу расширяется. Уже можно будет депонировать не только деньги. Согласно п. 3 Ст. 926.1 «Объектом депонирования могут быть вещи (включая наличные деньги, документарные ценные бумаги и документы), безналичные денежные средства, бездокументарные ценные бумаги».

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

Опубликовано в PCWEEK/RE