Как правильно делать Due Diligence ПО?

⏱ Время чтения: 10 минут

Какие процессы и активы создают стоимость в сделках tech M&A? Зачем нужен acqui-hiring? Чем юристу может помочь технический due diligence ПО и есть особенности управления процессом юридической проверки прав на ПО? Об этом рассказывает наш эксперт Анастасия Нерчинская, юрист M&A и IT, автор и член сообщества профессионалов The Experts: School of Finance, автор телеграм-канала по M&A.

Какие активы и процессы создают стоимость для акционеров приобретателя ИТ-бизнеса? Ключевые из них:

1. программное обеспечение (ПО) – AS IS и готовые продукты;

2. команда разработки и технической поддержки (в IT-секторе очень распространен т.н. acqui-hiring через M&A);

3. обслуживающая инфраструктура;

4. бизнес-процессы (автоматизированное или «ручное» управление разработкой) и методология разработки ПО;

5. для некоторых видов бизнеса – массивы данных и технологии их обработки.

До покупки ИТ-бизнеса приобретателю важно сделать как минимум четыре вида проверок:

1. техническую;

2. налоговую;

3. финансовую и

4. юридическую (хотя бы в объеме указанных выше вопросов, связанных с ключевыми активами).

Ключевые вопросы юридической проверки ИТ-компании включают проверку:

1. чистоты прав на ПО;

2. текущих правообладателей программного продукта;

3. лиц, контролирующих экземпляры кодовой базы ПО;

4. процессов создания и коммерциализации ПО;

5. соответствующих рисков.

Как правильно сделать юридическую проверку прав на ПО и какие могут возникнуть сложности – далее в материале.

ПОЧЕМУ СТАНДАРТНЫЙ ПОДХОД К DUE DILIGENCE НЕ РАБОТАЕТ

Обычно в крупных M&A-сделках due diligence ПО делают юридические консультанты.

Единых правил такой проверки не существует. Но постепенно складываются форматы, которые называют «рыночной практикой». Стандарты, глубина и подходы к due diligence ПО могут сильно отличаться в зависимости от консультанта и целей заказчика.

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

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

Что не так со стандартным подходом к проверке прав на ПО

Стандартный подход – это когда юридическая проверка полностью контролируется юристами и ее итоги в максимальной степени зависят именно от юридической команды. Юристы по своему усмотрению ведут Q&A-процесс и формируют комнату данных. Основной подход к проверке – документальный. От пояснений бизнес-команды юридические выводы существенно не зависят.

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

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

Почему при таком подходе ошибки неизбежны?

Покупатель (заказчик due diligence) ограничен в доступе к фактическим данным (их у него просто нет). Он переадресует вопросы юристов непосредственно проверяемой компании — владельцу ПО, а в некоторой части — продавцу.

Получив от юридических консультантов покупателя запрос на предоставлении информации по ПО, команда таргета (предполагаемого владельца ПО) далеко не всегда понимает, как на него правильно ответить.

Во-первых, не у всех в штате есть ИТ-юристы, способные «перевести» такой запрос с юридического языка на понятный бизнесовый.

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

На ряд вопросов бизнес-команда таргета без дополнительных пояснений часто не может ответить. Иногда вопросы в принципе не понятны. Стандартные вопросники очень редко кастомизируются юридическими консультантам под конкретный проект и формулируются по принципу «предоставьте все обо всем». Не потому, что консультанты не понимают серьезности задачи. А потому, что как раз без технических вводных кастомизированный первичный запрос на проверку ПО и ИТ-систем сделать почти невозможно.

Почему нужна предварительная техническая экспертиза?

Для полноценной проверки прав на ПО и выявления исторических рисков невозможно обойтись силами только юридической команды. Первичное звено при проверке прав на ПО – не юристы, а технические специалисты. Но пока при управлении tech M&A-проектами об этом не так часто задумываются. Иногда срабатывает логика: если задача — проверить наличие прав, значит, надо сразу идти к юристам. Ведь так делают всегда, когда надо проверить права на любой другой актив.

Почему ПО — исключение из этого правила?

Из всех объектов гражданского оборота «чистоту» прав, на которые обычно проверяют в рамках due diligence, ПО без преувеличения является самым сложным. Причины:

1. оно невидимое/неосязаемое;

2. постоянно изменяется во времени;

3. сложно поддается идентификации для разных целей.

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

Иными словами, внешний наблюдатель (находящийся «снаружи» кодовой базы) никогда не может четко знать – перед ним все еще тот же объект (ПО) или уже другой. Если другой, когда и что конкретно с ним изменилось?

Если юридическая проверка ПО будет основана на некорректных вводных данных, юристы неизбежно придут к ошибочным выводам (хорошо, если только в части). Далее подключается команда M&A, которая полностью полагается на итоги проверки бизнеса IP-командой. Это негативно скажется на итогах всего due diligence: как в части выявления рисков, так и их митигации.

Чем юристу могут помочь данные по результатам технического due diligence программного продукта? Например, с помощью таких данных можно:

1. отделить одно ПО от другого;

2. выделить отдельные компоненты внутри сложного программного комплекса;

3. установить точное количество самостоятельных и зависимых ПО и существующих между ними связей;

4. установить круг авторов ПО. Это не юридическая, но крайне важная для юридического due diligence ПО задача;

5. отделить стороннее ПО и ПО с открытым исходным кодом в составе программного продукта;

6. определить методологию разработки (это особенно важно при анализе юридических аспектов создания обновлений ПО и его развития);

7. определить «где что хранится» (кодовые базы различных продуктов, бэкапы, черновые версии, документация, журналы логирования и т.п.) – это важно для переноса всех процессов, связанных с ПО, в контур покупателя).

Вывод

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

Поэтому проверка прав на ПО имеет серьезные особенности с точки зрения управления процессом due diligence. Здесь очень важна фигура т.н. process-owner. То есть общего координатора, который помогает всем сторонам – заказчику, таргету, их командам консультантов, технических специалистов и т.п. прийти к единому пониманию происходящего в рамках сделки и ее отдельных этапов.

КАК СДЕЛАТЬ ПРАВИЛЬНО?

В силу специфики такого объекта как ПО, на 100% выявить все риски и установить точную картину не получится. В этом и нет необходимости. Достаточно определить ситуацию по рискам с существенной степенью достоверности.

Что для этого нужно сделать?

Юридическая проверка прав на ПО должна начинаться с верификации ключевых фактических обстоятельств, относящихся к разработке ПО.

К ним относятся как минимум следующие три:

1. сколько в рамках программного продукта самостоятельных компонентов и как они связаны;

2. кто их авторы;

3. в какие периоды времени они (их «минимально жизнеспособные продукты (MVP») были созданы.

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

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

Эти данные можно уточнить у CTO, команды разработки / технической поддержки. И на протяжении всего проекта быть готовыми комментировать/уточнять детали, делать стримы с командой разработки, проверять одни и те же аспекты с разных ракурсов, используя подход “cross-questioning”.

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

Что следует запросить у команды таргета в отношении ПО:

1. Описание архитектуры ПО с указанием структурных элементов, из которых оно состоит (компонентов, модулей, подсистем), их названий и способов линкования (fttp-протоколы, брокеры сообщений и т.п.), а также краткое описание функционала каждого из таких элементов.

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

1. Период разработки минимально жизнеспособного продукта (MVP) ПО в целом.

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

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

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

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

Эти сведения помогут верифицировать круг авторов и правообладателей.

Часто ошибки в due diligence связаны с тем, что неправильно установлен порядок взаимодействия при написании кода. Например, младший разработчик писал код в обычной «ветке» кодовой базы, код за ним проверял старший коллега, он же и делал коммиты, которые содержали проверенный код. В репозитории видны коммиты такого «выкладчика», и их может быть много. Это может привести к выводу, что старший коллега, который проверял код за младшим, внес серьезный вклад в написание ПО. А по факту он может вообще не являться автором либо его вклад будет существенно ниже. Исправление ошибок, как правило, не образует нового охраноспособного элемента ПО.

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

   1) ФИО и должностей по штатному расписанию (если это штатный разработчик);

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

   3) их роли при работе с ПО (frontend/backend/full-stack разработчик, дизайнер, архитектор, тестировщик, отладчик и т.д.);

   4) логины/никнеймы в системе и его расшифровка — ФИО разработчика, кому принадлежит;

   5) даты приема на работу для штатных работников/заключения гражданско-правового договора или начала работы без договора для внештатных работников;

   6) даты увольнения/прекращения гражданско-правового договора;

   7) количества коммитов в хранилище/репозитории (в процентном и в абсолютном выражении);

   8) сведений о том, кто из этих лиц фактически разрабатывал код, а кто только выкладывал части кода, написанные другими разработчиками (с указанием их ФИО);

   9) описания конкретного вклада в разработку ПО каждого из лиц, кто участвовал в ее создании, в том числе лиц, не имевших доступа в информационные системы, указанные выше (то есть кто придумал идею ПО/ее функционал, разработал архитектуру, писал непосредственно код, подбирал компоненты для линковки и средства интеграции, организовывал процесс и т.д.).

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

На какие вопросы при проверке прав на ПО следует обратить особое внимание

Базовая юридическая проверка прав на ПО обычно предполагает:

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

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

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

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

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

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

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

4. Подготовку рекомендаций по смягчению рисков для целей заключения предполагаемой сделки.

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

Также при проверке прав на ПО при необходимости следует:

1. Определить:

   1) виды деятельности таргета и компаний его корпоративной группы: только сервисная разработка, только продуктовая, или гибридная;

   2) какой процент выручки приходится на каждый вид деятельности;

   3) по какой договорной модели осуществляется коммерциализация ПО на рынке.

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

1. Проверить, как структурированы отношения по техподдержке ПО.

В договорах на услуги по техподдержке часто не регулируются вопросы распределения прав на ПО. Многие воспринимают эту деятельность как услуги, а не как создание ПО. Тем не менее, иногда в рамках услуг техподдержки появляется так называемое side-ground IP. То есть самостоятельно охраноспособные части ПО, создание которых не являлось предметом договора. Права на такие «случайные» компоненты лучше консолидировать у заказчика услуг техподдержки. 

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

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

1. Обратить внимание заказчика на возможные налоговые и бухгалтерские последствия «митигации» титульных рисков на ПО. Например, ПО, права на которое «не подтвердились» в рамках due diligence, ранее могло быть поставлено на учет как нематериальный актив. Если юристы в качестве митигации риска порекомендуют выкупить права на ПО у текущих правообладателей, может потребоваться корректировка данных бухгалтерского и налогового учета.

2. Установить всех текущих правообладателей ПО, а также «места» хранения кодовой базы. Это важно, когда не все компании группы таргета входят в периметр сделки, и часть сервисов останется под контролем продавца или его аффилированных лиц. Или в ситуации, когда, например, таргет перерабатывала ПО на основе лицензии от материнской компании (продавца). В этом случае, даже при переходе прав на ПО в таргет для целей сделки, нужно внимательно анализировать принадлежность прав на ранее созданные переработки и их консолидации в периметре сделки.

3. Внимательно проверить оформление отношений с зарубежными разработчиками.

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

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

Вывод

Специфика такого объекта как ПО не позволяет провести юридическую проверку методом поверхностного (ограниченного) анализа (как, например, это было бы возможно в случае проверки титула на некоторые объекты недвижимости). «Экспресс»-проверка, особенно если приобретается масштабная технология, с высокой степенью вероятности приведет к неверным выводам. При приобретении крупного бизнеса по сделке M&A, цена некачественной проверки прав на ПО может впоследствии оказаться слишком высокой.

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

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